[systemd-devel] Antw: [EXT] Re: Support for unmerged-usr systems will be REMOVED in the second half of 2023
>>> Luca Boccassi schrieb am 05.11.2022 um 12:32 in Nachricht : > On Sat, 5 Nov 2022, 10:53 TJ, wrote: > >> On 05/11/2022 10:36, Mantas Mikulėnas wrote: >> > On Sat, Nov 5, 2022 at 12:06 PM TJ wrote: >> > >> >> Just seen this announcement in the v252 changelog: >> >> >> >> "We intend to remove support for split-usr (/usr mounted separately >> >> during boot) ..." >> >> >> >> How does this align with support for separate /usr/ with dm-verity ? >> >> >> >> For example, this will affect nspawn. See "man 1 systemd-nspawn" and >> >> "--root-hash=" where in respect of /usr/ it says: >> >> >> >> "Note that this configures the root hash for the root file system. Disk >> >> images may also contain separate file systems for the /usr/ hierarchy, >> >> which may be Verity protected as well. The root hash for this protection >> >> may be configured via the "user.verity.usrhash" extended file attribute >> >> or via a .usrhash file adjacent to the disk image, following the same >> >> format and logic as for the root hash for the root file system described >> >> here." >> >> >> > >> > /usr can remain on a separate partition as long as it's mounted *by the >> > initrd* (the same way initrd currently mounts your rootfs), so that by >> the >> > time systemd starts it already has the full filesystem. >> >> How does this work when systemd is used inside the initrd, as >> "recommended" / discussed at, for example "Using systemd inside an initrd" >> : >> >> https://systemd.io/INITRD_INTERFACE/ >> >> > What's finally being removed is support for having the rootfs itself >> mount >> > /usr halfway through, which requires many things that normally are on >> > /usr/lib to be split between it and /lib instead (such as on Debian). >> > >> > Using the initrd to mount /usr isn't new. >> > < >> > https://web.archive.org/web/20150906203654if_/https://www.gentoo.org/support/ > news-items/2013-09-27-initramfs-required.html >> > >> > >> >> Does it also affect the command-line options "mount.usr=, >> mount.usrfstype=, mount.usrflags=, usrhash=, systemd.verity_usr_data=, >> systemd.verity_usr_hash=, systemd.verity_usr_options=" as per "man 7 >> kernel-command-line" ? >> > > No, that is unrelated. This is about the ancient notion (that no initrd > tools support anymore) that you can boot userspace with /bin /lib /sbin and > no /usr, with the latter being set up late at boot. This is what is no > longer going to be supported. ..by systemd developers And so the Linux OS world must change... > >>
[systemd-devel] Antw: [EXT] Re: Support for unmerged-usr systems will be REMOVED in the second half of 2023
>>> TJ schrieb am 05.11.2022 um 10:59 in Nachricht : > Just seen this announcement in the v252 changelog: > > "We intend to remove support for split-usr (/usr mounted separately > during boot) ..." Actually I think this is because systemd is everything but a small boot environment (so wanting the "big /usr"). > > How does this align with support for separate /usr/ with dm-verity ? > > For example, this will affect nspawn. See "man 1 systemd-nspawn" and > "--root-hash=" where in respect of /usr/ it says: > > "Note that this configures the root hash for the root file system. Disk > images may also contain separate file systems for the /usr/ hierarchy, > which may be Verity protected as well. The root hash for this protection > may be configured via the "user.verity.usrhash" extended file attribute > or via a .usrhash file adjacent to the disk image, following the same > format and logic as for the root hash for the root file system described > here."
Re: [systemd-devel] systemd-resolved/NetworkManager resolv.conf handling
> On 2 Nov 2022, at 15:20, Thomas HUMMEL wrote:
>
> On 10/31/22 12:19, Petr Menšík wrote:
>
> Hello, thank you and Barry as well for your answers
>
>
>> I would suggest using strace to find what exactly it does and what it tries
>> to modify. I expect sources for that client are not available.
>
> Well, digging a little deeper, here's what I've found out:
>
> 1) in the default case (described in my initial post), i.e.
>
>/etc/resolv.conf symlinked to systemd-resolved
> /run/systemd/resolve/stub-resolv.conf
>no dns nor rc.manager directives in NM config
>no F5 client NM profile
>
> The vpn client:
>
>a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
>b) readlinks the symlink
>c) execve's /sbin/resolvconf providing nameservers (thus trying to play
> along with systemd-resolved) but on the wrong interface on my Fedora (eth0.f5
> instead of tun0) [besides with a deprecated and not used arg (-m)]
>
>execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5", "-m 0"],
> 0x7ffd13bf8568 /* 30 vars */
So a dirty hack is to replace /sbin/resolvconf with a script that
does-the-right-thing.
Uses resolvectl on the correct interface etc. But only when called by F5.
Clearly F5 vpn software is in need of updating to support options for modern
linux.
Have you tried raising an issue with F5?
Barry
>
>d) set up tun0 interface and bring it up
>
> -> hence we end up with:
>
>a) /etc/resolv.conf.fp-saved as a regular file, copy of
> /run/systemd/resolve/stub-resolv.conf
>b) NM managed tun0 interface without and dns property in its profile nor
> any disk persistent profile
>c) unchanded /etc/resolv.conf (still linked to
> /run/systemd/resolve/stub-resolv.conf
>
> so, systemd-resolved not knowing about vpn nameservers and vpn nameresolution
> fails without workaround (like resolvectl dns adding the tun0 nameserver for
> instance)
>
> 2) with NM handling /etc/resolv.conf as a regular file, i.e.
>
> /etc symlink rm-ed
> dns=default
> rc.manager=file
>
> the F5 client consider it a 'legacy' setting and overwrite (which is wrong to
> me) NM managed /etc/resolv.conf regular file
>
> it restores it when stopped by copying back /etc/resolv.conf.fp-saved
>
> So, basically I'd say there are 2 bugs :
>
> 1) legacy handling which seems to consider pre-NM era legacy
> 2) resolvconf call when systemd-resolved is used (at least on Fedora)
>
> In any case, I don't understand why it does not set the NM profile ipv4.dns
> property, which would let much more chances for NM and/or resolved to work
>
> Anyway, this leaves 2 unanswered questions, the first of which was my initial
> one:
>
> 1) how could, when all resolv.conf-as-a-file-by-NM conf has been removed (by
> me) and symlink to stub has been restored (by me) systemd-resolved, with *no
> trace* of the vpn nameservers in its own /run/systemd/resolv/resolv.conf nor
> seemingly nowhere else, can be still aware of the vpn nameservers (as
> described in my initial post scenario) ?
>
> -> is there a persistent systemd-resolved cache on disk somewhere ?
>
> 2) when running resolvconf by hand (resolvconf ) providing specific
> interface specific nameservers (on stdin), it seems to update the **global**
> /run/systemd/resolve/resolv.conf (hence making those nameservers available
> for all interfaces ?)
>
> -> Is there any other place where the specific ns <-> interface is persited
> or stored or is this global updating all there is ?
>
> Thanks for your help
>
> --
> Thomas HUMMEL
>
Re: [systemd-devel] systemd-resolved/NetworkManager resolv.conf handling
Oh, understood. Then it is specific problem to Fedora, because I think
other distributions do not use systemd's implementation of resolvconf
binary.
I think original Debian resolvconf package does not use -a interface
parameter for anything serious. It just uses the same interface
identifier to pair -a and -d for the same connection.
On the other hand systemd's resolvconf tracks settings per interface and
it requires it to point to the real interface on the system. Of course
F5 client should use a real interface name it is going to use. I am not
sure what can be done for it on side of systemd. Perhaps systemd could
allow configuration of aliases, so it would allow to map eth0.f5 to tun0
interface. But that seems a mere workaround, F5 client should be
modified to call resolvconf once it knows used interface name, not
before that. It would be nice to issue a bug on F5 site. I haven't found
issue matching your description. It would be worth filling.
https://support.f5.com/csp/bug-tracker
On 11/2/22 16:20, Thomas HUMMEL wrote:
On 10/31/22 12:19, Petr Menšík wrote:
Hello, thank you and Barry as well for your answers
I would suggest using strace to find what exactly it does and what it
tries to modify. I expect sources for that client are not available.
Well, digging a little deeper, here's what I've found out:
1) in the default case (described in my initial post), i.e.
/etc/resolv.conf symlinked to systemd-resolved
/run/systemd/resolve/stub-resolv.conf
no dns nor rc.manager directives in NM config
no F5 client NM profile
The vpn client:
a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
b) readlinks the symlink
c) execve's /sbin/resolvconf providing nameservers (thus trying to
play along with systemd-resolved) but on the wrong interface on my
Fedora (eth0.f5 instead of tun0) [besides with a deprecated and not
used arg (-m)]
execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5",
"-m 0"], 0x7ffd13bf8568 /* 30 vars */
d) set up tun0 interface and bring it up
-> hence we end up with:
a) /etc/resolv.conf.fp-saved as a regular file, copy of
/run/systemd/resolve/stub-resolv.conf
b) NM managed tun0 interface without and dns property in its
profile nor any disk persistent profile
c) unchanded /etc/resolv.conf (still linked to
/run/systemd/resolve/stub-resolv.conf
so, systemd-resolved not knowing about vpn nameservers and vpn
nameresolution fails without workaround (like resolvectl dns adding
the tun0 nameserver for instance)
2) with NM handling /etc/resolv.conf as a regular file, i.e.
/etc symlink rm-ed
dns=default
rc.manager=file
the F5 client consider it a 'legacy' setting and overwrite (which is
wrong to me) NM managed /etc/resolv.conf regular file
it restores it when stopped by copying back /etc/resolv.conf.fp-saved
That is exactly what it should do for a VPN, unless it knows a more
proper way to configure system DNS. Some packages like dnssec-trigger
prevents that by setting additional parameter to /etc/resolv.conf,
making it non-writeable even by root process. There is not a generic and
better way other than resolvconf. On Fedora resolvconf is provided just
for systemd-resolved in default installation. But it needs precise
interfaces used, unlike original implementation.
So, basically I'd say there are 2 bugs :
1) legacy handling which seems to consider pre-NM era legacy
2) resolvconf call when systemd-resolved is used (at least on Fedora)
In any case, I don't understand why it does not set the NM profile
ipv4.dns property, which would let much more chances for NM and/or
resolved to work
Does "nmcli c" command show F5 profile in green, when it is connected?
"nmcli c show " would provide all details it knows. I
am not sure how information obtained from VPN plugins should work. I
think network manager list has to be used for qualified response. It
seems to me only VPNs configured by NM plugin know configuration details.
Anyway, this leaves 2 unanswered questions, the first of which was my
initial one:
1) how could, when all resolv.conf-as-a-file-by-NM conf has been
removed (by me) and symlink to stub has been restored (by me)
systemd-resolved, with *no trace* of the vpn nameservers in its own
/run/systemd/resolv/resolv.conf nor seemingly nowhere else, can be
still aware of the vpn nameservers (as described in my initial post
scenario) ?
-> is there a persistent systemd-resolved cache on disk somewhere?
I don't think any persistent cache were ever on disk or that it would be
a good idea. Most dns caches are able to dump contents of cache
somewhere on request, but I haven't found a way to do that with resolvectl.
2) when running resolvconf by hand (resolvconf ) providing
specific interface specific nameservers (on stdin), it seems to update
the **global** /run/systemd/resolve/resolv.conf (hence making those
nameservers available for all interfaces ?)
->
