Re: [systemd-devel] systemd-nspawn trouble
On Sun, 17.05.15 17:30, Michael Biebl (mbi...@gmail.com) wrote: > 2015-05-15 22:16 GMT+02:00 Tom Gundersen : > > on-demand I agree with Lennart that it makes the most sense to simply > > unconditionally load the modules. If this is undesirable the solution > > should be to teach the kernel to auto-load the modules, not to expect > > the admin to figure out that explicit loading is required, IMHO. > > And now we expect that the admin figures out how to disable loading of > the iptables module, which isn't anymore obvious. Why would he do that? I generally think we should make things easy if we can, and hence work out of the box. But avoid the iptables module to be loaded is certainly not "making things work", it's the opposite, it is avoiding to make things work. Hence, it's much less interesting to me. > What I was suggesting was, that the iptables modules should only be > loaded on demand, i.e. when the firewalling functionality is actually > used. Lennart did argue, that he didn't want to do that within > networkd, since he didn't want to grant networkd that capability to > load modules and therefor to load the module unconditionally in PID 1. > But moving the modules loading out of networkd doesn't mean, it has to > be done unconditonally, see how we did it for > udev/kmod-static-nodes.service Note that effectively we just changed auto-loading of the iptables module from opt-in to opt-out, to make it behave more like most other modules. Previously it was never auto-loaded. Now it is by default loaded at boot, but you can still blacklist it with modprobe.conf files. This hence ensures behaviour is identical to modules that are auto-loaded via udev or via opening of a device node: for all kinds of modules the blacklist is now where you can turn off or on the module. That's certainly the friendliest way for admins to handle this... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Sun, May 17, 2015 at 5:30 PM, Michael Biebl wrote: > 2015-05-15 22:16 GMT+02:00 Tom Gundersen : >> on-demand I agree with Lennart that it makes the most sense to simply >> unconditionally load the modules. If this is undesirable the solution >> should be to teach the kernel to auto-load the modules, not to expect >> the admin to figure out that explicit loading is required, IMHO. > > And now we expect that the admin figures out how to disable loading of > the iptables module, which isn't anymore obvious. Out of interest, what is the 'regression' users would experience by having the iptables module loaded? Or is it just about the principle of not wanting to load a module unless it is actually used? > What I was suggesting was, that the iptables modules should only be > loaded on demand, i.e. when the firewalling functionality is actually > used. If so, this should be done by the kernel. > Lennart did argue, that he didn't want to do that within > networkd, since he didn't want to grant networkd that capability to > load modules and therefor to load the module unconditionally in PID 1. > But moving the modules loading out of networkd doesn't mean, it has to > be done unconditonally, see how we did it for > udev/kmod-static-nodes.service Hm, this is all about letting the kernel do the module loading lazily on-demand, so I'd be all for that, but then the kernel would need to learn how to do that for iptables first... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-05-15 22:16 GMT+02:00 Tom Gundersen : > on-demand I agree with Lennart that it makes the most sense to simply > unconditionally load the modules. If this is undesirable the solution > should be to teach the kernel to auto-load the modules, not to expect > the admin to figure out that explicit loading is required, IMHO. And now we expect that the admin figures out how to disable loading of the iptables module, which isn't anymore obvious. What I was suggesting was, that the iptables modules should only be loaded on demand, i.e. when the firewalling functionality is actually used. Lennart did argue, that he didn't want to do that within networkd, since he didn't want to grant networkd that capability to load modules and therefor to load the module unconditionally in PID 1. But moving the modules loading out of networkd doesn't mean, it has to be done unconditonally, see how we did it for udev/kmod-static-nodes.service -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, Apr 22, 2015 at 2:36 PM, Michael Biebl wrote: > 2015-04-22 14:26 GMT+02:00 Lennart Poettering : >> On Wed, 22.04.15 14:22, Michael Biebl (mbi...@gmail.com) wrote: >>> 2015-04-22 14:14 GMT+02:00 Lennart Poettering : >>> > On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: >>> >> 2015-04-22 13:57 GMT+02:00 Lennart Poettering : >>> >> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 >>> >> >>> >> Not everyone is using networkd or nspawn though, so loading this >>> >> module for everyone is a bit excessive. >>> > >>> > Well, then blacklist the module or don't build it at all. >>> >>> That's the wrong way around. >> >> Nah, I disagree. We do this for a number of modules now. I mean, we > > We currently do this static loading for unix, ipv6 and autofs4. > >> load tons of modules automatically, even if you don't use them. For >> example, my laptop always loads the bluetooth modules, even though I >> never used bluetooth. > > Those are all loaded on demand, not statically. I.e. we don't load the > bluetooth module for each and every user. We never require the admin to explicitly opt-in to loading any modules for the functionality we use. For hardware drivers, modules are unconditionally loaded when the hardware exists, for other modules the kernel is usually able to load them on demand (filesystems, netdevs, ...). In the cases where the kernel is not able to load modules on-demand I agree with Lennart that it makes the most sense to simply unconditionally load the modules. If this is undesirable the solution should be to teach the kernel to auto-load the modules, not to expect the admin to figure out that explicit loading is required, IMHO. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
Yes, I was referring to a container when using the name "vm". Sorry if I caused confusion with this, I used to run lots of real VMs and then moved those over to containers and still think of those services as virtual machines. On Mon, Apr 27, 2015 at 5:01 PM, Lennart Poettering wrote: > I figure we should teach journalctl -m to actually watch running > containers and accessing their journals directly, without requiring a > symlink in /var/log/journal. For ephemeral containers (which exist > purely during runtime), this sounds like the best option since we > shouldn't litter persistant file systems with objects that should not > persist. > > Added to TODO list. That would be super awesome! And you could get rid of some of those those --link-journal options. PS: Networking works more like I had expected now, but I am not sure what I changed. Maybe that was an issue with the arch packages or something. I did I reinstalled both the server as well as all the containers it runs a couple of times in the meantime. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Sat, 25.04.15 01:44, Tobias Hunger (tobias.hun...@gmail.com) wrote: > By the way: Is there a way to get the journal from a --ephemeral container? > > I had expected --link-journal=host to work, but --link-journal seems > to not be allowed in any way. I figure we should teach journalctl -m to actually watch running containers and accessing their journals directly, without requiring a symlink in /var/log/journal. For ephemeral containers (which exist purely during runtime), this sounds like the best option since we shouldn't litter persistant file systems with objects that should not persist. Added to TODO list. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Sat, 25.04.15 00:14, Tobias Hunger (tobias.hun...@gmail.com) wrote: > Hello, > > sorry (again) for the delay. I unfortunately can not check into this > as often as I would like:-( > > Lennart: Thank you for that patch, that does indeed fix my issue with > read-only machine images. > > The networking issue does work better when iptables are used. All I > needed to do was to make sure that packages from the VM are not > getting dropped in the forwarding chain. Is there a way for me to do > that automatically as interfaces to containers are created? I do not > want to just accept every machine talking to everything else. > Paranoia:-) This is currently not supported, but I figure we could add that. Added to the TODO list. > What I noticed though is that the VM has the google nameservers set > up. That came as a bit of a surprise: I had expected either the host > to be the only DNS server register (providing a DNS proxy) or at least > that the nameservers of the host will also be set in the VM. Is that a > know issue or are my expectations wrong? When you use the word "vm" you refer to "container"? (So far i used the name "vm" for full machine virtualization such as kvm or virtualbox, and "container" for same-kernel virtualization, such as nspawn). networkd does not proxy DNS. however, networkd does forward DNS configuration it learnt via DHCP. Also, nspawn by default actually copies /etc/resolv.conf from the host into the container at boot, though we probably should stop doing that... What does "networkctl status -a" say when run in the container? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
By the way: Is there a way to get the journal from a --ephemeral container? I had expected --link-journal=host to work, but --link-journal seems to not be allowed in any way. On Sat, Apr 25, 2015 at 12:14 AM, Tobias Hunger wrote: > Hello, > > sorry (again) for the delay. I unfortunately can not check into this > as often as I would like:-( > > Lennart: Thank you for that patch, that does indeed fix my issue with > read-only machine images. > > The networking issue does work better when iptables are used. All I > needed to do was to make sure that packages from the VM are not > getting dropped in the forwarding chain. Is there a way for me to do > that automatically as interfaces to containers are created? I do not > want to just accept every machine talking to everything else. > Paranoia:-) > > What I noticed though is that the VM has the google nameservers set > up. That came as a bit of a surprise: I had expected either the host > to be the only DNS server register (providing a DNS proxy) or at least > that the nameservers of the host will also be set in the VM. Is that a > know issue or are my expectations wrong? > > Best Regards, > Tobias > > > On Wed, Apr 22, 2015 at 5:00 PM, Lennart Poettering > wrote: >> On Wed, 22.04.15 16:31, Tobias Hunger (tobias.hun...@gmail.com) wrote: >> >>> On Wed, Apr 22, 2015 at 4:04 PM, Lennart Poettering >>> wrote: >>> > Well, if that's what it says, then yes. We can certainly add support >>> > for manipulating nft too, but so far the APIs fo that appeared much >>> > less convincing to me, and quite a bit more exotic. >>> >>> The user space tools for nft are much nicer than iptables, so I think >>> they do provide a significant benefit. I would appreciate not having >>> to go back to iptables:-) >>> >>> The exact command line I am running is this (straight out of systemctl >>> cat systemd-nspawn@vm.service, *THANKS* to whoever implemented that!): >>> >>> ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --ephemeral \ >>> --machine=vm \ >>> --network-veth \ >>> --bind=/mnt/raid0/data/ftp:/mnt/ftp >>> >>> /var/lib/machines is a normal read-write btrfs snapshot. vm is a >>> read-only snapshot. >>> >>> It starts fine when vm is read-write. >> >> OK, I think I fixed this now, please check: >> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=aee327b8169670986f6a48acbd5ffe1355bfcf27 >> >> Lennart >> >> -- >> Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
Hello, sorry (again) for the delay. I unfortunately can not check into this as often as I would like:-( Lennart: Thank you for that patch, that does indeed fix my issue with read-only machine images. The networking issue does work better when iptables are used. All I needed to do was to make sure that packages from the VM are not getting dropped in the forwarding chain. Is there a way for me to do that automatically as interfaces to containers are created? I do not want to just accept every machine talking to everything else. Paranoia:-) What I noticed though is that the VM has the google nameservers set up. That came as a bit of a surprise: I had expected either the host to be the only DNS server register (providing a DNS proxy) or at least that the nameservers of the host will also be set in the VM. Is that a know issue or are my expectations wrong? Best Regards, Tobias On Wed, Apr 22, 2015 at 5:00 PM, Lennart Poettering wrote: > On Wed, 22.04.15 16:31, Tobias Hunger (tobias.hun...@gmail.com) wrote: > >> On Wed, Apr 22, 2015 at 4:04 PM, Lennart Poettering >> wrote: >> > Well, if that's what it says, then yes. We can certainly add support >> > for manipulating nft too, but so far the APIs fo that appeared much >> > less convincing to me, and quite a bit more exotic. >> >> The user space tools for nft are much nicer than iptables, so I think >> they do provide a significant benefit. I would appreciate not having >> to go back to iptables:-) >> >> The exact command line I am running is this (straight out of systemctl >> cat systemd-nspawn@vm.service, *THANKS* to whoever implemented that!): >> >> ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --ephemeral \ >> --machine=vm \ >> --network-veth \ >> --bind=/mnt/raid0/data/ftp:/mnt/ftp >> >> /var/lib/machines is a normal read-write btrfs snapshot. vm is a >> read-only snapshot. >> >> It starts fine when vm is read-write. > > OK, I think I fixed this now, please check: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=aee327b8169670986f6a48acbd5ffe1355bfcf27 > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 16:31, Tobias Hunger (tobias.hun...@gmail.com) wrote: > On Wed, Apr 22, 2015 at 4:04 PM, Lennart Poettering > wrote: > > Well, if that's what it says, then yes. We can certainly add support > > for manipulating nft too, but so far the APIs fo that appeared much > > less convincing to me, and quite a bit more exotic. > > The user space tools for nft are much nicer than iptables, so I think > they do provide a significant benefit. I would appreciate not having > to go back to iptables:-) > > The exact command line I am running is this (straight out of systemctl > cat systemd-nspawn@vm.service, *THANKS* to whoever implemented that!): > > ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --ephemeral \ > --machine=vm \ > --network-veth \ > --bind=/mnt/raid0/data/ftp:/mnt/ftp > > /var/lib/machines is a normal read-write btrfs snapshot. vm is a > read-only snapshot. > > It starts fine when vm is read-write. OK, I think I fixed this now, please check: http://cgit.freedesktop.org/systemd/systemd/commit/?id=aee327b8169670986f6a48acbd5ffe1355bfcf27 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, Apr 22, 2015 at 4:04 PM, Lennart Poettering wrote: > Well, if that's what it says, then yes. We can certainly add support > for manipulating nft too, but so far the APIs fo that appeared much > less convincing to me, and quite a bit more exotic. The user space tools for nft are much nicer than iptables, so I think they do provide a significant benefit. I would appreciate not having to go back to iptables:-) The exact command line I am running is this (straight out of systemctl cat systemd-nspawn@vm.service, *THANKS* to whoever implemented that!): ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --ephemeral \ --machine=vm \ --network-veth \ --bind=/mnt/raid0/data/ftp:/mnt/ftp /var/lib/machines is a normal read-write btrfs snapshot. vm is a read-only snapshot. It starts fine when vm is read-write. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
> > > 2015-04-22 14:14 GMT+02:00 Lennart Poettering : > > > > > > Well, I really don't want to give networkd the caps for that, > > > sorry. It's a network facing daemon, it should not be able to load > > > kernel modules. > > > > But it is okay for networkd to manipulate the firewall directly. > > Yes, networkd configures the network. That's its raison d'etre. Thanks for clearing that up. I alway's thought firewalls were a security thing, and that netfilter is mandatory access control framewark that should be, mostly, transparent to applications and services. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788 Dominick Grift pgpbPvtZbgCoo.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:19, Tobias Hunger (tobias.hun...@gmail.com) wrote: > On Wed, Apr 22, 2015 at 3:12 PM, Tobias Hunger > wrote: > > Hi Lennart, > > > > On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering > > wrote: > >>> I was trying to run "systemd-nspawn --ephemeral", but that failed > >>> since I had a read-only image in /var/lib/machines. Why is that not > >>> allowed? systemd-nspawn does create its own snapshot of that one after > >>> all (which can be read-write). Why does the base image have to be > >>> read-write, too? > >> > >> Hmm? This shouldn't fail. What's the precise error message you get? > > > > It complains about a read-only filesystem when trying to bind-mount > > some directories into the machine. > > Sorry, I forgot to attach the exact error message: > > Apr 22 15:13:18 server systemd-nspawn[1804]: Failed to create mount > point /var/lib/machines/.#vmbdd461661453a1b8/mnt/ftp: Read-only file > system > > Looking at the code I do not see why that subvolume should be > read-only. Maybe it inherits the read-only from the one it is a > snapshot off? So, this is not inherited. THere are some trouble with setting the read only flag correctly when we do recursive snapshots, I am working on fixing that now. That only is triggered when --read-only and --ephemeral are combined though. The error you run into confuses me a bit I must say. What's the precise command line you trigger this with? Does /mnt/tmp exist? Is /mnt a mount or so, and /mnt/tmp another? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:55, Dominick Grift (dac.overr...@gmail.com) wrote: > > 2015-04-22 14:14 GMT+02:00 Lennart Poettering : > > > > Well, I really don't want to give networkd the caps for that, > > sorry. It's a network facing daemon, it should not be able to load > > kernel modules. > > But it is okay for networkd to manipulate the firewall directly. Yes, networkd configures the network. That's its raison d'etre. > The nft manual page states that the iptable_nat module conflicts > with the module that deals with nftables nat. Does that mean that > the networkd IPMasquerade= functionality will not work if one > blacklists iptables_nat? Well, if that's what it says, then yes. We can certainly add support for manipulating nft too, but so far the APIs fo that appeared much less convincing to me, and quite a bit more exotic. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:43, Michael Biebl (mbi...@gmail.com) wrote: > 2015-04-22 15:25 GMT+02:00 Lennart Poettering : > > On Wed, 22.04.15 14:36, Michael Biebl (mbi...@gmail.com) wrote: > > > >> >> >> Not everyone is using networkd or nspawn though, so loading this > >> >> >> module for everyone is a bit excessive. > >> >> > > >> >> > Well, then blacklist the module or don't build it at all. > >> >> > >> >> That's the wrong way around. > >> > > >> > Nah, I disagree. We do this for a number of modules now. I mean, we > >> > >> We currently do this static loading for unix, ipv6 and autofs4. > >> > >> > load tons of modules automatically, even if you don't use them. For > >> > example, my laptop always loads the bluetooth modules, even though I > >> > never used bluetooth. > >> > >> Those are all loaded on demand, not statically. I.e. we don't load the > >> bluetooth module for each and every user. > > > > No, things like bluetooth are not loaded on demand, but already when > > you just have the hw for it. That's quite a difference. > > > > Loading the bluetooth module when you have the hardware is something > different then loading it unconditionally for everyone. > You are doing the latter with iptables. I don#t see how this really was any different. I am sure a lot of people never want to use bluetooth, and I am also sure that a lot of people don#t want to use iptables (and of both of these, bluetooth is certainly the more exotic one, even). In both cases we autoload them now, with an easy way out, via blacklisting. > And why does this have to be hard-coded in the source instead of > shipping a /etc/modules-load.d snippet where it would be easily > discoverable? Because we generally try to make the system just work, without configuration. There's also another backstory: hopefully we can merge Daniel's patches soon that add minimal per-service Firewalling to PID 1. In that case it's not only networkd+nspawn that needs this, but PID 1 too, which makes the modules-load.d path unworkable. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:42, Tobias Hunger (tobias.hun...@gmail.com) wrote: > PS: Is there a way to stop the VMs to get a btrfs subvolume created in > /var/lib/machines? Not in nspawn, no. This could be implemented via seccomp though. > I have a couple of .#vm subvolumes in /var/lib/machines now and > btrfs subvolume delete does not work on those since they have a > subvolume in /var/lib/machine. Apparently systemd-nspawn also stumbled > over this as the directories are still there but the machines are not > running. As mentioned in an earlier thread here, Chris intends to add recursive subvolume deletion to btrfs-progs. In systemd git "machinectl remove" recursively deletes subvolumes already. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
> 2015-04-22 14:14 GMT+02:00 Lennart Poettering : > > Well, I really don't want to give networkd the caps for that, > sorry. It's a network facing daemon, it should not be able to load > kernel modules. But it is okay for networkd to manipulate the firewall directly. The nft manual page states that the iptable_nat module conflicts with the module that deals with nftables nat. Does that mean that the networkd IPMasquerade= functionality will not work if one blacklists iptables_nat? -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788 Dominick Grift pgpNEepiniQub.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 15:25 GMT+02:00 Lennart Poettering : > On Wed, 22.04.15 14:36, Michael Biebl (mbi...@gmail.com) wrote: > >> >> >> Not everyone is using networkd or nspawn though, so loading this >> >> >> module for everyone is a bit excessive. >> >> > >> >> > Well, then blacklist the module or don't build it at all. >> >> >> >> That's the wrong way around. >> > >> > Nah, I disagree. We do this for a number of modules now. I mean, we >> >> We currently do this static loading for unix, ipv6 and autofs4. >> >> > load tons of modules automatically, even if you don't use them. For >> > example, my laptop always loads the bluetooth modules, even though I >> > never used bluetooth. >> >> Those are all loaded on demand, not statically. I.e. we don't load the >> bluetooth module for each and every user. > > No, things like bluetooth are not loaded on demand, but already when > you just have the hw for it. That's quite a difference. > Loading the bluetooth module when you have the hardware is something different then loading it unconditionally for everyone. You are doing the latter with iptables. And why does this have to be hard-coded in the source instead of shipping a /etc/modules-load.d snippet where it would be easily discoverable? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
PS: Is there a way to stop the VMs to get a btrfs subvolume created in /var/lib/machines? I have a couple of .#vm subvolumes in /var/lib/machines now and btrfs subvolume delete does not work on those since they have a subvolume in /var/lib/machine. Apparently systemd-nspawn also stumbled over this as the directories are still there but the machines are not running. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:19, Tobias Hunger (tobias.hun...@gmail.com) wrote: > On Wed, Apr 22, 2015 at 3:12 PM, Tobias Hunger > wrote: > > Hi Lennart, > > > > On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering > > wrote: > >>> I was trying to run "systemd-nspawn --ephemeral", but that failed > >>> since I had a read-only image in /var/lib/machines. Why is that not > >>> allowed? systemd-nspawn does create its own snapshot of that one after > >>> all (which can be read-write). Why does the base image have to be > >>> read-write, too? > >> > >> Hmm? This shouldn't fail. What's the precise error message you get? > > > > It complains about a read-only filesystem when trying to bind-mount > > some directories into the machine. > > Sorry, I forgot to attach the exact error message: > > Apr 22 15:13:18 server systemd-nspawn[1804]: Failed to create mount > point /var/lib/machines/.#vmbdd461661453a1b8/mnt/ftp: Read-only file > system > > Looking at the code I do not see why that subvolume should be > read-only. Maybe it inherits the read-only from the one it is a > snapshot off? Oh, that could be. I figure we should unset the read-only flag unless --ephemeral is combined with --read-only. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:12, Tobias Hunger (tobias.hun...@gmail.com) wrote: > >> Then I have trouble with "systemd-nspawn --network-veth": The host0 > >> interface won't come up and stays in degraded state. On the host i get > >> the following line in the journal: > >> > >> systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: > >> Protocol not available > >> > >> I have an nftables based firewall up and running, so maybe networkd is > >> expecting iptables to be in use? > > > > Most likely iptables is compiled as kernel module for you. The module > > cannot be auto-loaded currently, iptables manually loads it for you on > > first invocation, networkd doesn't. If you load it manually (by adding > > it to modules-load.d for example) things should work. > > I loaded the ip-tables module manually now and that does indeed fix > the error message in my original mail. The machine still stays in > "degraded (configuring)" forever though. > > As I said: I have a fully set up nftables-based firewall, so I expect > systemd will have trouble doing anything sensible with iptables. I > read iptables are a wrapper around nftables nowadays, but iptables -L > does not show any of my rules, so that might be the reason for the > trouble I am seeing. Well, to my knowledge the kernel actually supports both in parallel. networkd + nspawn only do iptables. > Do I need to reinstall my machines using an iptables firewall for this to > work? No need. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:36, Michael Biebl (mbi...@gmail.com) wrote: > >> >> Not everyone is using networkd or nspawn though, so loading this > >> >> module for everyone is a bit excessive. > >> > > >> > Well, then blacklist the module or don't build it at all. > >> > >> That's the wrong way around. > > > > Nah, I disagree. We do this for a number of modules now. I mean, we > > We currently do this static loading for unix, ipv6 and autofs4. > > > load tons of modules automatically, even if you don't use them. For > > example, my laptop always loads the bluetooth modules, even though I > > never used bluetooth. > > Those are all loaded on demand, not statically. I.e. we don't load the > bluetooth module for each and every user. No, things like bluetooth are not loaded on demand, but already when you just have the hw for it. That's quite a difference. Pure on-demand loading of all modules is something that was given up on back in kernel 2.2 times already... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, Apr 22, 2015 at 3:12 PM, Tobias Hunger wrote: > Hi Lennart, > > On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering > wrote: >>> I was trying to run "systemd-nspawn --ephemeral", but that failed >>> since I had a read-only image in /var/lib/machines. Why is that not >>> allowed? systemd-nspawn does create its own snapshot of that one after >>> all (which can be read-write). Why does the base image have to be >>> read-write, too? >> >> Hmm? This shouldn't fail. What's the precise error message you get? > > It complains about a read-only filesystem when trying to bind-mount > some directories into the machine. Sorry, I forgot to attach the exact error message: Apr 22 15:13:18 server systemd-nspawn[1804]: Failed to create mount point /var/lib/machines/.#vmbdd461661453a1b8/mnt/ftp: Read-only file system Looking at the code I do not see why that subvolume should be read-only. Maybe it inherits the read-only from the one it is a snapshot off? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
Hi Lennart, On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering wrote: >> I was trying to run "systemd-nspawn --ephemeral", but that failed >> since I had a read-only image in /var/lib/machines. Why is that not >> allowed? systemd-nspawn does create its own snapshot of that one after >> all (which can be read-write). Why does the base image have to be >> read-write, too? > > Hmm? This shouldn't fail. What's the precise error message you get? It complains about a read-only filesystem when trying to bind-mount some directories into the machine. >> Then I have trouble with "systemd-nspawn --network-veth": The host0 >> interface won't come up and stays in degraded state. On the host i get >> the following line in the journal: >> >> systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: >> Protocol not available >> >> I have an nftables based firewall up and running, so maybe networkd is >> expecting iptables to be in use? > > Most likely iptables is compiled as kernel module for you. The module > cannot be auto-loaded currently, iptables manually loads it for you on > first invocation, networkd doesn't. If you load it manually (by adding > it to modules-load.d for example) things should work. I loaded the ip-tables module manually now and that does indeed fix the error message in my original mail. The machine still stays in "degraded (configuring)" forever though. As I said: I have a fully set up nftables-based firewall, so I expect systemd will have trouble doing anything sensible with iptables. I read iptables are a wrapper around nftables nowadays, but iptables -L does not show any of my rules, so that might be the reason for the trouble I am seeing. Do I need to reinstall my machines using an iptables firewall for this to work? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:26 GMT+02:00 Lennart Poettering : > On Wed, 22.04.15 14:22, Michael Biebl (mbi...@gmail.com) wrote: > >> 2015-04-22 14:14 GMT+02:00 Lennart Poettering : >> > On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: >> > >> >> 2015-04-22 13:57 GMT+02:00 Lennart Poettering : >> >> >> Maybe we should simply list the iptables kernel modules in >> >> >> src/core/kmod-setup, and then tell people to blacklist them if they >> >> >> really don't want them. >> >> > >> >> > I have made such a change now: >> >> > >> >> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 >> >> >> >> Not everyone is using networkd or nspawn though, so loading this >> >> module for everyone is a bit excessive. >> > >> > Well, then blacklist the module or don't build it at all. >> >> That's the wrong way around. > > Nah, I disagree. We do this for a number of modules now. I mean, we We currently do this static loading for unix, ipv6 and autofs4. > load tons of modules automatically, even if you don't use them. For > example, my laptop always loads the bluetooth modules, even though I > never used bluetooth. Those are all loaded on demand, not statically. I.e. we don't load the bluetooth module for each and every user. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:28, Michael Biebl (mbi...@gmail.com) wrote: > 2015-04-22 14:22 GMT+02:00 Michael Biebl : > > 2015-04-22 14:14 GMT+02:00 Lennart Poettering : > >> On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: > >> > >>> Not everyone is using networkd or nspawn though, so loading this > >>> module for everyone is a bit excessive. > >> > >> Well, then blacklist the module or don't build it at all. > > [..] > > >> For the same reason that iptables doesn't complain loudly but loads > >> it. To be user-friendly and just make things work? > > And making everyone who doesn't want this feature jump through hoops > and having them blacklist the module is not user-friendly at all. > Least of it, it's not really intuitive and discoverable, how this > module got loaded in the first place. Well, it is not discoverable for *any* kmod really, not just this one. Except, that this is actually *more* discoverable thant normal udev-based or kernel-auto-loaded kmods, since we actually *do* log about it, in contrast to those cases. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:22 GMT+02:00 Michael Biebl : > 2015-04-22 14:14 GMT+02:00 Lennart Poettering : >> On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: >> >>> Not everyone is using networkd or nspawn though, so loading this >>> module for everyone is a bit excessive. >> >> Well, then blacklist the module or don't build it at all. [..] >> For the same reason that iptables doesn't complain loudly but loads >> it. To be user-friendly and just make things work? And making everyone who doesn't want this feature jump through hoops and having them blacklist the module is not user-friendly at all. Least of it, it's not really intuitive and discoverable, how this module got loaded in the first place. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:14 GMT+02:00 Lennart Poettering : > On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: > >> 2015-04-22 13:57 GMT+02:00 Lennart Poettering : >> >> Maybe we should simply list the iptables kernel modules in >> >> src/core/kmod-setup, and then tell people to blacklist them if they >> >> really don't want them. >> > >> > I have made such a change now: >> > >> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 >> >> Not everyone is using networkd or nspawn though, so loading this >> module for everyone is a bit excessive. > > Well, then blacklist the module or don't build it at all. That's the wrong way around. >> Why non let nspawn and networkd complain loudly if iptables support is >> missing? >> This would also be better in case you have a kernel compiled withouth >> iptables support. > > For the same reason that iptables doesn't complain loudly but loads > it. To be user-friendly and just make things work? iptables loads it on-demand, If nspawn or networkd would load it on-demand, I would have no problem with it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:22, Michael Biebl (mbi...@gmail.com) wrote: > 2015-04-22 14:14 GMT+02:00 Lennart Poettering : > > On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: > > > >> 2015-04-22 13:57 GMT+02:00 Lennart Poettering : > >> >> Maybe we should simply list the iptables kernel modules in > >> >> src/core/kmod-setup, and then tell people to blacklist them if they > >> >> really don't want them. > >> > > >> > I have made such a change now: > >> > > >> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 > >> > >> Not everyone is using networkd or nspawn though, so loading this > >> module for everyone is a bit excessive. > > > > Well, then blacklist the module or don't build it at all. > > That's the wrong way around. Nah, I disagree. We do this for a number of modules now. I mean, we load tons of modules automatically, even if you don't use them. For example, my laptop always loads the bluetooth modules, even though I never used bluetooth. We always load more kmods than strictly necessary, simply to ensure a good user experience, and so we should do this in this case too. And the blacklist is a good answer to give the user control, if he wants to opt out of some modules. (Also note that this is a non-issue on distros like Fedora, where the kmod is built-in anyway.) > > >> Why non let nspawn and networkd complain loudly if iptables support is > >> missing? > >> This would also be better in case you have a kernel compiled withouth > >> iptables support. > > > > For the same reason that iptables doesn't complain loudly but loads > > it. To be user-friendly and just make things work? > > iptables loads it on-demand, If nspawn or networkd would load it > on-demand, I would have no problem with it. Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: > 2015-04-22 13:57 GMT+02:00 Lennart Poettering : > >> Maybe we should simply list the iptables kernel modules in > >> src/core/kmod-setup, and then tell people to blacklist them if they > >> really don't want them. > > > > I have made such a change now: > > > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 > > Not everyone is using networkd or nspawn though, so loading this > module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. > Why non let nspawn and networkd complain loudly if iptables support is > missing? > This would also be better in case you have a kernel compiled withouth > iptables support. For the same reason that iptables doesn't complain loudly but loads it. To be user-friendly and just make things work? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 13:57 GMT+02:00 Lennart Poettering : >> Maybe we should simply list the iptables kernel modules in >> src/core/kmod-setup, and then tell people to blacklist them if they >> really don't want them. > > I have made such a change now: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Why non let nspawn and networkd complain loudly if iptables support is missing? This would also be better in case you have a kernel compiled withouth iptables support. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 13:46, Lennart Poettering (lenn...@poettering.net) wrote: > > I have an nftables based firewall up and running, so maybe networkd is > > expecting iptables to be in use? > > Most likely iptables is compiled as kernel module for you. The module > cannot be auto-loaded currently, iptables manually loads it for you on > first invocation, networkd doesn't. If you load it manually (by adding > it to modules-load.d for example) things should work. > > I am not sure how to fix this best. I#d rather not have networkd gain > support for autoloading kernel modules. Also, it's unlikely to be > sufficient, given that nspawn can make use of the iptables bits as > well... > > Maybe we should simply list the iptables kernel modules in > src/core/kmod-setup, and then tell people to blacklist them if they > really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Any chance you can check if this makes things work for you? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Tue, 21.04.15 22:43, Tobias Hunger (tobias.hun...@gmail.com) wrote: > Hi! > > Now that systemd 219 is finally available in arch I am playing with > systemd-nspawn again. > > I was trying to run "systemd-nspawn --ephemeral", but that failed > since I had a read-only image in /var/lib/machines. Why is that not > allowed? systemd-nspawn does create its own snapshot of that one after > all (which can be read-write). Why does the base image have to be > read-write, too? Hmm? This shouldn't fail. What's the precise error message you get? > Then I have trouble with "systemd-nspawn --network-veth": The host0 > interface won't come up and stays in degraded state. On the host i get > the following line in the journal: > > systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: > Protocol not available > > I have an nftables based firewall up and running, so maybe networkd is > expecting iptables to be in use? Most likely iptables is compiled as kernel module for you. The module cannot be auto-loaded currently, iptables manually loads it for you on first invocation, networkd doesn't. If you load it manually (by adding it to modules-load.d for example) things should work. I am not sure how to fix this best. I#d rather not have networkd gain support for autoloading kernel modules. Also, it's unlikely to be sufficient, given that nspawn can make use of the iptables bits as well... Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn trouble
Hi! Now that systemd 219 is finally available in arch I am playing with systemd-nspawn again. I was trying to run "systemd-nspawn --ephemeral", but that failed since I had a read-only image in /var/lib/machines. Why is that not allowed? systemd-nspawn does create its own snapshot of that one after all (which can be read-write). Why does the base image have to be read-write, too? Then I have trouble with "systemd-nspawn --network-veth": The host0 interface won't come up and stays in degraded state. On the host i get the following line in the journal: systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: Protocol not available I have an nftables based firewall up and running, so maybe networkd is expecting iptables to be in use? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
