Systemd and containers [LWN.net]

By Jonathan Corbet
June 10, 2015

As Lennart Poettering noted at the beginning of his LinuxCon Japan talk, containers are "all the rage" these days. He was there to talk about how systemd works with containers — on both the inside and the outside. The systemd developers believe that containers should be a core part of an operating system, a feature that is provided out-of-the-box, rather than being an add-on. The container concept should be integrated all the way through the operating system. This idea, Lennart admitted, is not new; it also characterized the Solaris Zones implementation.

Systemd development is also driven by the idea that the operating system running inside a container should be as similar as possible to that running outside. Applications should not care whether they are running inside a container or not; the operating system should hide the differences between those two settings. Lennart called this concept "integrated isolation." There is isolation in that the container should appear to be its own host, but there should be full integration with the real host; a system-log query, for example, should be able to return results from the host, from one or more containers, or all of the above.

The Docker system, Lennart said, wants to have a single tenant running in each container. Systemd takes a different approach. Daemons that run on the host, for example, should generally run within the container as well.

There are a number of other overriding principles that drive systemd container development. The core system should be minimal, without a lot of options for users to wade through — but the door should be open for alternatives when the need arises. The focus should be on getting the low-level parts right. "No hacks"; the implementation should be clean. That is why Btrfs is used with native systemd containers rather than adding the logical volume manager to the mix. New standards should not be created when standards already exist; thus, for example, systemd doesn't include its own packaging system since Docker and rkt already exist. Most systemd testing is done inside containers; that simply makes life easier, since it's no longer necessary to reboot the system for each testing cycle. Finally, systemd is not focused on cluster-wide orchestration; instead, it provides the building blocks that allow others to create solutions at that level.

The core of the systemd approach to containers is a daemon called systemd-machined; it serves as a registry for containers running on the system. Other tools that have container awareness integrate with systemd-machined to get their job done. Thus, the systemctl command, when given the -M option, will run a command in an arbitrary container. The -r option causes services running in containers to be listed as well. There is a list-machines subcommand to create a list of containers along with some health status. Other command-line tools, including loginctl, systemd-run, and journalctl, also understand the -M option. The machinectl command-line tool can be used to log into or stop a container. And so on.

Work has been done to integrate with other system tools as well. There is an option to the ps command to see which container owns any given process. Gnome-system-monitor has been extended in similar ways. The name service switch (NSS) subsystem has been enhanced with a module to do hostname resolution for containers. The sd-bus IPC library is container-aware. Importantly, all of these mechanisms work with the various container-management systems available on Linux; they are not limited to systemd's containerization mechanism.

That mechanism is built around systemd-nspawn, a simple container manager. The rkt container system was built around systemd-nspawn at the lowest levels. It is a minimal system which, naturally, integrates with systemd-machined. All it needs is a directory full of operating-system files and it will be able to boot from there. It can also boot raw disk images, the same ones that work with KVM or on bare metal. So, for example, Fedora Cloud images work with systemd-nspawn.

It can also be set up to provide "containers as a service." Each container can be a normal systemd service, meaning that all of systemd's resource-management and process-management features are available.

One of the newer tools is systemd-networkd, added about one year ago. It adds a network-configuration mechanism that, Lennart said, is "minimal" but "really powerful." A systemd-networkd daemon running on the host will, when a virtual Ethernet tunnel appears for a container, pick an IP range for the container, run a DHCP server for it, set up IPv4LL, set up network address translation, etc. When running in the container, instead, it will launch the DHCP client and perform IPv4LL setup. The end result is that networking for containers just works with no additional configuration needed.

Another recent addition is systemd-resolved, which does central hostname resolution. It is a centralized daemon, avoiding many of the hassles that come with NSS resolution; in particular, it maintains a single, global cache. There is no longer a need to run a resolver in each application which, among other things, should reduce the attack surface of the system. Lookups with LLMNR are set up by default.

The systemd-import tool can import and export container images. It understands simple formats like tarballs and raw disk images; it can also import from (but not export to) the Docker format. This tool is typically used via the machinectl pull-raw command to get container images off the net. These images can then be booted directly with systemd-nspawn.

Lennart closed the session with a brief discussion of the concept of stateless systems. These systems have everything they need to boot in /usr; other directories, including /etc and /var, are created on the first boot. With such systems, a factory reset is easily achieved by removing everything except /usr. To achieve a truly stateless system, one just has to always boot in this manner. Stateless systems are useful for containers, since it is possible to instantiate a lot of them and have them set themselves up on the first boot. A single /usr image can be used as a golden master image, making for easy centralized updating. The stateless systems idea is relatively new, but the systemd developers are hoping to push distributors in that direction.

