Ever since I read about
sytemd-networkd being in the making I was looking forward to try it out. I kept watching for the package to appear in Debian, or at least ITP bugs. A few days ago, by accident, I noticed that I already have systemd-networkd on my machine: It is simply shipped with
the systemd package!
My previous setup was a combination of
ifplugd to detect when I plug or unplug the ethernet cable with a plain DHCP entry in
/etc/network/interface. A while ago I was using
guessnet to do a static setup depending on where I am, but I don t need this flexibility any more, so the very simple approach with
systemd-networkd is just fine with me. So after stopping
ifplugd and
$ cat > /etc/systemd/network/eth.network <<__END__
[Match]
Name=eth0
[Network]
DHCP=yes
__END__
$ systemctl enable systemd-networkd
$ systemctl start systemd-networkd
I was ready to go. Indeed,
systemd-networkd, probably due to the integrated dhcp client, felt quite a bit faster than the old setup. And what s more important (and my main motivation for the switch): It did the right thing when I put it to sleep in my office, unplug it there, go home, plug it in and wake it up.
ifplugd failed to detect this change and I often had to manually run
ifdown eth0 && ifup eth0; this now works.
But then I was bitten by what I guess some people call the viral nature of
systemd:
sytemd-networkd would not update
/etc/resolve.conf, but rather relies on
systemd-resolved. And that requires me to change
/etc/resolve.conf to be a symlink to
/run/systemd/resolve/resolv.conf. But of course I also use my wireless adapter, which, at that point, was still managed using
ifupdown, which would use
dhclient which updates
/etc/resolve.conf directly.
So I investigated if I can use
systemd-networkd also for my wireless account. I am not using NetworkManager or the like, but rather keep
wpa_supplicant running in roaming mode, controlled from
ifupdown (not sure how that exactly works and what controls what, but it worked). I found out that this setup works just fine with
systemd-networkd: I start
wpa_supplicant with this service file (which I found in the
wpasupplicant repo, but not yet in the Debian package):
[Unit]
Description=WPA supplicant daemon (interface-specific version)
Requires=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=simple
ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I
[Install]
Alias=multi-user.target.wants/wpa_supplicant@%i.service
Then
wpa_supplicant will get the interface up and down as it goes, while
systemd-networkd, equipped with
[Match]
Name=wlan0
[Network]
DHCP=yes
does the rest.
So suddenly I have a system without
/etc/init.d/networking and without
ifup. Feels a bit strange, but also makes sense. I still need to migrate how I manage my UMTS modem device to that model.
The only thing that I m missing so far is a way to trigger actions when the network configuration has changes, like I could with
/etc/network/if-up.d/ etc. I want to run things like
killall -ALRM tincd and
exim -qf. If you know how to do that, please tell me, or answer over at
Stack Exchange.
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. :/
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 
Two days ago, 
Since systemd is now the default init system under Debian Jessie, it
got installed to my system and I had a chance to test it. The result is
disappointing: it does not work well with cryptsetup, so I am switching
back to SysV init and RC.The problem comes from the fact that I am using encrypted drives with
cryptsetup, and while this is correctly integrated with SysV, it just
sucks with systemd, where the passphrase prompt is mixed up with service
start messages, a bit like that (from memory, since I did not take a
picture of my system booting):
TL;DR: static version of 
Like 
It turns out that my recent woes with pbuilder were all due to 
It's past time I wrote about how Linaro's students fared in this
year's Google Summer of Code. You might remember me posting earlier in
the year when we
Early last year, I referred to a 