21 Oct 2014
At DebConf14 in Portland, Oregon, USA, next year's DebConf team presented their conference plans and announced the conference dates: DebConf15 will take place from 15 to 22 August 2015 in Heidelberg, Germany. On the Open Weekend on 15/16 August, we invite members of the public to participate in our wide offering of content and events, before we dive into the more technical part of the conference during following week. DebConf15 will also be preceeded by DebCamp, a time and place for teams to gather for intensive collaboration.
A set of slides from a quick show-case during the DebConf14 closing ceremony provide a quick overview of what you can expect next year. For more in-depth information, we invite you to watch the video recording of the full session, in which the team provides detailed information on the preparations so far, location and transportation to the venue at Heidelberg, the different rooms and areas at the Youth Hostel (for accommodation, hacking, talks, and social activities), details about the infrastructure that are being worked on, and the plans around the conference schedule.
We invite everyone to join us in organising this conference. There are different areas where your help could be very valuable, and we are always looking forward to your ideas. Have a look at our wiki page, join our IRC channels and subscribe to our mailing lists.
We are also contacting potential sponsors from all around the globe. If you know any organisation that could be interested, please consider handing them our sponsorship brochure or contact the fundraising team with any leads.
Let's work together, as every year, on making the best DebConf ever!
21 Oct 2014 2:30pm GMT
This is an update of my previous attempt at summarizing this discussion. As I proposed one of the amendments, you should not blindly trust me, of course. :-)
First, let's address two FAQ:
What is the impact on jessie?
On the technical level, none. The current state of jessie already matches what is expected by all proposals. It's a different story on the social level.
Why are we voting now, then?
Ian Jackson, who submitted the original proposal, explained his motivation in this mail.
We now have four different proposals: (summaries are mine)
- [iwj] Original proposal (Ian Jackson): Packages may not (in general) require one specific init system (Choice 1 on this page)
- [lucas] Amendment A (Lucas Nussbaum): support for alternative init systems is desirable but not mandatory (Choice 2 on this page)
- [dktrkranz] Amendment B (Luca Falavigna): Packages may require a specific init system (Choice 3 on this page)
- [plessy] Amendment C (Charles Plessy): No GR, please; already resolved (Choice 4 on this page)
[plessy] is the simplest, and does not discuss the questions that the other proposals are answering, given it considers that they already have been resolved (even though I disagree with this analysis).
In order to understand the three other proposals, it's useful to break them down into several questions.
Q1: support for the default init system on Linux
A1.1: packages MUST work with the default init system on Linux as PID 1.
(That is the case in both [iwj] and [lucas])
A1.2: packages SHOULD work with the default init system on Linux as PID 1.
With [dktrkranz], it would no longer be required to support the default init system, as maintainers could choose to require another init system that the default, if they consider this a prerequisite for its proper operation; and no patches or other derived works exist in order to support other init systems. That would not be a policy violation. (see this mail and its reply for details). Theoretically, it could also create fragmentation among Debian packages requiring different init systems: you would not be able to run pkgA and pkgB at the same time, because they would require different init systems.
Q2: support for alternative init systems as PID 1
A2.1: packages MUST work with one alternative init system (in [iwj])
(if you are confused with "one" here, it's basically fine to read it as "sysvinit" instead. See this subthread for a discussion about this)
To the user, that brings the freedom to switch init systems (assuming that the package will not just support two init systems with specific interfaces, but rather a generic interface common to many init systems).
However, it might require the maintainer to do the required work to support additional init systems, possibly without upstream cooperation.
Lack of support is a policy violation (severity >= serious, RC).
Bugs about degraded operation on some init systems follow the normal bug severity rules.
A2.2: packages SHOULD work with alternative init systems as PID 1. (in [lucas])
This is a recommendation. Lack of support is not a policy violation (bug severity < serious, not RC). A2.3: nothing is said about alternative init systems (in [dktrkranz]). Lack of support would likely be a wishlist bug.
Q3: special rule for sysvinit to ease wheezy->jessie upgrades
(this question is implicitly dealt with in [iwj], assuming that one of the supported init systems is sysvinit)
A3.1: continue support for sysvinit (in [lucas])
For the jessie release, all software available in Debian 'wheezy' that supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so.
A3.2: no requirement to support sysvinit (in [dktrkranz])
Theoretically, this could require two-step upgrades: first reboot with systemd, then upgrade other packages
Q4: non-binding recommendation to maintainers
A4.1: recommend that maintainers accept patches that add or improve
support for alternative init systems. (in both [iwj] and [lucas], with a different wording)
A4.2: say nothing (in [dktrkranz])
Q5: support for init systems with are the default on non-Linux ports
A5.1: non-binding recommendation to add/improve support with a high priority (in [lucas])
A5.2: say nothing (in [iwj] and [dktrkranz])
Comments are closed: please discuss by replying to that mail.
21 Oct 2014 1:07pm GMT
Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1from the documentation, a priority less than 0 disallows the package from being installed. systemd-sysv is the package that would enable systemd as your default init (/sbin/init).
21 Oct 2014 12:17pm GMT
This is just a quick announce: Debian packages for Juno are out. In fact, they were ready the day of the release, on the 16th of October. I uploaded it all (to Experimental) the same day, literally a few hours after the final released was git tagged. But I had no time to announce it.
This week-end, I took the time to do an Ubuntu Trusty port, which I also publish (it's just a mater of rebuilding all, and it should work out of the box). Here are the backports repositories. For Wheezy:
deb http://archive.gplhost.com/debian juno-backports main
deb http://archive.gplhost.com/debian juno main
deb http://archive.gplhost.com/debian trusty-juno-backports main
But of course, everything is also available directly in Debian. Since Sid/Jessie contains OpenStack Icehouse (which has more chance to receive long enough security support), and it will be like this until Jessie is released. So I have uploaded all of Juno into Debian Experimental. This shows on the OpenStack qa page (you may also notice that the team is nearly reaching 200 packages… though am planning to off-load some of that to the Python module team, when the migration to Git will be finished). On the QA page, you may also see that I uploaded all of the last Icehouse point release to Sid, and that all packages migrated to Jessie. There's only a few minor issues with some Python modules which I fixed, that haven't migrated to Jessie yet.
I can already tell that all packages can be installed without an issue, and that I know Horizon at least works as expected. But I didn't have time to test it all just yet. I'm currently working on doing even more installation automation at the package level (by providing some OVS bridging init script and such, to make it more easy to run Tempest functional testing). I'll post more about this when it's ready.
21 Oct 2014 5:45am GMT
20 Oct 2014
The biggest part of this HackWeek will be spent on Weblate. The major task is to complete new UI for it. There have been already some blog posts about that here, so regular readers of my blog already know it is using Twitter Bootstrap.
I expect there will be some rough edges, so don't hesitate to report any issues, so that I can quickly fix them.
20 Oct 2014 1:00pm GMT
As a first tiny project in this HackWeek, Enca 1.16 has been just released. It mostly brings small code cleanups and missing aliases for languages, but fixes also some minor bugs found by Coverity Scan.
If you don't know Enca, it is an Extremely Naive Charset Analyser. It detects character set and encoding of text files and can also convert them to other encodings using either a built-in converter or external libraries and tools like libiconv, librecode, or cstocs.
Full list of changes for 1.16 release:
- Fixed typo in Belarusian language name
- Added aliases for Chinese and Yugoslavian languages
Still enca is in maintenance mode only and I have no intentions to write new features. However there is no limitation to other contributors :-).
You can download from http://cihar.com/software/enca/.
20 Oct 2014 8:00am GMT
Here's how to setup LXC-based "chroots" on Debian jessie. While this is documented on the Debian wiki, I had to tweak a few things to get the networking to work on my machine.
Start by installing (as root) the necessary packages:
apt-get install lxc libvirt-bin debootstrap
I decided to use the default
/etc/lxc/default.conf configuration (no change needed here):
lxc.network.type = veth lxc.network.flags = up lxc.network.link = virbr0 lxc.network.hwaddr = 00:FF:AA:xx:xx:xx lxc.network.ipv4 = 0.0.0.0/24
but I had to make sure that the "guests" could connect to the outside world through the "host":
Enable IPv4 forwarding by putting this in
and then applying it using:
Ensure that the network bridge is automatically started on boot:
virsh -c lxc:/// net-start default virsh -c lxc:/// net-autostart default
and that it's not blocked by the host firewall, by putting this in
-A INPUT -d 184.108.40.206 -s 192.168.122.1 -j ACCEPT -A INPUT -d 192.168.122.255 -s 192.168.122.1 -j ACCEPT -A INPUT -d 192.168.122.1 -s 192.168.122.0/24 -j ACCEPT
and applying the rules using:
Creating a container
Creating a new container (in
/var/lib/lxc/) is simple:
sudo MIRROR=http://ftp.nz.debian.org/debian lxc-create -n sid64 -t debian -- -r sid -a amd64
You can start or stop it like this:
sudo lxc-start -n sid64 -d sudo lxc-stop -n sid64
Connecting to a guest using ssh
The ssh server is configured to require pubkey-based authentication for root logins, so you'll need to log into the console:
sudo lxc-stop -n sid64 sudo lxc-start -n sid64
then install a text editor inside the container because the root image doesn't have one by default:
apt-get install vim
then paste your public key in
Then you can exit the console (using
Ctrl+a q) and ssh into the container. You can find out what IP address the container received from DHCP by typing this command:
sudo lxc-ls --fancy
Fixing Perl locale errors
If you see a bunch of errors like these when you start your container:
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "fr_CA.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").
then log into the container as root and use:
to enable the same locales as the ones you have configured in the host.
20 Oct 2014 2:00am GMT
19 Oct 2014
I've previously covered running LAVA on ARM devices, now that the packages are in Debian. I've also covered setting up the home lab, including the difficulty in obtaining the PDU and relying on another machine to provide USB serial converters with inherent problems of needing power to keep the same devices assigned to the same ser2net ports.
There have been ideas about how to improve the situation. Conferences are a prime example - setting up a demo involving LAVA means bringing a range of equipment, separate power bricks, separate network switches (with power bricks), a device of some kind to connect up the USB serial converters (and power brick) and then the LAVA server (with SATA drive and power brick) - that is without the actual devices and their cables and power. Each of those power cables tend to be a metre long, with networking and serial, it quickly becomes a cable spaghetti.
Ideas around this also have application inside larger deployments, so the hardware would need to daisy-chain to provide services to a rack full of test devices.
The objective is a single case providing network, power and serial connectivity to a number of test devices over a single power input and network uplink. Naturally, with a strong free software and open development bias, the unit will be Open Hardware running Debian, albeit with a custom Beaglebone Linux kernel. It's a Test Automation Controller, so we're using the name OpenTAC.
Open hardware ARM device running Debian to automate tests on 4 to 8 devices, initially aimed at LAVA support for Linaro engineers. Power distribution, serial console, network and optional GPIO extensions.
The design involves:
- A Beaglebone Black (revC)
- USB hotplug support required, certainly during development.
- Custom PCB connected as a Beaglebone Cape, designed by Andy Simpkins.
- Base board provides 4 channels:
- 5V Power - delivered over USB
- Ethernet - standard Cat5, no LEDs
- Serial connectivity
- Internal gigabit network switch
- Space for a board like a CubieTruck (with SATA drive) to act as LAVA server
- Daughter board:
- Same basic design as the base board, providing another 4 channels, equivalent to the base channels. When the daughter board is fitted, a second network switch would be added instead of the CubieTruck.
- Power consumption measurement per channel
- queries made via the Beaglebone Black over arbitrary time periods, including during the test itself.
- The GPIO lines can be used to work around issues with development boards under test, including closing connections which may be required to get a device to reboot automatically, without manual intervention.
- Serial connections to test devices can be isolated during device power-cycles - this allows for devices which pull power over the serial connection. (These are typically hardware design issues but the devices still need to be tested until the boards can be modified or replaced.)
- Thermal control, individual fan control via the Beaglebone Black.
- 1U case - rackable or used alone on the desk of developers.
- Software design:
- lavapdu backend module for PDU control (opentac.py) & opentac daemon on the BBB
telnet opentac-01 3225
- ser2net for serial console control
telnet opentac-01 4000
- lavapdu backend module for PDU control (opentac.py) & opentac daemon on the BBB
The initial schematics are now complete and undergoing design review. A lot of work remains …
19 Oct 2014 10:34pm GMT
A new maintenance release of littler is available now.
The main change are a few updates and extensions to the examples provided along with littler. Several of those continue to make use of the wonderful docopt package by Edwin de Jonge. Carl Boettiger and I are making good use of these littler examples, particularly to install directly from CRAN or GitHub, in our Rocker builds of R for Docker (about which we should have a bit more to blog soon too).
The code is available via the GitHub repo, from tarballs off my littler page and the local directory here. A fresh package has gone to the incoming queue at Debian; Michael Rutter will probably have new Ubuntu binaries at CRAN in a few days too.
Comments and suggestions are welcome via the mailing list or issue tracker at the GitHub repo.
19 Oct 2014 9:09pm GMT
Finally I was able to do the enormous paperwork (no, it is not that much) to switch my old 1024D key to a new 4096R one. I was a bit afraid that there might be something bad happening, but my fear was without any reason. After the RT bug was closed, I could upload and sent signed emails to mailing lists. So thanks alot to everyone involved.
old key, 0xD362B62A54B99890 pub 1024D/54B99890 2008-07-23 Key fingerprint = 36E2 EDDE C21F EC8F 77B8 7436 D362 B62A 54B9 9890 uid Thorsten Alteholz (...) sub 4096g/622D94A8 2008-07-23 new key, 0xA459EC6715B0705F pub 4096R/0xA459EC6715B0705F 2014-02-03 Schl.-Fingerabdruck = C74F 6AC9 E933 B306 7F52 F33F A459 EC67 15B0 705F uid [ uneing.] Thorsten Alteholz (...) sub 4096R/0xAE861AE7F39DF730 2014-02-03 Schl.-Fingerabdruck = B8E7 6074 5FF4 C707 1C77 870C AE86 1AE7 F39D F730 sub 4096R/0x96FCAC0D387B5847 2014-02-03 Schl.-Fingerabdruck = 6201 FBFF DBBD E078 22EA BB96 96FC AC0D 387B 5847
19 Oct 2014 8:44pm GMT
I am helping coordinate three and a half day-long workshops in November for anyone interested in learning how to use programming and data science tools to ask and answer questions about online communities like Wikipedia, free and open source software, Twitter, civic media, etc. This will be a new and improved version of the workshops run successfully earlier this year.
The workshops are for people with no previous programming experience and will be free of charge and open to anyone.
Our goal is that, after the three workshops, participants will be able to use data to produce numbers, hypothesis tests, tables, and graphical visualizations to answer questions like:
- Are new contributors to an article in Wikipedia sticking around longer or contributing more than people who joined last year?
- Who are the most active or influential users of a particular Twitter hashtag?
- Are people who participated in a Wikipedia outreach event staying involved? How do they compare to people that joined the project outside of the event?
If you are interested in participating, fill out our registration form here before October 30th. We were heavily oversubscribed last time so registering may help.
If you already know how to program in Python, it would be really awesome if you would volunteer as a mentor! Being a mentor will involve working with participants and talking them through the challenges they encounter in programming. No special preparation is required. If you're interested, send me an email.
19 Oct 2014 1:19am GMT
18 Oct 2014
Yesterday I received a small rush of SPAM mails, all of which were 419 scams, and all of them sent by "Mrs Elizabeth PETERSEN".
It struck me that I can't think of ever receiving a legitimate mail from a "Mrs XXX [YYY]", but I was too busy to check.
Today I've done so. Of the 38,553 emails I've received during the month of October 2014 I've got a hell of a lot of mails with a From address including a "Mrs" prefix:
"Mrs.Clanzo Amaki" <email@example.com> "Mrs Sarah Mamadou"<firstname.lastname@example.org> "Mrs Abia Abrahim" <email@example.com> "Mrs. Josie Wilson" <firstname.lastname@example.org> "Mrs. Theresa Luis"<email@example.com>
There are thousands more. Not a single one of them was legitimate.
I have one false-positive when repeating the search for a Mr-prefix. I have one friend who has set his sender-address to "Mr Bob Smith", which always reads weirdly to me, but every single other email with a Mr-prefix was SPAM.
I'm not going to use this in any way, since I'm happy with my mail-filtering setup, but it was interesting observation.
Names are funny. My wife changed her surname post-marriage, but that was done largely on the basis that introducing herself as "Doctor Kemp" was simpler than "Doctor Foreign-Name", she'd certainly never introduce herself ever as Mrs Kemp.
Trivia: In Finnish the word for "Man" and "Husband" is the same (mies), but the word for "Woman" (nainen) is different than the word for "Wife" (vaimo).
18 Oct 2014 11:03pm GMT
18 Oct 2014 5:41pm GMT
Yesterday I managed to get the last ticket from the waitinglist for the premiere of Trans Gender Moves. It is a play about the lives of three people: A transman, a transwoman and an intersexual person. They tell stories from their life, their process of finding their own identity over time. With in parts amusing anecdotes and ones that gets you thinking I can just wholeheartly encourage you to watch it if you have the chance to. It will still be shown the next few days, potentially extending depending on the requests for tickets, from what I've been told by one of the actors.
The most funny moment for me though was when I was talking with one of the actors about that it really touched me that I was told that one of them will be moving into into the same building I will be moving into in two year's time. Unfortunately that will be delayed a bit because they found me thinks field hamster or the likes in the ground and have to wait until spring for them to move. :/
18 Oct 2014 10:14am GMT
17 Oct 2014
I'm on my way home from Düsseldorf where I attended the LinuxCon Europe and Linux Plumber conferences. I was quite surprised how huge LinuxCon was, there were about 1.500 people there! Certainly much more than last year in New Orleans.
Containers (in both LXC and docker flavors) are the Big Thing everybody talks about and works with these days; there was hardly a presentation where these weren't mentioned at all, and (what felt like) half of the presentations were either how to improve these, or how to use these technologies to solve problems. For example, some people/companies really take LXC to the max and try to do everything in them including tasks which in the past you had only considered full VMs for, like untrusted third-party tenants. For example there was an interesting talk how to secure networking for containers, and pretty much everyone uses docker or LXC now to deploy workloads, run CI tests. There are projects like "fleet" which manage systemd jobs across an entire cluster of containers (distributed task scheduler) or like project-builder.org which auto-build packages from each commit of projects.
Another common topic is the trend towards building/shipping complete (r/o) system images, atomic updates and all that goodness. The central thing here was certainly "Stateless systems, factory reset, and golden images" which analyzed the common requirements and proposed how to implement this with various package systems and scenarios. In my opinion this is certainly the way to go, as our current solution on Ubuntu Touch (i. e. Ubuntu's system-image) is far too limited and static yet, it doesn't extend to desktops/servers/cloud workloads at all. It's also a lot of work to implement this properly, so it's certainly understandable that we took that shortcut for prototyping and the relatively limited Touch phone environment.
On Plumbers my main occupations were mostly the highly interesting LXC track to see what's coming in the container world, and the systemd hackfest. On the latter I was again mostly listening (after all, I'm still learning most of the internals there..) and was able to work on some cleanups and improvements like getting rid of some of Debian's patches and properly run the test suite. It was also great to sync up again with David Zeuthen about the future of udisks and some particular proposed new features. Looks like I'm the de-facto maintainer now, so I'll need to spend some time soon to review/include/clean up some much requested little features and some fixes.
All in all a great week to meet some fellows of the FOSS world a gain, getting to know a lot of new interesting people and projects, and re-learning to drink beer in the evening (I hardly drink any at home :-P).
If you are interested you can also see my raw notes, but beware that there are mostly just scribbling.
Now, off to next week's Canonical meeting in Washington, DC!
17 Oct 2014 4:54pm GMT
Two days ago, Drupal announced version 7.32 was available. This version fixes a particularly nasty bug, allowing a SQL injection at any stage of interaction (that means, previous to the authentication taking place).
As soon as I could, I prepared and uploaded Debian packages for this - So if you run a Debian-provided Drupal installation, update now. The updated versions are:
- sid / jessie (unstable / testing)
- wheezy (stable)
- squeeze-backports (oldstable)
And, as expected, I'm already getting several attacks on my sites. Good thing that will help you anyway: Even though it won't prevent the attack from happening, if you use suhosin, several of the attacks will be prevented. Yes, sadly suhosin has not been in a stable Debian release since Wheezy, but still... :-|
Partial logs. This looks like a shellcode being injected as a file created via the menu_router mechanism (shellcode snipped):
Oct 16 15:22:21 lafa suhosin: ALERT - configured request variable
total name length limit exceeded - dropped variable 'name[0; INSERT INTO
`menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`,
`access_callback`, `access_arguments`) VALUES ('deheky', '', '', 'deheky',
);;# ]' (attacker '220.127.116.11', file '/usr/share/drupal7/index.php')
While the previous one is clearly targetting this particular bug, I'm not sure about this next one: It is just checking for some injection viability before telling me its real intentions:
Oct 17 10:26:04 lafa suhosin: ALERT - configured request variable
name length limit exceeded - dropped variable
(attacker '18.104.22.168', file '/usr/share/drupal7/index.php')
So... looking at my logs from the last two days, Suhosin has not let any such attack reach Drupal (or I have been h4x0red and the logs have all been cleaned - Cannot dismiss that possibility :-) )
Anyway... We shall see many such attempts in the next weeks :-|
[update] Yes, I'm not the only one reporting this attack in the wild. Zion Security explains the same attempt I logged: It attempts to inject PHP code so it can be easily executed remotely (and game over for the admin!)
For the more curious, Tamer Zoubi explains the nature and exploitation of this bug.
17 Oct 2014 4:24pm GMT