Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
The one that produces the messages is 249.11 (that is running in a docker container): https://packages.ubuntu.com/jammy/systemd The one running on the host is 215-17 (Debian 8). > But it sounds like systemd issue in one specific version you are using. On hosts with newer Debians the issue doesn't manifest itself (the systemd version inside docker remains the same). I'm trying to figure out what exactly is happening on Debian 8. If not a systemd issue... The things that come to mind are: a) the process is waiting to release some resources after exit() or return from main(), b) something PAM- or dbus-related, c) some threads that don't let it exit. Not a C programmer to know if those are possible (if something can not let a process terminate after exit() or return from main()). On Tue, May 10, 2022 at 8:09 AM Andrei Borzenkov wrote: > > On 09.05.2022 23:43, Yuri Kanivetsky wrote: > > Hi Andrei, > > > > Thanks for the suggestion. It becomes more verbose, but it still seems > > like `systemd` fails to notice that `gnome-keyring` exited: > > > > Probably > > ... > > > > > The child exits: > > > > May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[314]: -- main: > > return 0, gkd-main.c:1210 > > May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[314]: -- main: return > > 0, gkd-main.c:1210 > > May 09 17:52:47 cb6d1c84f84e systemd[106]: Child 314 > > (gnome-keyring-d) died (code=exited, status=0/SUCCESS) > > May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > Child 314 belongs to gnome-keyring.service. > > May 09 17:52:47 cb6d1c84f84e systemd[106]: Received SIGCHLD from > > PID 314 (n/a). > > What I miss is "cgroup is empty" message. For comparison: > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Received SIGCHLD from > PID 73346 (sleep). > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Child 73346 (sleep) > died (code=exited, status=0/SUCCESS) > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Child > 73346 belongs to oneshot.service. > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: > Control group is empty. > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: > Succeeded. > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: > Service will not restart (restart setting) > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: > Changed stop-sigterm -> dead > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Job > 986 oneshot.service/start finished, result=done > > May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Finished test oneshot > forking service. > > > You never mentioned your systemd version so it is hard to say anything. > But it sounds like systemd issue in one specific version you are using. > > > > > The org.freedesktop.secrets service is activated: > > > > May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000 > > pid=124] Activating service name='org.freedesktop.secrets' requested > > by ':1.16' (uid=1000 pid=243 comm="/usr/libexec/xdg-desktop-portal ") > > May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: -- main: > > gkd-main.c:1046 > > May 09 17:52:47 cb6d1c84f84e org.freedesktop.secrets[348]: > > gnome-keyring-daemon: no process capabilities, insecure memory might > > get used > > May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[348]: couldn't > > access control socket: /run/user/1000/keyring/control: No such file or > > directory > > May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: couldn't access > > control socket: /run/user/1000/keyring/control: No such file or > > directory > > May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000 > > pid=124] Successfully activated service 'org.freedesktop.secrets' > > > > The gnome-keyring service times out: > > > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > State 'stop-sigterm' timed out. Killing. > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > Failed with result 'timeout'. > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > Service will not restart (restart setting) > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > Changed stop-sigterm -> failed > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > Job 167 gnome-keyring.service/start finished, result=failed > > May 09 17:54:17 cb6d1c84f84e systemd[106]: Failed to start Start > > gnome-keyring for the Secrets Service, and PKCS #11. > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > > Unit entered failed state. > > > > More info here: > > > > https://gist.github.com/x-yuri/b12e8178a621372a4aa62c60693af37b#file-b-journal-gnome-keyring-gist-md > > > > Do you know any reason a process can remain alive after exit() or > > return from main()? Any threads started by PAM or anything > > dbus-related (wild guesses on my part)? Anything else I
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
On 09.05.2022 23:43, Yuri Kanivetsky wrote: > Hi Andrei, > > Thanks for the suggestion. It becomes more verbose, but it still seems > like `systemd` fails to notice that `gnome-keyring` exited: > Probably ... > > The child exits: > > May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[314]: -- main: > return 0, gkd-main.c:1210 > May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[314]: -- main: return > 0, gkd-main.c:1210 > May 09 17:52:47 cb6d1c84f84e systemd[106]: Child 314 > (gnome-keyring-d) died (code=exited, status=0/SUCCESS) > May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Child 314 belongs to gnome-keyring.service. > May 09 17:52:47 cb6d1c84f84e systemd[106]: Received SIGCHLD from > PID 314 (n/a). What I miss is "cgroup is empty" message. For comparison: May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Received SIGCHLD from PID 73346 (sleep). May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Child 73346 (sleep) died (code=exited, status=0/SUCCESS) May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Child 73346 belongs to oneshot.service. May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Control group is empty. May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Succeeded. May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Service will not restart (restart setting) May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Changed stop-sigterm -> dead May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Job 986 oneshot.service/start finished, result=done May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Finished test oneshot forking service. You never mentioned your systemd version so it is hard to say anything. But it sounds like systemd issue in one specific version you are using. > > The org.freedesktop.secrets service is activated: > > May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000 > pid=124] Activating service name='org.freedesktop.secrets' requested > by ':1.16' (uid=1000 pid=243 comm="/usr/libexec/xdg-desktop-portal ") > May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: -- main: > gkd-main.c:1046 > May 09 17:52:47 cb6d1c84f84e org.freedesktop.secrets[348]: > gnome-keyring-daemon: no process capabilities, insecure memory might > get used > May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[348]: couldn't > access control socket: /run/user/1000/keyring/control: No such file or > directory > May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: couldn't access > control socket: /run/user/1000/keyring/control: No such file or > directory > May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000 > pid=124] Successfully activated service 'org.freedesktop.secrets' > > The gnome-keyring service times out: > > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > State 'stop-sigterm' timed out. Killing. > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Failed with result 'timeout'. > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Service will not restart (restart setting) > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Changed stop-sigterm -> failed > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Job 167 gnome-keyring.service/start finished, result=failed > May 09 17:54:17 cb6d1c84f84e systemd[106]: Failed to start Start > gnome-keyring for the Secrets Service, and PKCS #11. > May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: > Unit entered failed state. > > More info here: > > https://gist.github.com/x-yuri/b12e8178a621372a4aa62c60693af37b#file-b-journal-gnome-keyring-gist-md > > Do you know any reason a process can remain alive after exit() or > return from main()? Any threads started by PAM or anything > dbus-related (wild guesses on my part)? Anything else I can check? > > Regards, > Yuri > > On Thu, May 5, 2022 at 8:19 AM Andrei Borzenkov wrote: >> >> On 05.05.2022 04:41, Yuri Kanivetsky wrote: >>> Hi, >>> >>> This might be not a systemd issue. But the behavior is weird, and I'm not >>> sure. >>> >>> I'm trying to run GNOME in a docker container. And gnome-keyring fails to >>> start: >>> >>> https://gist.github.com/x-yuri/c3c715ea6355633de4546ae957a66410 >>> >>> I added debug statements, and in the log I see: >>> >>> May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start >>> gnome-keyring for the Secrets Service, and PKCS #11... >>> May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- main: 1046 >>> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: >>> gnome-keyring-daemon: no process capabilities, insecure memory might >>> get used >>> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- >>> fork_and_print_environment: fork(), parent, 653 >>> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- >>>
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On 5/9/22 13:27, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 09, 2022 at 03:57:21PM +0200, Lennart Poettering wrote: >> On Mo, 09.05.22 11:23, Thomas Haller (thal...@redhat.com) wrote: >> >>> Hi everybody, >>> >>> this email is for discussing MACAddressPolicy=persistent in >>> /data/src/systemd/network/99-default.link >> >> I think this would be better discussed on a new github issue, as >> suggested here: > > I suggested systemd-devel for this… It's not a question of a bug, > but instead whether the default MACAddressPolicy makes sense. So I think > it's better to discuss this on the mailing list. > > FWIW, I still think it's a better _default_. The patch that finally > introduced this was my patch [1], so I'm obviously biased… Some more > considerations: > > 1. this allows bridge devices to be created without attached > interfaces, and have a stable MAC address. > > 2. the idea that all interfaces are always available and always in the > same order is something that isn't necessarilly true for modern systems > where we want to react to hardware being detected dynamically. > If we wait until late userspace to configure networking, then yeah, all > devices will most likely have been detected by that time. But if we want > to bring networking in the initrd, not all hardware must be detected by > the time we start configuration. > > 3. one of the reasons to use bridge/bond and similar devices it that > the agreggate device can function when some of the child devices die. > By requiring the presence of one of the devices, we're partially > defeating this. > > [1] https://github.com/systemd/systemd/commit/6d36464065 > >> 1) for bridge/bond interfaces, there is a special meaning of leaving >> the MAC address unassigned. It causes kernel to automatically set the >> MAC address when the first port gets attached. By setting a persistent >> MAC address, that automatism is not longer possible. >> >> The MAC address can matter, for example, if you configure the DHCP >> server to hand out IP addresses based on the MAC address (or based on >> the client-id, which in turn might be based on the MAC address). If you >> boot many machines (e.g. in data center or cloud), you might know the >> MAC address of the machines, and thereby can also determine the >> assigned IP addresses. With MACAddressPolicy=persistent the MAC address >> is not predictable. > > This is true. But one can just as well argument that with > MACAddressPolicy=persistent the address is even more predictable. If > you know the machine-id and device name, you can calculate the address > in advance, even before deciding if the device will e.g. have this or > that card attached. Regarding machine-id, isn't that unique and set on first boot? So you don't really even know your "new mac address" until your system is up and running (and now can't get DHCP because your net is locked down). For me it's more about expectations and the user being surprised, which isn't necessarily a bug. If I'm controlling a datacenter (or even my 10s of devices on my home network) I generally know what hardware exists in the environment and don't want to be surprised to see activity from "unexpected hardware". I lock down my DHCP via MAC address of the known hardware NICs in the lab/DC. Often times hardware gets racked and configured in the datacenter environment before it can even be powered on. You get the MAC address from the documentation (labels, stickers, etc) and have your network admins plumb through the necessary bits. I understand your arguments for the new behavior, but my preference would be to keep the old behavior. > > I'm not sure if we expose this conveniently anywhere… Would it help if > we document how to do this calculation with python one-liner or some > helper? > >> 2) udev changing the MAC address causes races with naive scripts/tools. >> For example: >> >> ip monitor link & >> while : ; do >> ip link del xxx >> ip link add name xxx type dummy \ >> && ip link set xxx addr aa:00:00:00:00:00 \ >> && ip link show xxx | grep -q aa:00:00:00:00:00 \ >> || break >> done > > Again, this is a question of expecations. With MACAP=p, 'dummy' gets > the same address every time, and maybe there's no reason to set it > manually. > > It would be great if we could have 'ip link add' wait for udev to > process the device. Maybe even by default? > > We also discussed adding a kernel command-line switch similar to > net.ifnames= to allow this to be configured globally. Would that > help? Right. I opened that request here: https://github.com/systemd/systemd/issues/23294 I think it helps. I would want to make sure it applied in the initrd as well. > > The cases where the old behaviour is relied on seems to be cases like > the data center described above. But in that case you're creating > local configuration anyway, so dropping in an override should be > acceptable. At least for bonds I'd argue pretty hard that
Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
Hi Andrei, Thanks for the suggestion. It becomes more verbose, but it still seems like `systemd` fails to notice that `gnome-keyring` exited: May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Passing 0 fds to service May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: About to execute /usr/local/bin/gnome-keyring-daemon --start --components pkcs11,secrets May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Forked /usr/local/bin/gnome-keyring-daemon as 310 May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Changed dead -> start May 09 17:52:47 cb6d1c84f84e systemd[106]: Starting Start gnome-keyring for the Secrets Service, and PKCS #11... May 09 17:52:47 cb6d1c84f84e systemd[310]: Skipping PR_SET_MM, as we don't have privileges. May 09 17:52:47 cb6d1c84f84e systemd[310]: gnome-keyring.service: Executing: /usr/local/bin/gnome-keyring-daemon --start --components pkcs11,secrets The main() starts: May 09 17:52:47 cb6d1c84f84e (g-daemon)[310]: -- main: gkd-main.c:1046 A child is forked: May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[310]: -- fork_and_print_environment: fork(), parent, gkd-main.c:653 May 09 17:52:47 cb6d1c84f84e (g-daemon)[310]: -- fork_and_print_environment: fork(), parent, gkd-main.c:653 May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[314]: -- fork_and_print_environment: fork(), child, gkd-main.c:684 May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[314]: -- fork_and_print_environment: fork(), child, gkd-main.c:684 May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[314]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[314]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory The parent exits: May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[310]: -- fork_and_print_environment: exit(0), gkd-main.c:680 May 09 17:52:47 cb6d1c84f84e (g-daemon)[310]: -- fork_and_print_environment: exit(0), gkd-main.c:680 May 09 17:52:47 cb6d1c84f84e systemd[106]: Received SIGCHLD from PID 310 (gnome-keyring-d). May 09 17:52:47 cb6d1c84f84e systemd[106]: Child 310 (gnome-keyring-d) died (code=exited, status=0/SUCCESS) May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Child 310 belongs to gnome-keyring.service. May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Main process exited, code=exited, status=0/SUCCESS (success) May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Changed start -> stop-sigterm The child exits: May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[314]: -- main: return 0, gkd-main.c:1210 May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[314]: -- main: return 0, gkd-main.c:1210 May 09 17:52:47 cb6d1c84f84e systemd[106]: Child 314 (gnome-keyring-d) died (code=exited, status=0/SUCCESS) May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service: Child 314 belongs to gnome-keyring.service. May 09 17:52:47 cb6d1c84f84e systemd[106]: Received SIGCHLD from PID 314 (n/a). The org.freedesktop.secrets service is activated: May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000 pid=124] Activating service name='org.freedesktop.secrets' requested by ':1.16' (uid=1000 pid=243 comm="/usr/libexec/xdg-desktop-portal ") May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: -- main: gkd-main.c:1046 May 09 17:52:47 cb6d1c84f84e org.freedesktop.secrets[348]: gnome-keyring-daemon: no process capabilities, insecure memory might get used May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[348]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000 pid=124] Successfully activated service 'org.freedesktop.secrets' The gnome-keyring service times out: May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: State 'stop-sigterm' timed out. Killing. May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: Failed with result 'timeout'. May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: Service will not restart (restart setting) May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: Changed stop-sigterm -> failed May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: Job 167 gnome-keyring.service/start finished, result=failed May 09 17:54:17 cb6d1c84f84e systemd[106]: Failed to start Start gnome-keyring for the Secrets Service, and PKCS #11. May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service: Unit entered failed state. More info here:
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
(sent previously from different address) Lennart Poettering writes: > On Mo, 09.05.22 18:12, Kamil Jońca (kjo...@op.pl) wrote: > >> For now I do not know how handle multiple interface where: >> 1. set routing according to classles routes from dhcp on some >> interfaces. > > We don't do that anyway? I do not know. When I tried (but it was about year ago) I think it did not work, but later someone on list claims that systemd handle proper DHCP option. > >> 2. set NAT (ie call nftables sctipts) with multitple egress interfaces and >> bunch >> of VM-s inside host. > > we have native NAT support in .network files? what is missing there? Will try. When I find some time. > >> 3. decide where to resolve names based on domain and existence of ipsec >> or openvpn tunnel. > > Sounds like a job for the resolved domain routing logic, which already > exists? Not quite. When I asked previously I got response, that resolved is based on interfaces. But ipsec tunnel does not need dedicated interface. > > it appears you can use what's already there for these cases. And if > not, it seems like we could extend things. > maybe in the end things wouldn't work exactly the same as before, but > should deliver the same results? Yes. > >> With systemd-networkd I even do not know where to start. And when I try >> to test somenthig, almost immediately I see that I systemd cannot do >> something I need. > > Start with the documentation? But take a step back, i.e. what is the > stuff you actually intend to do conceptually, instead of already > assuming the tech you want to do it with. > Let's see. from SYSTEMD.NETWORK(5) ... IPMasquerade= Configures IP masquerading for the network interface. If enabled, packets forwarded from the network interface will be appear as coming from the local host. I still do not know what mean "local host" here. I guess that this will be interface address. :) I still do not know if this is rather "snat" or rather "masquerade". How can I decide which to use. And what engine is used here. I know that networkd cannot handle bridge without ports (quite convenient when you use it as dummy interface with qemu machines) [...] >> I simply want to pass option during disposinng interface up, and expect >> this option will be honored. (IE. interface will be default or >> not.[1]) > > Afaics RouteMetric= [DHCPv4] section already does all you need. just > give the iface whose default route you want to take precedence a lower > metric and you are done. How? By editing files? And what with other examples? > Note anyway that networkd assumes it manages an interface in its > entirety: if you muck with what it sets up it likely will override > your changes sooner or later, when some event happens... you have a I do not want interfere with interfaces "per se" I simply want to get some info from systemd and pass it to dnsmasq (for DNS) or nftables (for filtering) . That's it. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: [systemd-devel] [SPAM] Re: Custom options and passing options via command line.
Kamil Jońca writes: > Let's see. > from SYSTEMD.NETWORK(5) > ... > IPMasquerade= >Configures IP masquerading for the network interface. If >enabled, packets forwarded from the network interface will be >appear as coming from the local host. > > > > I still do not know what mean "local host" here. I guess that this will > be interface address. :) > > I still do not know if this is rather "snat" or rather "masquerade". How > can I decide which to use. And what engine is used here. > Another question: 1. "partial nat" 3 interfaces qemu1 , qemu2, and eth I want to nat treffic from qemu1 via eth but not qemu2 (NB this is the place, where I use mu custom option in /etc/network/interfaces which means "NAT this traffic" ) 2. nat based on destination network. I want to nat only traffic to say, 192.168.10.0/24, leaving rest untouched. (This is case when I have ipsec tunnel and I want to nat only traffic to other endpoint) How to do it? KJ -- http://wolnelektury.pl/wesprzyj/teraz/
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Mon, May 09, 2022 at 03:57:21PM +0200, Lennart Poettering wrote: > On Mo, 09.05.22 11:23, Thomas Haller (thal...@redhat.com) wrote: > > > Hi everybody, > > > > this email is for discussing MACAddressPolicy=persistent in > > /data/src/systemd/network/99-default.link > > I think this would be better discussed on a new github issue, as > suggested here: I suggested systemd-devel for this… It's not a question of a bug, but instead whether the default MACAddressPolicy makes sense. So I think it's better to discuss this on the mailing list. FWIW, I still think it's a better _default_. The patch that finally introduced this was my patch [1], so I'm obviously biased… Some more considerations: 1. this allows bridge devices to be created without attached interfaces, and have a stable MAC address. 2. the idea that all interfaces are always available and always in the same order is something that isn't necessarilly true for modern systems where we want to react to hardware being detected dynamically. If we wait until late userspace to configure networking, then yeah, all devices will most likely have been detected by that time. But if we want to bring networking in the initrd, not all hardware must be detected by the time we start configuration. 3. one of the reasons to use bridge/bond and similar devices it that the agreggate device can function when some of the child devices die. By requiring the presence of one of the devices, we're partially defeating this. [1] https://github.com/systemd/systemd/commit/6d36464065 > 1) for bridge/bond interfaces, there is a special meaning of leaving > the MAC address unassigned. It causes kernel to automatically set the > MAC address when the first port gets attached. By setting a persistent > MAC address, that automatism is not longer possible. > > The MAC address can matter, for example, if you configure the DHCP > server to hand out IP addresses based on the MAC address (or based on > the client-id, which in turn might be based on the MAC address). If you > boot many machines (e.g. in data center or cloud), you might know the > MAC address of the machines, and thereby can also determine the > assigned IP addresses. With MACAddressPolicy=persistent the MAC address > is not predictable. This is true. But one can just as well argument that with MACAddressPolicy=persistent the address is even more predictable. If you know the machine-id and device name, you can calculate the address in advance, even before deciding if the device will e.g. have this or that card attached. I'm not sure if we expose this conveniently anywhere… Would it help if we document how to do this calculation with python one-liner or some helper? > 2) udev changing the MAC address causes races with naive scripts/tools. > For example: > > ip monitor link & > while : ; do > ip link del xxx > ip link add name xxx type dummy \ > && ip link set xxx addr aa:00:00:00:00:00 \ > && ip link show xxx | grep -q aa:00:00:00:00:00 \ > || break > done Again, this is a question of expecations. With MACAP=p, 'dummy' gets the same address every time, and maybe there's no reason to set it manually. It would be great if we could have 'ip link add' wait for udev to process the device. Maybe even by default? We also discussed adding a kernel command-line switch similar to net.ifnames= to allow this to be configured globally. Would that help? The cases where the old behaviour is relied on seems to be cases like the data center described above. But in that case you're creating local configuration anyway, so dropping in an override should be acceptable. Zbyszek > https://github.com/systemd/systemd/issues/3374#issuecomment-1031072530 > > or here: > > https://github.com/systemd/systemd/issues/3374#issuecomment-601240730
Re: [systemd-devel] Custom options and passing options via command line.
On Mo, 09.05.22 18:12, Kamil Jońca (kjo...@op.pl) wrote: > For now I do not know how handle multiple interface where: > 1. set routing according to classles routes from dhcp on some > interfaces. We don't do that anyway? > 2. set NAT (ie call nftables sctipts) with multitple egress interfaces and > bunch > of VM-s inside host. we have native NAT support in .network files? what is missing there? > 3. decide where to resolve names based on domain and existence of ipsec > or openvpn tunnel. Sounds like a job for the resolved domain routing logic, which already exists? it appears you can use what's already there for these cases. And if not, it seems like we could extend things. maybe in the end things wouldn't work exactly the same as before, but should deliver the same results? > With systemd-networkd I even do not know where to start. And when I try > to test somenthig, almost immediately I see that I systemd cannot do > something I need. Start with the documentation? But take a step back, i.e. what is the stuff you actually intend to do conceptually, instead of already assuming the tech you want to do it with. > > or are you saying that you intend to change which one is preferred > > dynamically? but the network callouts à la networkd-dispatcher run at > > configuration time, not on request iiuc... > > I simply want to pass option during disposinng interface up, and expect > this option will be honored. (IE. interface will be default or > not.[1]) Afaics RouteMetric= [DHCPv4] section already does all you need. just give the iface whose default route you want to take precedence a lower metric and you are done. Note anyway that networkd assumes it manages an interface in its entirety: if you muck with what it sets up it likely will override your changes sooner or later, when some event happens... you have a choice: make networkd manage it, or manager it with your own scripts, but interfering with routing via manual "ip" invocations on the interface's routes will sooner or later break. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Custom options and passing options via command line.
Lennart Poettering writes: [...] >> >> I am afraid you will not cover all cases with networking. > > Well, I am not sure. I am pretty sure there are almost always better > ways to fix the issues that people address with network callout stuff. I cannot discuss with your conviction. For now I do not know how handle multiple interface where: 1. set routing according to classles routes from dhcp on some interfaces. 2. set NAT (ie call nftables sctipts) with multitple egress interfaces and bunch of VM-s inside host. 3. decide where to resolve names based on domain and existence of ipsec or openvpn tunnel. With current config there is some scritps (and dnsmasq), pretty simple to write. (When you have some knowledge about networking) With systemd-networkd I even do not know where to start. And when I try to test somenthig, almost immediately I see that I systemd cannot do something I need. >> > In networkd you can configure the route metric via Metric= in the >> > [Route] section. If the routes are acquired through dhcp, you can set >> > the metric to use in the [DHCPv4] section in the RouteMetric= setting, >> > and so on. >> >> But sometimes I want to "override" default route, i.e. I have two >> interfaces configured by DHCP and I want to "force" use particular >> interface. Is this possible via cli? Or I have to deal with creating >> and removing files and "daemon-reload"ing? > > You can use RouteMetric= in the [DHCPv4] section if one of the two > interfaces shall always be the preferred one over the other. > > or are you saying that you intend to change which one is preferred > dynamically? but the network callouts à la networkd-dispatcher run at > configuration time, not on request iiuc... I simply want to pass option during disposinng interface up, and expect this option will be honored. (IE. interface will be default or not.[1]) > KJ [1] - but please treat this as an example only. This also can be additional domain to search. Or additional DNS to use, or ... something. -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: [systemd-devel] Custom options and passing options via command line.
On Mo, 09.05.22 16:13, Kamil Jońca (kjo...@op.pl) wrote: > >> (https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html) > >> there is a possibility to define custom option and passing it to up/down > >> script (see ENVIRONMENT VARIABLES section) > >> Is it possible in *.network files? > > > > We do not support call-outs in networkd, for security and robustness > > reasons. In almost all cases callouts end up being used to hook > > higher-level stuff into lower-level components, which then > > synchronously block on it, which is just the wrong way. > > Hm. What is the network dispatcher then? Do you mean networkd-dispatcher? That's an Ubuntu thing. It does not exist upstream. Maintained by different people, unrelated to the systemd project. > > So usually our approach is to figure out what people actually hook > > into this, and find better solutions. > > I am afraid you will not cover all cases with networking. Well, I am not sure. I am pretty sure there are almost always better ways to fix the issues that people address with network callout stuff. > > In networkd you can configure the route metric via Metric= in the > > [Route] section. If the routes are acquired through dhcp, you can set > > the metric to use in the [DHCPv4] section in the RouteMetric= setting, > > and so on. > > But sometimes I want to "override" default route, i.e. I have two > interfaces configured by DHCP and I want to "force" use particular > interface. Is this possible via cli? Or I have to deal with creating > and removing files and "daemon-reload"ing? You can use RouteMetric= in the [DHCPv4] section if one of the two interfaces shall always be the preferred one over the other. or are you saying that you intend to change which one is preferred dynamically? but the network callouts à la networkd-dispatcher run at configuration time, not on request iiuc... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Mo, 09.05.22 10:35, Neal Gompa (ngomp...@gmail.com) wrote: > > I am pretty sure the answer to this is not to make choice of boot > > loaders configurable, but making them adhere to a common definition > > how boot menu entries are defined, so that it doesn't matter which > > boot loader you are using, the menu items pop up correctly either way. > > > > i.e. if boot loaders would all implement > > https://systemd.io/BOOT_LOADER_SPECIFICATION then there would be a > > very clear way how without trampling on each other's feet multi-boot > > would work... > > Has there been a campaign to get them to do it? Any outreach? Posting > a page on the internet doesn't exactly do anything to get people to > adopt a spec. There was some. I even wrote a patch for Grub and posted it. But there was no positive feedback on that, so we dropped the ball. Back then, grub development was also kinda dead, so it wasn't surprising... It takes a lot of energy and dedication to fight this through if you have no stakes in the community you are trying to convince and that community isn't the most healthy on the planet in the first place — in particular if you don't actually intend to run their code yourself. And that's really how Grub is to us... Besides grub no other boot loader really mattered, as it's pretty much the only boot loader big distros use. Was back then, and still is. I think the Fedora patch for boot loader spec support in grub might actually based on my original work in one way or another, but I am not sure, i never looked at it anymore... To my knowledge that fedora patch never made it upstream though, even though it has been shipped for a long time in fedora? (given the patch extended boot loader spec to become a templating language which I think is not precisely a wise choice I'd rather not be associated with that work though...) Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Mon, May 9, 2022 at 10:30 AM Lennart Poettering wrote: > > On Fr, 06.05.22 10:12, Wols Lists (antli...@youngman.org.uk) wrote: > > > On 27/04/2022 14:53, Lennart Poettering wrote: > > > I think we systematically disagree on one point here: I am pretty sure > > > picking a boot loader is genuinely someting a distro should be doing, > > > and not the admin really. I mean, yes, I personally of course switched > > > away from Fedora's default choice of grub to use sd-boot, and of > > > course I'd prefer if it wasn't such a mess to do so. But also: we > > > should not advertise this as something people should actually do and > > > should make easy to do. > > > > EXCEPT. The boot loader loads the distro. An OS has no say in the computer's > > choice of BIOS/EFI because that's what starts the distro. Same for boot > > loader. > > > > There's a whole bunch of comments on LWN at the moment comparing computers > > to "cattle or pet". For "cattle", yep if the distro chooses the boot loader > > who cares. > > > > But for "pet"s (like my computer), (a) I'm going to need more hand-holding > > because I'm not a professional sys-admin, and (b) my system is multi-boot - > > it's bad enough with distros squabbling over who has control of grub.cfg, > > without them also squabbling over whether it's grub, systemd-bootd, rEFInd, > > LILO, whatever whatever. > > I am pretty sure the answer to this is not to make choice of boot > loaders configurable, but making them adhere to a common definition > how boot menu entries are defined, so that it doesn't matter which > boot loader you are using, the menu items pop up correctly either way. > > i.e. if boot loaders would all implement > https://systemd.io/BOOT_LOADER_SPECIFICATION then there would be a > very clear way how without trampling on each other's feet multi-boot > would work... > Has there been a campaign to get them to do it? Any outreach? Posting a page on the internet doesn't exactly do anything to get people to adopt a spec. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Custom options and passing options via command line.
Lennart Poettering writes: > On So, 08.05.22 19:19, Kamil Jońca (kjo...@op.pl) wrote: > >> I have question about custom options in network interface definitions >> and passing it via command line. >> In currend Debian tools >> >> (https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html) >> there is a possibility to define custom option and passing it to up/down >> script (see ENVIRONMENT VARIABLES section) >> Is it possible in *.network files? > > We do not support call-outs in networkd, for security and robustness > reasons. In almost all cases callouts end up being used to hook > higher-level stuff into lower-level components, which then > synchronously block on it, which is just the wrong way. > Hm. What is the network dispatcher then? > So usually our approach is to figure out what people actually hook > into this, and find better solutions. I am afraid you will not cover all cases with networking. >> Moreover: can I pass option during interface up/down? >> For example, in my if-up*/if-down* scripts I have code for replacing (or >> not!) default route when needed.[1] > > You can have multiple default routes, thus normally you'd install them > all in parallel, and then configure a route metric on each to declare > which one shall win if multiple are in effect. > > In networkd you can configure the route metric via Metric= in the > [Route] section. If the routes are acquired through dhcp, you can set > the metric to use in the [DHCPv4] section in the RouteMetric= setting, > and so on. But sometimes I want to "override" default route, i.e. I have two interfaces configured by DHCP and I want to "force" use particular interface. Is this possible via cli? Or I have to deal with creating and removing files and "daemon-reload"ing? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
> use DNSStubListenerExtra=
It's indeed this directive I'm using on the downstream interface. Maybe
I should have mentioned that.
Configuration / results (MACs etc. obfuscated, but all correct on the
running system):
# head -n-0 /etc/systemd/network/linux-dummy_local0.{netdev,network}
==> /etc/systemd/network/linux-dummy_local0.netdev <==
[NetDev]
Description=[...]
Kind=dummy
Name=local0
==> /etc/systemd/network/linux-dummy_local0.network <==
[Match]
Name=local0
[Network]
Description=[...]
Address=/64
Address=/24
DNSSEC=false
Domains=~home.example.org
LLMNR=false
MulticastDNS=false
# networkctl status local0
5: local0
Link File: /usr/lib/systemd/network/99-default.link
Network File:
/etc/systemd/network/linux-dummy_local0.network
Type: ether
State: routable (configured)
Online state: online
Driver: dummy
Hardware Address:
MTU: 1500
QDisc: noqueue
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 1/1
Address:
*.network>
fe80::[...]
Route Domains: home.example.org
Activation Policy: up
Required For Online: yes
DHCP6 Client DUID: DUID-EN/Vendor:[...]
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: netdev ready
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: Link UP
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: Gained carrier
Mai 08 23:08:07 rpi3b-router systemd-networkd[378]: local0: Gained IPv6LL
# ip address show local0
5: local0: mtu 1500 qdisc noqueue state
UNKNOWN group default qlen 1000
link/ether [...] brd ff:ff:ff:ff:ff:ff
inet [...]/24 brd [...] scope global local0
valid_lft forever preferred_lft forever
inet6 [...]/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::[...]/64 scope link
valid_lft forever preferred_lft forever
# resolvectl status local0
Link 5 (local0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
DNS Domain: ~home.example.org
And with all these results a querying a DNS server on local0 e. g. by
"drill @ home.example.org" works but "resolvectl query
home.example.org" fails.
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Mo, 09.05.22 11:23, Thomas Haller (thal...@redhat.com) wrote: > Hi everybody, > > this email is for discussing MACAddressPolicy=persistent in > /data/src/systemd/network/99-default.link I think this would be better discussed on a new github issue, as suggested here: https://github.com/systemd/systemd/issues/3374#issuecomment-1031072530 or here: https://github.com/systemd/systemd/issues/3374#issuecomment-601240730 I don't think that new issue was ever filed? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Custom options and passing options via command line.
On So, 08.05.22 19:19, Kamil Jońca (kjo...@op.pl) wrote: > I have question about custom options in network interface definitions > and passing it via command line. > In currend Debian tools > > (https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html) > there is a possibility to define custom option and passing it to up/down > script (see ENVIRONMENT VARIABLES section) > Is it possible in *.network files? We do not support call-outs in networkd, for security and robustness reasons. In almost all cases callouts end up being used to hook higher-level stuff into lower-level components, which then synchronously block on it, which is just the wrong way. So usually our approach is to figure out what people actually hook into this, and find better solutions. > Moreover: can I pass option during interface up/down? > For example, in my if-up*/if-down* scripts I have code for replacing (or > not!) default route when needed.[1] You can have multiple default routes, thus normally you'd install them all in parallel, and then configure a route metric on each to declare which one shall win if multiple are in effect. In networkd you can configure the route metric via Metric= in the [Route] section. If the routes are acquired through dhcp, you can set the metric to use in the [DHCPv4] section in the RouteMetric= setting, and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
On Mon, May 9, 2022, 16:35 Peter Mattern wrote: > Hi, Petr. > > > Do you need any systemd-resolved specific features? > Primarily, it's about the way directive Domains allows for directing > queries to particular DNS servers based on the queries' domains. > I'm using it to restrict the ISP's DNS server to the ISP's domain, use a > local DNS server for local subdomains and have a DNS server like Quad 9 > serve all the rest. > This can be achieved with other applications, too, e. g. dnsmasq. But I > find it more handy to configure with networkd/resolved, in particular, > when these are already in use anyway. > > > I don't think resolved considers it common to have more than one DNS > server on the localhost. > As I understand it, it's the very purpose of directive Domains to have > systemd-resolved interact with various different DNS servers. So why > shouldn't one of these run on the same host as resolved? > > > unbound, knot-resolver > These aren't an option. I do not need a cache only, but want to serve > the said local-only subdomain, which also needs to comprise RRs other > than [AAA]A like CNAME, MX or TXT. > I heard Unbound handles that quite well. See the `local-data` option. (As does BIND9 of course.) >
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
Hi, Petr. > Do you need any systemd-resolved specific features? Primarily, it's about the way directive Domains allows for directing queries to particular DNS servers based on the queries' domains. I'm using it to restrict the ISP's DNS server to the ISP's domain, use a local DNS server for local subdomains and have a DNS server like Quad 9 serve all the rest. This can be achieved with other applications, too, e. g. dnsmasq. But I find it more handy to configure with networkd/resolved, in particular, when these are already in use anyway. > I don't think resolved considers it common to have more than one DNS server on the localhost. As I understand it, it's the very purpose of directive Domains to have systemd-resolved interact with various different DNS servers. So why shouldn't one of these run on the same host as resolved? > unbound, knot-resolver These aren't an option. I do not need a cache only, but want to serve the said local-only subdomain, which also needs to comprise RRs other than [AAA]A like CNAME, MX or TXT. > dnsmasq This is indeed what I've been using so far. But I'd like to replace it for several reasons. I'm not happy with its development any more in many ways. The network configuration I need involves things like Prefix Delegation which I find easier to handle with networkd. So dnsmasq is limited to the DNS part, which in turn I'd prefer to configure with a server like Knot. I find this simply easier, e. g. I can use a regular zone file and don't have to memorize a bunch of custom dnsmasq switches. Serving a whole LAN is probably not exactly what resolved was primarily meant for. But my LAN isn't that big and so far having its stub resolver listen on the router's downstream interface is working like a charm. That aside my actual question was, whether resolved shouldn't recognize a DNS server on a Linux dummy interface just the way it recognizes servers on regular hardware links. And I'd find this interesting to know totally independent from the maybe a bit particular rest of my setup.
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
On Mo, 09.05.22 15:32, Lennart Poettering (lenn...@poettering.net) wrote: > On So, 08.05.22 15:00, Peter Mattern (pmatt...@arcor.de) wrote: > > > Hello. > > > > Apparently resolved is ignoring DNS servers which are listening on Linux > > dummy interfaces. > > It should not do that. Are you sure you configured the interfaces > properly, and they are up? > > Provide "networkctl status" output, if in doubt. > > > So can anybody tell me what's the matter here, in particular whether this > > may be a problem of resolved or whether there's a way to get this working > > somehow? > > If this doesn't work, and the iface is up and otherwise properly > configured, then it would be a bug. But I have the suspicion the > interface might simply not be up or have no IP address correctly > configured or so? Note that we go into great length to ensure the stub isn't accessed by remote clients, regardless on which iface it binds. If you want to open this up to remote clients, use DNSStubListenerExtra=, which does not come with such restrictions. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
On So, 08.05.22 15:00, Peter Mattern (pmatt...@arcor.de) wrote: > Hello. > > Apparently resolved is ignoring DNS servers which are listening on Linux > dummy interfaces. It should not do that. Are you sure you configured the interfaces properly, and they are up? Provide "networkctl status" output, if in doubt. > So can anybody tell me what's the matter here, in particular whether this > may be a problem of resolved or whether there's a way to get this working > somehow? If this doesn't work, and the iface is up and otherwise properly configured, then it would be a bug. But I have the suspicion the interface might simply not be up or have no IP address correctly configured or so? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Fr, 06.05.22 10:12, Wols Lists (antli...@youngman.org.uk) wrote: > On 27/04/2022 14:53, Lennart Poettering wrote: > > I think we systematically disagree on one point here: I am pretty sure > > picking a boot loader is genuinely someting a distro should be doing, > > and not the admin really. I mean, yes, I personally of course switched > > away from Fedora's default choice of grub to use sd-boot, and of > > course I'd prefer if it wasn't such a mess to do so. But also: we > > should not advertise this as something people should actually do and > > should make easy to do. > > EXCEPT. The boot loader loads the distro. An OS has no say in the computer's > choice of BIOS/EFI because that's what starts the distro. Same for boot > loader. > > There's a whole bunch of comments on LWN at the moment comparing computers > to "cattle or pet". For "cattle", yep if the distro chooses the boot loader > who cares. > > But for "pet"s (like my computer), (a) I'm going to need more hand-holding > because I'm not a professional sys-admin, and (b) my system is multi-boot - > it's bad enough with distros squabbling over who has control of grub.cfg, > without them also squabbling over whether it's grub, systemd-bootd, rEFInd, > LILO, whatever whatever. I am pretty sure the answer to this is not to make choice of boot loaders configurable, but making them adhere to a common definition how boot menu entries are defined, so that it doesn't matter which boot loader you are using, the menu items pop up correctly either way. i.e. if boot loaders would all implement https://systemd.io/BOOT_LOADER_SPECIFICATION then there would be a very clear way how without trampling on each other's feet multi-boot would work... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] resolved vs. DNS servers listening on Linux dummy interfaces
Hi Peter, is there a reason why do you want resolved to serve whole LAN? It has its problems and I think its authors meant it as localhost cache. I don't think resolved considers it common to have more than one DNS server on the localhost. Is there a reason why you wouldn't use dnsmasq, unbound or knot-resolver instead, which are more common on routers? Do you need any systemd-resolved specific features? Like mDNS or LLMNR resolution? On 5/8/22 15:00, Peter Mattern wrote: > Hello. > > Apparently resolved is ignoring DNS servers which are listening on > Linux dummy interfaces. > > When directive "Domains" in section [Network] of the dummy interface's > *.network unit is set as usual, "resolvectl status " > still shows "Current Scopes: none" and "resolvectl query handled by the server>" fails. > Seen on up to date Arch Linux with the network setup handled > completely by networkd/resolved. As DNS servers dnsmasq and Knot were > tested, both were working as expected on that interface type according > to drill queries pointing to the interface's IP. > > Use case is a router on which I'd like to use Knot to serve a > subdomain used in the LAN only while leaving the upstream interface to > the ISP's DNS server and having resolved's stub resolver provide DNS > to the LAN on the downstream interface. > Tbh. I'm not even sure whether Linux dummy interfaces are meant for a > purpose like this. But given that both servers (as well as nginx, > btw.) seem to work well on the interface I'd actually expect resolved > to pick them. > > So can anybody tell me what's the matter here, in particular whether > this may be a problem of resolved or whether there's a way to get this > working somehow? > > Regards > > Peter Mattern > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
[systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
Hi everybody, this email is for discussing MACAddressPolicy=persistent in /data/src/systemd/network/99-default.link there is a Fedora CoreOS issue about this: [1] https://github.com/coreos/fedora-coreos-tracker/issues/919 Since systemd 242 (Apr 2019), this policy applies to more device types ([2]). [2] https://github.com/systemd/systemd/blob/v247/NEWS#L2332-L2358 This topic was already discussed. For example at [3]. I also brought this up before at [4], but I'd like to reopen this discussion with the recent Fedora CoreOS issue. [3] https://github.com/systemd/systemd/issues/3374 [4] https://github.com/systemd/systemd/issues/3374#issuecomment-522528484 To reiterate, this causes two problems: 1) for bridge/bond interfaces, there is a special meaning of leaving the MAC address unassigned. It causes kernel to automatically set the MAC address when the first port gets attached. By setting a persistent MAC address, that automatism is not longer possible. The MAC address can matter, for example, if you configure the DHCP server to hand out IP addresses based on the MAC address (or based on the client-id, which in turn might be based on the MAC address). If you boot many machines (e.g. in data center or cloud), you might know the MAC address of the machines, and thereby can also determine the assigned IP addresses. With MACAddressPolicy=persistent the MAC address is not predictable. 2) udev changing the MAC address causes races with naive scripts/tools. For example: ip monitor link & while : ; do ip link del xxx ip link add name xxx type dummy \ && ip link set xxx addr aa:00:00:00:00:00 \ && ip link show xxx | grep -q aa:00:00:00:00:00 \ || break done granted, a script should either set the MAC address from the start, or it should wait for udev to settle. Still, how many tools out there are (still) broken? On RHEL, 99-default.link is patched to set MACAddressPolicy=none. On Fedora, despite this behavior being there for a while now, I think it's harmful and should be dropped as well... at least for bridges/bonds (problem 1) or even all software devices (problem 2). In my opionion, this approach should be reconsidered for udev in general. best, Thomas signature.asc Description: This is a digitally signed message part