Lennart's slides [PDF] are available for the curious.

[Your editor would like to thank the Linux Foundation for funding his travel to LinuxCon Japan]

Index entries for this article
Conference	LinuxCon Japan/2015

to post comments

Systemd and containers

Posted Jun 11, 2015 8:26 UTC (Thu) by gfa (guest, #53331) [Link] (16 responses)

this time i think systemd does too much. *i don't want to flame* but dnsmasq is already here and working fine, why does systemd implement it's own dhcp server?

i think this time systemd is suffering from NIH syndrome

Systemd and containers

Posted Jun 11, 2015 9:59 UTC (Thu) by cortana (subscriber, #24596) [Link] (11 responses)

Among other things, dnsmasq has no idea about how to map different upstream nameserver configurations to currently active network connections. A really nice feature of systemd-resolved is that names are resolved separately on each of the currently active connections, and the results are merged. So connecting to a VPN no longer needs to hijack your entire internet connection--it can now just be used to give you access to a particular network, without interrupting traffic that shouldn't flow through it.

Systemd and containers

Posted Jun 11, 2015 10:14 UTC (Thu) by gfa (guest, #53331) [Link] (9 responses)

of course it does

dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap50303112-34 --except-interface=lo --pid-file=/$RANDOM.pid --server=8.8.8.8 --dhcp-hostsfile=/tmp/1c83334d-7896-4b1d-9381-26108295f89d/host --addn-hosts=/tmp/addn_hosts --dhcp-optsfile=/tmp/opts

this way dnsmasq will bind exclusively to an interface (tap50303112-34 ) and will use 8.8.8.8 as dns server for that interface. more complex things can be done

anyway is good to have a choice

Systemd and containers

Posted Jun 11, 2015 17:33 UTC (Thu) by kleptog (subscriber, #1183) [Link] (6 responses)

I think you misunderstood. The active connections in this case are for example a VPN to your work and a VPN to your Uni. So when asked to resolve a domain resolved asks each of the upstream nameservers (at your work and at Uni) and merges the results. I don't think dnsmasq can do that and your example certainly doesn't (it sends everything to 8.8.8.8).

Systemd and containers

Posted Jun 11, 2015 18:00 UTC (Thu) by cuviper (subscriber, #56273) [Link] (5 responses)

You can do split networks with dnsmasq though, as NetworkManager will do with the dnsmasq plugin. For example I get a something like "dnsmasq --server=/redhat.com/$VPN_DNS --server=$ISP_DNS", so all redhat.com queries go over the VPN, and the rest go to my ISP. That seems better than "ask everyone and merge" that you describe.

Systemd and containers

Posted Jun 11, 2015 22:42 UTC (Thu) by rahvin (guest, #16953) [Link] (4 responses)

The method you describe would require that you configure every time you change connection what connections go over what links. This can become exceedingly micromanaging and drive someone nuts. The systemd method ensures that you always get the results regardless of what links are up or active. As long as names don't overlap that is, if you have overlaps in names the systemd method would be a resolv nightmare.

Systemd and containers

Posted Jun 11, 2015 22:45 UTC (Thu) by cuviper (subscriber, #56273) [Link] (3 responses)

Yeah, it's not something I'd want to configure manually, but NetworkManager does it for me.

Systemd and containers

Posted Jun 12, 2015 8:16 UTC (Fri) by anselm (subscriber, #2796) [Link] (2 responses)

NetworkManager is a useful but quite complicated piece of software, and adding potentially several instances of dnsmasq into the mix isn't going to make things more straightforward. It would be useful to be able to deal with as many of the standard use cases as is reasonable with systemd-networkd (and if it plays well with containers, so much the better) and reserve the extra complexity of NetworkManager for those situations where it is actually needed (like dealing with lots of different wireless networks).

Systemd and containers

Posted Jun 18, 2015 8:07 UTC (Thu) by dakas (guest, #88146) [Link] (1 responses)

NetworkManager is a useful but quite complicated piece of software,

So does systemd differ by being not useful or by being not complicated? I don't quite see the point you try to make against this being NIH syndrome.

Systemd and containers

Posted Jun 18, 2015 9:08 UTC (Thu) by anselm (subscriber, #2796) [Link]

There are lots of systems that profit from being based on systemd but have no conceivable need for NetworkManager (mostly because NetworkManager's strength is dealing with a changing network environment, while these systems may be sitting firmly on a desk or in a rack somewhere). It makes sense to investigate whether such systems could use something simpler than NetworkManager+dnsmasq.

Systemd and containers

Posted Jun 20, 2015 14:18 UTC (Sat) by dakas (guest, #88146) [Link] (1 responses)

anyway is good to have a choice

The systemd universe is about not having choices. It's all or nothing.

Systemd and containers

Posted Jun 20, 2015 14:19 UTC (Sat) by anselm (subscriber, #2796) [Link]

Go back under your bridge, troll. This has been debunked so many times it is no longer funny.

Systemd and containers

Posted Jun 15, 2015 9:58 UTC (Mon) by alan (subscriber, #4018) [Link]

Instead of implementing a dhcp server, was any effort made to reach out to dnsmasq developers to add the additional support needed? If not then this is definitely NIH syndrome, reimplementing a service that gives you 95% of what you need without investigating what is necessary to get support for that additional 5%.

Systemd and containers

Posted Jun 11, 2015 11:17 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (2 responses)

dnsmasq does not support LLMNR which is useful for truly stateless configs using local link addressing.

Systemd and containers

Posted Jun 11, 2015 21:44 UTC (Thu) by luto (subscriber, #39314) [Link] (1 responses)

But dnsmasq would allow *.local (or whatever) to be forwarded to an LLMNR resolver.

There's one problem: for link-local applications, client software (especially on IPv6) needs an ifindex or other scope indicator. We don't have that using just resolv.conf-based mechanisms. I think that should be added independently of systemd-resolved, though.

Systemd and containers

Posted Jun 13, 2015 13:34 UTC (Sat) by grawity (subscriber, #80596) [Link]

I remember spending some time with that. Both systemd's libnss_resolve, and (I think) Avahi's libnss_mdns, do return the scope index. Unfortunately, glibc throws it away.

(libnss_dns of course doesn't return the scope because it doesn't know the scope.)

Systemd and containers

Posted Jun 11, 2015 13:21 UTC (Thu) by charlieb (guest, #23340) [Link]

This time? Where have you been?

Systemd and containers

Posted Jun 11, 2015 17:08 UTC (Thu) by xtifr (guest, #143) [Link] (16 responses)

In /usr/? I don't want "everything I need to boot" in /usr/! I want everything I need to complete at least the first stage of booting in /bin/, /sbin/, and /lib/. In other words, I want at least enough to get a basic shell launched to be on the root partition, and all the add-ons and fripperies and applications on a separate /usr/ device.

I realize this is somewhat old-fashioned and perhaps a bit naive, but I still think it's an ideal system even with modern hardware. A small root partition (as people used to have in olden times) can now be located on fast (e.g. flash) storage, with the bulk of the system remaining on slower-but-cheaper storage.

Of course, it's possible this isn't inconsistent with the basic idea; if the generic boot system on / is actually shared between the containers, then the container-specific apps can all be in /usr/, and everything's hunky-dory. But it's not clear to me that that's what he's talking about.

Systemd and containers

Posted Jun 11, 2015 17:29 UTC (Thu) by yokem_55 (subscriber, #10498) [Link] (4 responses)

Systemd hasn't supported a seperate /usr without an initrd mounting it at boot time for quite a while...

Systemd and containers

Posted Jun 11, 2015 18:54 UTC (Thu) by davidstrauss (guest, #85867) [Link] (3 responses)

> Systemd hasn't supported a seperate /usr without an initrd mounting it at boot time for quite a while...

And that continues to be a restriction from other tools, not systemd. systemd just warns because a split /usr tends to cause breakage in modern systems (but again, not because of systemd).

Systemd and containers

Posted Jun 11, 2015 19:36 UTC (Thu) by xtifr (guest, #143) [Link] (2 responses)

Yes, I know it's a problem with a lot of modern systems (and I know it predates systemd). I just wish it were being treated as a bug, rather than encouraged and reinforced.

Systemd and containers

Posted Jun 11, 2015 19:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Why? What's the point?

During the Bad Old Days the minimal /boot was used for RAID assembly (if /usr was on RAID) or for error recovery. Both these duties are now taken over by initrd, which usually contains a minimal Busybox environment or something similar.

Systemd and containers

Posted Jun 11, 2015 20:41 UTC (Thu) by davidstrauss (guest, #85867) [Link]

> Yes, I know it's a problem with a lot of modern systems (and I know it predates systemd). I just wish it were being treated as a bug, rather than encouraged and reinforced.

The warning systemd creates isn't intended to be normative any more than a sign on a highway warning that a bridge may be icy is normative. There's a difference between having a desired state versus warning that other states have known issues.

Systemd and containers

Posted Jun 11, 2015 18:00 UTC (Thu) by raven667 (subscriber, #5198) [Link] (10 responses)

Everything that is needed to complete the first stage of booting, such as mount and fsck and a shell, needs to go in the initial ramdisk and get loaded by the firmware/bootloader if you are going to have the flexibility to support all the different ways that a root filesystem can be mounted (iSCSI, NFS, LVM, encrypted, SCSI, SATA, USB, or a combination with loadable kernel modules, etc.) or have the tools to fix a broken filesystem. The firmware already has to be capable of loading the kernel image from somewhere, by re-using this mechanism to get all the modules and boot strapping tools, you aren't taking on any additional complexity or risk which makes the system more robust.

So the best technical mechanism to accomplish the goals you describe, of having a separate, simpler, bootstrapping system, is to put everything in the ramdisk that the firmware can load without needing the OS to be at all functional. Once you've put the bootstrapping tools in the ramdisk the seperation of /bin vs. /usr/bin no longer serves any function so you can reduce complexity by putting everything in /usr/, once you've put everything in /usr you have one clean hierarchy where all the executable code lives, that can be mounted seperately if you wish without the possibility of breakage. It's the clean seperation of configuration and mutable data from code which makes containers and stateless systems workable without getting buried under the kludgy hacks that swamped previous iterations of this idea.

Systemd and containers

Posted Jun 12, 2015 4:58 UTC (Fri) by bandrami (guest, #94229) [Link] (4 responses)

So what does having /usr to begin with gain you in that scenario? Why not just put everything in /bin and /lib (and, hell, /include, /share, and /local if needed) and just skip out on /usr entirely?

Systemd and containers

Posted Jun 12, 2015 8:10 UTC (Fri) by anselm (subscriber, #2796) [Link]

You only need to mount one file system to get the whole kit and caboodle (which is convenient for containers or remote storage) and your root directory isn't “polluted” by lots of names.

Systemd and containers

Posted Jun 12, 2015 8:19 UTC (Fri) by smcv (subscriber, #53363) [Link]

Recent proponents of merging the root filesystem with /usr initially thought this too, but came to realise that unifying into /usr made more sense than unifying into / - the lib, libexec, share, bin, sbin directories have more in common with each other than with anything else that has traditionally been at the top level.

/usr is not meant to change, ever, except during OS upgrades/package installations (and perhaps installations to /usr/local if you use that); so it can normally be mounted read-only, and if you're using something like OSTree, all of /usr should change atomically as a single unit. The "merged /usr" model does support a separate /usr filesystem, if the initramfs mounts it.

https://wiki.freedesktop.org/www/Software/systemd/TheCase... mentions some other possibilities, like a shared /usr between machines that have the same architecture and package-set (admittedly this makes more sense on OSs like Fedora, where services are normally installed but disabled by default, than on Debian derivatives, where unwanted services are normally not installed).

Systemd and containers

Posted Jun 12, 2015 9:35 UTC (Fri) by Kamilion (subscriber, #42576) [Link] (1 responses)

... Nneeeggh! I don't really want all those directories cluttering up my /.

I don't want /bin, I don't want /sbin, I don't want /lib, I don't want /share, I don't want /local, and I certainly don't want /include.

It's kind of a shame that sysfs took over /sys otherwise I'd really push for just changing /usr's name to /sys.
But heck, people can't even agree on what /usr means today -- I keep getting told it's Unix System Resources, but to me it's always been the /usEr/ directory.

"I do not at all have the mind of a bully... in my mind bullies are intolerant of contrary opinion, domineering and rather cowardly. I would hope that none of those terms could be fairly used in describing me." -- Conrad Black

But that would be one of those changes that breaks the world because too many things rely on /usr/bin/<something>.

Thankfully on a lot of modern systems, /bin, /sbin, and /lib are just links to their /usr counterparts. One day they'll dissipate.

Eventually the old ash/bash/perl scripts will get replaced by python3, rust, and go by the distros. Maybe even Swift if it really takes off. I'm kind of skeptical about that one. Coreutils installations will start to be rare as whatever default dynamic language on the installation medium (python3) handles doing all the unixy regexes and transforms without shelling out of process...

X will go back to being an immediate-mode drawing protocol and DRI will be a laughable thing of the past once the wayland ecosystem solidifies. Most of the application toolkits have already supported it for quite a while; then xwayland will handle loading the required xorg components when necessary, like when I want to play a good old fashioned game of xevil. Once enough time passes, xorg won't even be a default installed component anymore and it'll be like "whaaat, I have to go get xorg to run this? Pffft! I'm not going through that hassle, googleing for a native rebuild..." kinda like xQuartz on a mac...

pixman and glamor will keep older fixed function graphics adapters reasonably operational, all the way back to the good ol' ATI mach64 and matrox G200w (Darn you, integrated server KVM devices!) and various framebuffer devices, including spitting SPI out to a 320x240 touchscreen on a Pi's GPIO header.

"I always keep a firewall between my own travails and my perception of public-policy issues; otherwise I would retain no credibility as a commentator." -- Conrad Black

The internet is changing. Unix is changing. If you're not cool with that; Slackware and Linux From Scratch can always use the help! (Although LFS has a systemd version which may become standard...)

Lennart's swiped the three most useful apple services, mdns/bonjour/avahi, coreaudio/pulseaudio, launchd/systemd, ripped them to chunks, and had a go at putting together a lego tower with the results.

"There are some people whose opinion I value and respect and it would be very bothersome if I forfeited their respect. But the general public? I'm not preoccupied with the opinions of others." -- Conrad Black

I've played with that lego tower, and honestly, I like it a lot better than the old duplo sysvinit set.
Some of it gets a little strange, like finding a block of lego technics pieces in with your classics.

"Containers in my init system? It's more common than you think." -- Adapted internet meme

Ubuntu's wiki actually put together a great little mapping page between the upstart features and the systemd features:
https://wiki.ubuntu.com/SystemdForUpstartUsers
It's short, it's sweet, and it's mostly useful for users of other distros as well just to get a quick cheat sheet on systemd.

Systemd and containers

Posted Jun 19, 2015 22:05 UTC (Fri) by flussence (guest, #85566) [Link]

> pixman and glamor will keep older fixed function graphics adapters reasonably operational, all the way back to the good ol' ATI mach64 and matrox G200w

If they get glamor's GLSL shader engine to work on those OpenGL 1.4 chips, when even my GL2.1-capable i945 refuses to start X with it enabled, I'll be impressed. Good luck with that.

Systemd and containers

Posted Jun 15, 2015 14:03 UTC (Mon) by dps (guest, #5725) [Link] (4 responses)

Anybody that has had significant hard disc problems and other complex problems knows that a functional system that does not require a large filesystem, like /usr, to work is worth a lot when the chips are down. Sane size initial ram discs just don't and can't provide that but small root filesystems with /bin and /lib can. The tools you need to fix your initial ram disc are unlikely be available if that is all you have.

If I want an aggressively minimised box then I just don't use systemd: kernel modules, dbus, udev and network manager are all bloat which stripped down firewall machine with fixed hardware does not need and therefore should have. Anything that requires them should be rejected when there is a reasonable alternative that does not. I might actually want some of the features on offer on a desktop but have yet to find any use for dbus whatsoever. It is possible that the fact I am neo-luddite and don't use linkedin, facebook, twitter, GUI file system interfaces, cloud services, etc is a sufficient explanation for that.

I also find systemd has significant problems when /var is a separate filesystem because some things it puts in /var suffer an existence failure when that filesystem is mounted. systemd militates against having /usr on a separate partition which is mounted read only, making the desired separation of fixed and mutable data harder. If everything was in /usr then I could not boot, period: systemd dies and I have to mount /usr and /var manually for it.

Initial ram discs which duplicate tools that are installed on a box, and are hard to update, *are* kludgy hacks.

Systemd and containers

Posted Jun 16, 2015 17:16 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> Sane size initial ram discs just don't and can't provide that but small root filesystems with /bin and /lib can.

Why make an arbitrary limit on the ramdisk to exclude it from being used as a rescue system? The initial ramdisk/ramfs mechanism is robust enough that it can load an entire OS installer/upgrader image. It seems that you've created a tautology by redefining sanity as not having a useful ramdisk to prove that ramdisks aren't useful.

> fact I am neo-luddite

Well, OK then, you can use what ever system you like but when building a system to distribute to others, that has to be flexible and robust enough to handle whatever crazy new thing they try to do with the system, features like a complete initial ramdisk able to mount anything, are kind of a requirement and can't just be defined away.

Sure, if you only ever had to support one use and one hardware then you could remove a ton of abstractions and have a greatly simplified system but that's not something you can do if you are distributing systems for others to use in any environment.

> If everything was in /usr then I could not boot, period: systemd dies and I have to mount /usr and /var manually for it.

You pretty much have to have all filesystems mounted before you exit the initial ramdisk and start services in the live root filesystem, if you try to chroot into a system which is half missing then it won't work.

> Initial ram discs which duplicate tools that are installed on a box, and are hard to update, *are* kludgy hacks.

Initial ram disks provide a mechanism for the tools on your system to be accessible with a minimum of fuss because they are loaded by the firmware so that your filesystem is fully ready to go when you pivot into it and you aren't trying to run on a half-borken system. There is a policy in the kernel of pushing setup into user space of anything which can be done by userspace so you need to have a userspace capable of setting everything up, loading modules, mounting filesystems, iteratively as busses come online exposing new hardware, before you can transition into your root filesystem.

Systemd and containers

Posted Jun 17, 2015 12:26 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Why make an arbitrary limit on the ramdisk to exclude it from being used as a rescue system?

There is a limit: initial ramdisks are not swappable (unlike, say, tmpfs). (This is why they are generally cleaned out and thrown away when switching to the initial root, so as not to waste precious physical RAM).

However, on a rescue disk it's not like you can rely on swap anyway, and on modern systems this is not much of a limit: I've seen ramdisks that contain entire compiler toolchains and even kernel source trees for building needed kernel modules on command. You wouldn't want to keep that lying around in RAM on a general-purpose system (can you imagine how big the initrd/linked in initramfs must be?), but in a rescue disk it's fine.

Systemd and containers

Posted Jun 18, 2015 0:24 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

> There is a limit: initial ramdisks are not swappable (unlike, say, tmpfs). (This is why they are generally cleaned out and thrown away when switching to the initial root, so as not to waste precious physical RAM).

I have seen code which switches root to the initramfs and runs a binary from there on shutdown. Wouldn't that mean that the initrd needs to be kept resident all the time?

Systemd and containers

Posted Jun 18, 2015 8:38 UTC (Thu) by mchapman (subscriber, #66589) [Link]

> I have seen code which switches root to the initramfs and runs a binary from there on shutdown. Wouldn't that mean that the initrd needs to be kept resident all the time?

No, the initramfs can be repopulated upon shutdown.

For example, with Dracut this is done by dracut-shutdown.service, which is pulled in by systemd's shutdown.target unit. See https://www.kernel.org/pub/linux/utils/boot/dracut/dracut... for details.

Systemd and containers

Posted Jun 13, 2015 2:09 UTC (Sat) by dlang (guest, #313) [Link]

It's ironic to hear systemd folks say that new standards should not be created where there are existing ones. They have seemed to be the kings on NIH and creating new 'standard' ways of doing things.

I strongly disagree that every daemon that runs on the host should run in every container as well. That leads to a large amount of unneeded duplication, and probably some security issues over time as well. If the software running in the container doesn't need functionality, it shouldn't be there. For some daemons, it's all or nothing, if they need even a single feature they need the whole thing, but for many that's not the case and you can eliminate the vast majority of the features/complexity/potential bugs from inside the container without hurting the container functionality.

Systemd and containers

Posted Jun 15, 2015 21:11 UTC (Mon) by dowdle (subscriber, #659) [Link]

Here's a video of the same talk (pretty much) from an earlier conference (April 2015):
https://www.youtube.com/watch?v=d4SwL2t5Yh4

This model of containerization is a grand error

Posted Jun 18, 2015 14:45 UTC (Thu) by ksandstr (guest, #60862) [Link] (17 responses)

Long story short, installing applications as self-contained mega-blobs which get deduplicated by filesystem magic is a bad idea because it makes security holes (e.g. Heartbleed, GRIME) persist per blob. To contrast, in traditional Unix-alikes those OpenSSL bugs were patched per OS image because OpenSSL is a shared library; and only binaries that linked it statically required dedicated upgrading. For the tin-foil types in audience, this is the ideal situation for the NSA and other cybercrooks: in the brave new Pöttering world, exploitable holes persist beyond automatic package management's capacity to repair.

To achieve parity with regard to ease of maintenance, package management must reach into each container, perhaps with a heavy layer of metadata in each; or PM must become per-containee with an equivalent high-level interface to the container. Shortly after implementing this[0] Pöttering will finish (topographically speaking) swallowing himself like a German ouroboros, and disappear without a trace.

The purpose of this overall desk-top inner-system exercise has gone underdiscussed, beyond it being the fashions ("all the rage") at the moment. My hypothesis is that Red Hat is still entertaining the idea that all of GNU/Linux should be reworked into an App Store[1] platform: the opportunities for increased control, parlayed into cashflow, are currently going unexploited outside of the respective installed bases of Apple, Microsoft, and Google. Fundamentally, such development is undesirable for everyone because it makes the users[2] of software less capable of modifying mega-blobs they've received from the Company Store, and operating their modified versions transparently; this makes the stated current direction of systemd inimical to the Four Freedoms.

In closing, systemd must be destroyed.

[0] or (more likely) some typically overengineered facsimile for novelty's sake
[1] and like, that shark got jumped over before "let's have an app store for home automation widgets", i.e. sometime in the late aughties at the latest
[2] such as you!

This model of containerization is a grand error

Posted Jun 18, 2015 15:46 UTC (Thu) by peter-b (guest, #66996) [Link] (13 responses)

Poettering doesn't contain a "ö".

This model of containerization is a grand error

Posted Jun 18, 2015 18:07 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

It's a shibboleth to mark anti-Lennart fanbois.

This model of containerization is a grand error

Posted Jun 19, 2015 0:59 UTC (Fri) by raven667 (subscriber, #5198) [Link] (4 responses)

You are right, its a dog whistle to make your feelings clear to like minded people and the practice of giving nicknames can be a way to assert dominance over someone by controlling something so fundamental as the persons name.

This model of containerization is a grand error

Posted Jun 19, 2015 8:52 UTC (Fri) by anselm (subscriber, #2796) [Link] (2 responses)

I think that in order to “assert dominance” over Lennart Poettering you would have to do a bit more than mis-spell his name.

This model of containerization is a grand error

Posted Jun 19, 2015 17:13 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

It usually isn't effective in creating submissiveness on the person its being said to, it's more about the ego of the person doing the saying, demonstrating that what they say is under their own control and they can be rude with little consequence. That is something which can puff up a weak ego, if only slightly.

This model of containerization is a grand error

Posted Jul 4, 2015 14:48 UTC (Sat) by ksandstr (guest, #60862) [Link]

How about instead of this generally passive-aggressive mumbling, you say how you really feel? You could even go as far as to refute my points directly.

Failing that, you could niggle at my insubtle hypothesis that eventually Pöttering will full-bodily enter his own fundament and thereby vanish. Or you could take issue with the hyperbole referencing Brave New World, a book concerning dystopian conformity; or the company store, a symbol of dire working-class exploitation in pre-New Deal America. Certainly there are individual phrases or words that could similarly serve as points of deflection, such as the millennia-old "foo must be destroyed" statement of creed[0], or my framing the putative motives of systemd "fanbois"[1] as motivated by fashions (i.e. positive peer pressure) alone.

That's assuming that the capacity for such refutation and/or secondary niggling beyond a variant spelling exists, that is.

Until then, I wish you a good day.

[0] entirely pre-empting the "dog whistle" shibboleth argument, in case this went by under the radar
[1] that's class right thur

This model of containerization is a grand error

Posted Jun 21, 2015 11:22 UTC (Sun) by misc (subscriber, #73730) [Link]

I agree with your point, I would go as far as saying that it can extend to more than persons ( example, a company in Seattle ).
Or do we just personify the said companies and therefore treat then as people, still not sure on that one.

This model of containerization is a grand error

Posted Jul 4, 2015 14:26 UTC (Sat) by ksandstr (guest, #60862) [Link] (6 responses)

But it does. In German the umlaut is regularly transcribed as an "oe" (or "ae" for ä). To contrast, in Swedish an "ö" would be ASCIIfied by stripping the diacritic altogether, which is common in e.g. E-mail. I'm using the non-canonical spelling because my keyboard has that letter, because "oe"'s pronounciation is that of "ö", and to avoid bolstering the marketing effect of someone's name starting with "poet"-- because who knows, perhaps Americans are genuinely that dumb. On the other hand Pöttering's first name is already a term of abuse, so there's good reason to avoid that as well (beyond unwarranted familiarity).

As for these other pop-psychology Internet shrink hypotheses about "asserting dominance", piffle! We are not cats and dogs.

This model of containerization is a grand error

Posted Jul 4, 2015 14:39 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Lennart Poettering is not from Germany.

This model of containerization is a grand error

Posted Jul 4, 2015 15:17 UTC (Sat) by ksandstr (guest, #60862) [Link]

Quoth the Wikipedia:

Lennart Poettering (born October 15, 1980) is a German computer free software programmer [...]

Whatever your implied argument on his current nationality, the origins of his name are German, from which its spelling and pronounciation follow. That is the point under argument.

This model of containerization is a grand error

Posted Jul 4, 2015 19:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (3 responses)

> But it does.

No. Lennart never spells it with 'ö' which makes it wrong. I'm sure my last name had an umlaut at some point too, but I'd still spell it 'oe' anyways today. It isn't used as such in any official documentation or by me, so it is wrong to use it. That is the case here too (AFAIK).

This model of containerization is a grand error

Posted Jul 4, 2015 23:46 UTC (Sat) by ksandstr (guest, #60862) [Link] (2 responses)

>No. Lennart never spells it with 'ö' which makes it wrong.

Interestingly the Wikipedia article on German orthography agrees with this reading. It appears you'll have to read it as a disrespectful stab up 'til now, and that I'll be avoiding the name altogether in the future. Call it going from petulance to erasure.

Who'd've thunk German was without consistent transcription rules.

This model of containerization is a grand error

Posted Jul 5, 2015 3:39 UTC (Sun) by viro (subscriber, #7872) [Link]

Oh, for pity sake! I loathe the guy, but this is ridiculous. Names are arbitrary tags. Etymology doesn't matter - it's not as if they had any meaning other than identifying the object they apply to. He gets to choose the orthography; insisting upon a different spelling simply demonstrates that the person insisting is a pretentious wanker.

*plonk*

This model of containerization is a grand error

Posted Jul 5, 2015 14:23 UTC (Sun) by anselm (subscriber, #2796) [Link]

Who'd've thunk German was without consistent transcription rules.

What, like English?

In German you can generally spell “ö” as “oe” if you don't have umlauts. But that doesn't mean every “oe” you encounter was originally an “ö”, or that you are always free to do the reverse replacement, especially in the names of people or places. For example, you would never get away with “Göthe” in place of “Goethe” (Germany's most famous poet) outside of the realm of lowbrow comedy. Transcription rules don't really enter into this.

This model of containerization is a grand error

Posted Jun 21, 2015 11:48 UTC (Sun) by misc (subscriber, #73730) [Link] (2 responses)

In the end, it all depend on how and what you put in the containers. Nothing would prevent automation of containers rebuilding if you assemble them from the existing distribution infrastructure. The problem is one of policy, not of technology, since tar.gz, static compiling, source code bundling or rpm/deb/whatever all suffer from the risk of having a component not cleanly separated. And that's not theorical, since that's why Fedora mandate to not bundle anything ( unless exceptions ). Debian do also have the same policy, following a zlib problem back in the days.

On the desktop side, getting application containers from Fedora rawhide running on a centos 6 might solve the issue of people wanting latest version of something without upgrading to rawhide. It doesn't solve every problem, likely bring some news, but that's worth testing and doing. Companies handling lots of traffic ( facebook, google, twitter among others ) have been using that since years on server side, so I think they would have noticed security issues.

And in a true UNIX lore fashion, no software but one should deal with SSL, since this otherwise would violate the idea of doing one thing and doing it right. So application containers push for more of the UNIX paradigm on the server side.

This model of containerization is a grand error

Posted Jun 24, 2015 4:06 UTC (Wed) by dlang (guest, #313) [Link]

> And in a true UNIX lore fashion, no software but one should deal with SSL, since this otherwise would violate the idea of doing one thing and doing it right.

you completely misunderstand the Unix "do one thing and do it well" mantra. That doesn't in any way prohibit you from having multiple things that do the one job, it just means that one tool shouldn't try to do lots of different jobs.

This model of containerization is a grand error

Posted Jul 4, 2015 15:13 UTC (Sat) by ksandstr (guest, #60862) [Link]

On the contrary, the question is not what I put in a container, or what the GNU/Linux distribution puts in one. Rather, containers used in this fashion create an interface for distribution-independent blobs from (tautology aside) outside any given distribution and its anti-bundling policies. Such blobs will invariably be bundled with their dependencies: how could it even be otherwise given filesystem separation to the degree of "soft VM"?

In the absence of standardization for intra-container automation (as stated in the "PM must reach" paragraph), this leaves users of security-broken web-download software with two workable options: either they wait for the container publisher's update (which may come in the form of a major version update, perhaps for a cost), or they build the fixed container themselves. Obstacles to the latter can be many, such as the recent Firefox bundling of in-browser DRM plugins; and alternatives to these two all boil down to bending over for the NSA.

The effect of containerzation in the manner proposed in the main article is that Debian, Mint, Gentoo, etc. users will be as ripe a target market for Linux desktop app stores as Red Hat's customer base is for its RPM repository. Iterated, this development converges in the death of the individual distribution in favour of an effective monoculture as preferred by proprietary software companies. With it comes the death of Free Software.

In closing, systemd must be destroyed.