Re: [systemd-devel] sibling DNS lookup of nspawn containers
> On Jun 18, 2021, at 16:02, Silvio Knizek wrote: > > Am Freitag, dem 18.06.2021 um 14:52 -0700 schrieb Johannes Ernst: >> >> Thanks, Silvio, but no luck: >> >> I have host, container a and container b. >> >> In both containers, .network for host0 has LLMNR=yes in the [Network] >> section >> >> The host has LLMNR=yes in the [Resolve] section of >> /etc/systemd/resolved.conf >> >> On the host: “resolvectl query a” and “…b” works. >> >> In the containers “resolvectl query a” works only in container a, not >> in b, and vice versa. So no sibling lookup. >> >> iptables and ip6tables show default rules for all three. >> >> What am I missing? >> >> Thanks, >> >> Johannes. >> > > Are both machines in the same network zone or attached to the same > bridge interface on the host machine? Else the default NAT rules won't > allow for multicast traffic as it is done by LLMNR. > sd-nspawn uses nftables, not iptables. You should see some rules with > »nft list table ip io.systemd.nat«. > So add »--network-zone=some-fancy-name« to your systemd-nspawn > commands. Almost! With —network-zone=foo, I get sibling IPv6 addresses, but I don’t get sibling IPv4 addresses. iptables are empty, nftables seem to have nothing IP-version specific in them. I know basically nothing about LLMNR. This is supposed to apply to both v4 and v6, right? On the other hand, I may not need IPv4 for my use case. Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
Am Freitag, dem 18.06.2021 um 14:52 -0700 schrieb Johannes Ernst: > > Thanks, Silvio, but no luck: > > I have host, container a and container b. > > In both containers, .network for host0 has LLMNR=yes in the [Network] > section > > The host has LLMNR=yes in the [Resolve] section of > /etc/systemd/resolved.conf > > On the host: “resolvectl query a” and “…b” works. > > In the containers “resolvectl query a” works only in container a, not > in b, and vice versa. So no sibling lookup. > > iptables and ip6tables show default rules for all three. > > What am I missing? > > Thanks, > > Johannes. > Hi Johannes, Are both machines in the same network zone or attached to the same bridge interface on the host machine? Else the default NAT rules won't allow for multicast traffic as it is done by LLMNR. sd-nspawn uses nftables, not iptables. You should see some rules with »nft list table ip io.systemd.nat«. So add »--network-zone=some-fancy-name« to your systemd-nspawn commands. === man: systemd.nspawn === Using --network-zone= is hence in most cases fully automatic and sufficient to connect multiple local containers in a joined broadcast domain to the host, with further connectivity to the external network. === === BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] UNSUSCRIBE
UNSUSCRIBE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
> On Jun 18, 2021, at 2:02, Silvio Knizek wrote: > > Am Donnerstag, dem 17.06.2021 um 20:26 -0700 schrieb Johannes Ernst: >> I’d like to be able to DNS lookup container b from within container a, if >> both were started with systemd-nspawn as siblings of each other, and shown >> as a and b in machinectl list. >> >> man nss-mymachines specifically notes it won’t do that. >> >> What’s the proper way of doing this? >> >> Thanks, > Hi Johannes, > > you would enable LinkLocalMulticastNameResolution (LLMNR) in the > containers systemd-networkd. > See man:networkd.conf for further information. Thanks, Silvio, but no luck: I have host, container a and container b. In both containers, .network for host0 has LLMNR=yes in the [Network] section The host has LLMNR=yes in the [Resolve] section of /etc/systemd/resolved.conf On the host: “resolvectl query a” and “…b” works. In the containers “resolvectl query a” works only in container a, not in b, and vice versa. So no sibling lookup. iptables and ip6tables show default rules for all three. What am I missing? Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reloading configuration after mount unit
On 18.06.2021 20:48, Norbert Lange wrote: > Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek > : >> >> Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange: >>> Hello, >>> >>> I have an extra mount for /usr/local (Tools + Services which are just >>> useful for development), classically done vie /etc/fstab. >>> >>> Now there are a few systemd services within /usr/local/lib and systemd >>> does not seem to load/reload those and start the ones that add a >>> sysinit.wants. >>> >>> currently I have to do the following to get a "full start": >>> systemctl daemon-reload >>> systemctl start default.target >>> >>> What would be the correct way to cause systemd to reevaluate configuration? >>> I get that this generally could lead to bad behaviour (endless >>> reconfiguration if cycles), >>> but for something hierarchical like mount-paths it should be possible. >>> >>> I could think of a unit having an after/requires to usr-local.mount or >>> using a path unit watching PathChanged=/usr/local/lib/systemd. >>> At any rate, I am not sure how I could tell systemd to start new units >>> wanted by eg. >>> sysinit.target if this was already fully started. `systemctl start >>> default.target` seems >>> a bit dangerous. >>> >>> Another, less important issue is that I cant set lazy unmount in fstab. >>> >>> Norbert. >> Hi Norbert, >> >> make sure your /usr/local mount is done in the initrd and that you use >> »systemctl link /path/to/unit.service« to enable them. > > That's not really helping, I don't want to chug in tons of tools in > the initramfs this is no desktop system. > systemctl link shouldnt be necessary, as /usr/local/lib/systemd/system > is a standard unit path. > > Since there is a systemd-update-done that changes /etc I would have thought > that > systemd rereads the configuration (as /etc/systemd/system could have > changed) during startup. The only thing systemd-update-done does is touch /etc/.updated touch /var/.updated It has nothing to do with "rereading configuration". > I would want that for /usr/local/lib/systemd/system after this path > was made available through a mount. > systemd will always scan unit path when you attempt to reference unit not yet loaded. So this "just works". But you apparently need something different. You want systemd to retrospectively scan new directory for any unit definition that is mentioned in any already loaded unit and re-evaluate dependencies. systemd was never designed for it. It was designed to statically build full closure of units to be started on boot, and do it just once. I suppose it is theoretically possible to do it in lazy way - start with just immediate dependencies of default.target and add dependency of each unit when you are about to start it. That would do what you want as long path becomes available before systemd starts units that reference these path. But that would need radical redesign of the whole dependency chain. > If systemd assumes the whole /usr drive to be static and has no way to > dynamically reload and "retarget" > (adding new wants/requires dependencies to starting/started targets) > then I guess that's the end of it. > It does not assume anything about /usr, it just builds full set if units to be started on boot once. Anything not available (visible) at this moment will not be included in boot "transaction". > I dont know if thats the case or if I just dont know how (as > systemd-update-done allows a changing /etc I would assume systemd > would rescan it for units/dependencies) > >> >> For the automount behaviour, you need to add >> »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s« >> to the options part in the /etc/fstab. See man:systemd.mount for more >> information. > > Thats Automount, but I want "LazyUnmount", > and the suggestion kinda contradicts "make sure your /usr/local mount > is done in the initrd" > > Norbert > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reloading configuration after mount unit
Am Freitag, dem 18.06.2021 um 19:48 +0200 schrieb Norbert Lange:
> Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek
:
> >
> > Hi Norbert,
> >
> > make sure your /usr/local mount is done in the initrd and that you
use
> > »systemctl link /path/to/unit.service« to enable them.
> That's not really helping, I don't want to chug in tons of tools in
> the initramfs this is no desktop system.
> systemctl link shouldnt be necessary, as
/usr/local/lib/systemd/system
> is a standard unit path.
You're right with the path, I re-checked it.
For your initrd the general suggestion is to actually include systemd
in it. See https://systemd.io/INITRD_INTERFACE/ for everything.
>
> Since there is a systemd-update-done that changes /etc I would have
thought that
> systemd rereads the configuration (as /etc/systemd/system could have
> changed) during startup.
> I would want that for /usr/local/lib/systemd/system after this path
> was made available through a mount.
>
> If systemd assumes the whole /usr drive to be static and has no way
to
> dynamically reload and "retarget"
> (adding new wants/requires dependencies to starting/started targets)
> then I guess that's the end of it.
>
> I dont know if thats the case or if I just dont know how (as
> systemd-update-done allows a changing /etc I would assume systemd
> would rescan it for units/dependencies)
systemds internal unit representation is actually static. Unit files
are only read when started as PID1 after the generators ran, while
switch-root'ing from the initrd and everytime you run »systemctl
daemon-re{load,exec}« (there are transient units as well, but this
would be to much for here).
What you could try is creating a new unit in /etc/systemd/system/
--- systemd-reload.service ---
[Unit]
Description=Reload systemd
Requires=usr-local.mount
After=usr-local.mount
[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl --no-block daemon-reload
[Install]
WantedBy=usr-local.mount
---
and than a »systemctl daemon-reload && systemctl enable systemd-
reload.service«.
In theory (because completly untested) this unit should be activated as
soon as your /usr/local mount point is ready.
>
> >
> > For the automount behaviour, you need to add
> > »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s«
> > to the options part in the /etc/fstab. See man:systemd.mount for
more
> > information.
>
> Thats Automount, but I want "LazyUnmount",
> and the suggestion kinda contradicts "make sure your /usr/local mount
> is done in the initrd"
The »x-systemd.idle-timeout=10s« actually unmounts the disk as soon as
10s long the disk is idle. Idle is defined as
- open file descriptors and
- process working directory.
So LazyUnmount (which you can define in an actual .mount unit) wouldn't
change anything IMHO.
(sorry for sending twice. Forgot the ML)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reloading configuration after mount unit
On Fri, 2021-06-18 at 19:48 +0200, Norbert Lange wrote: > If systemd assumes the whole /usr drive to be static and has no way to > dynamically reload and "retarget" > (adding new wants/requires dependencies to starting/started targets) > then I guess that's the end of it. Systemd does not necessarily assume the whole of /usr to be mounted at once - you could have binaries and data in submounts and systemd could wait for those - but there is no "normal" way to add units in the middle of operation. There is "daemon-reload", but it's more meant for things like online updates, not part of a standard boot sequence. Normally the complete set of units to start in a boot should be known early, not appended to in parts as things are mounted. So you could have tools in a separately-mounted /usr/local, but I think you'd need to have the systemd configuration for them in the main /usr to have things behave nicely. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reloading configuration after mount unit
Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek : > > Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange: > > Hello, > > > > I have an extra mount for /usr/local (Tools + Services which are just > > useful for development), classically done vie /etc/fstab. > > > > Now there are a few systemd services within /usr/local/lib and systemd > > does not seem to load/reload those and start the ones that add a > > sysinit.wants. > > > > currently I have to do the following to get a "full start": > > systemctl daemon-reload > > systemctl start default.target > > > > What would be the correct way to cause systemd to reevaluate configuration? > > I get that this generally could lead to bad behaviour (endless > > reconfiguration if cycles), > > but for something hierarchical like mount-paths it should be possible. > > > > I could think of a unit having an after/requires to usr-local.mount or > > using a path unit watching PathChanged=/usr/local/lib/systemd. > > At any rate, I am not sure how I could tell systemd to start new units > > wanted by eg. > > sysinit.target if this was already fully started. `systemctl start > > default.target` seems > > a bit dangerous. > > > > Another, less important issue is that I cant set lazy unmount in fstab. > > > > Norbert. > Hi Norbert, > > make sure your /usr/local mount is done in the initrd and that you use > »systemctl link /path/to/unit.service« to enable them. That's not really helping, I don't want to chug in tons of tools in the initramfs this is no desktop system. systemctl link shouldnt be necessary, as /usr/local/lib/systemd/system is a standard unit path. Since there is a systemd-update-done that changes /etc I would have thought that systemd rereads the configuration (as /etc/systemd/system could have changed) during startup. I would want that for /usr/local/lib/systemd/system after this path was made available through a mount. If systemd assumes the whole /usr drive to be static and has no way to dynamically reload and "retarget" (adding new wants/requires dependencies to starting/started targets) then I guess that's the end of it. I dont know if thats the case or if I just dont know how (as systemd-update-done allows a changing /etc I would assume systemd would rescan it for units/dependencies) > > For the automount behaviour, you need to add > »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s« > to the options part in the /etc/fstab. See man:systemd.mount for more > information. Thats Automount, but I want "LazyUnmount", and the suggestion kinda contradicts "make sure your /usr/local mount is done in the initrd" Norbert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alias for SMTP providers [ie. mutually exclusive service alternatives]
On Tue, Jun 15, 2021 at 5:13 AM Kenneth Porter wrote: > > What happens if I list multiple services in a Wants= and After= clause that > are mutually exclusive (eg. sendmail/postfix/exim? How can I say "This unit > needs to send mail" without knowing which is enabled? Unfortunately "need to send mail" is not well defined.. a) does it need to talk to smtp/smpts/submission ports ? then your smtp daemon needs to socket activate properly b) Needs to execute the sendmail binary ? your sendmail command must queue your messages for "later", Otherwise your service must start after any of this services but not want any of them, bad news is it will race anyway and your app still shouldn't care about what daemon or not is handling the email so goto a) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reloading configuration after mount unit
Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange: > Hello, > > I have an extra mount for /usr/local (Tools + Services which are just > useful for development), classically done vie /etc/fstab. > > Now there are a few systemd services within /usr/local/lib and systemd > does not seem to load/reload those and start the ones that add a > sysinit.wants. > > currently I have to do the following to get a "full start": > systemctl daemon-reload > systemctl start default.target > > What would be the correct way to cause systemd to reevaluate configuration? > I get that this generally could lead to bad behaviour (endless > reconfiguration if cycles), > but for something hierarchical like mount-paths it should be possible. > > I could think of a unit having an after/requires to usr-local.mount or > using a path unit watching PathChanged=/usr/local/lib/systemd. > At any rate, I am not sure how I could tell systemd to start new units > wanted by eg. > sysinit.target if this was already fully started. `systemctl start > default.target` seems > a bit dangerous. > > Another, less important issue is that I cant set lazy unmount in fstab. > > Norbert. Hi Norbert, make sure your /usr/local mount is done in the initrd and that you use »systemctl link /path/to/unit.service« to enable them. For the automount behaviour, you need to add »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s« to the options part in the /etc/fstab. See man:systemd.mount for more information. HTH Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reloading configuration after mount unit
Hello, I have an extra mount for /usr/local (Tools + Services which are just useful for development), classically done vie /etc/fstab. Now there are a few systemd services within /usr/local/lib and systemd does not seem to load/reload those and start the ones that add a sysinit.wants. currently I have to do the following to get a "full start": systemctl daemon-reload systemctl start default.target What would be the correct way to cause systemd to reevaluate configuration? I get that this generally could lead to bad behaviour (endless reconfiguration if cycles), but for something hierarchical like mount-paths it should be possible. I could think of a unit having an after/requires to usr-local.mount or using a path unit watching PathChanged=/usr/local/lib/systemd. At any rate, I am not sure how I could tell systemd to start new units wanted by eg. sysinit.target if this was already fully started. `systemctl start default.target` seems a bit dangerous. Another, less important issue is that I cant set lazy unmount in fstab. Norbert. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sibling DNS lookup of nspawn containers
Am Donnerstag, dem 17.06.2021 um 20:26 -0700 schrieb Johannes Ernst: > I’d like to be able to DNS lookup container b from within container a, if > both were started with systemd-nspawn as siblings of each other, and shown as > a and b in machinectl list. > > man nss-mymachines specifically notes it won’t do that. > > What’s the proper way of doing this? > > Thanks, Hi Johannes, you would enable LinkLocalMulticastNameResolution (LLMNR) in the containers systemd-networkd. See man:networkd.conf for further information. BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
