Re: [systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
It was 2014-12-02 wto 00:35, when Lennart Poettering wrote: On Mon, 24.11.14 09:30, Łukasz Stelmach (l.stelm...@samsung.com) wrote: It was 2014-11-21 pią 21:36, when Lennart Poettering wrote: On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case, as sd-network (which will eventually be a public API of libsystems) needs the directory to be around to install an inotify watch. If the directory doesn't exist, and the API is used it will fail entirely, which is suboptimal, given that networkd might be installed later on, and things should then just start to work. Will it be necessary for this directory to be owned by systemd-network even without networkd? Yes. If networkd is compile-time enable the dir should exist and be properly owned, even if it networkd is split off into a separate binary package and currently not installed. And what if the networkd is disabled? Does the directory must exist? Now if networkd is disabled /run/systemd/netif* are not in tmpfiles.d/systemd.conf. Is this correct? If these directories are (going to be) required even with networkd being compile-time disabled, who should own them? Your patch in the version Zbigniew commited looks correct in this regard! Then, I suppose the answers to the above questions are not crucial, however, I am still curious to know them. Kind regards, -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpfXR4R9kWMt.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
On Tue, Dec 2, 2014 at 10:24 AM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2014-12-02 wto 00:35, when Lennart Poettering wrote: On Mon, 24.11.14 09:30, Łukasz Stelmach (l.stelm...@samsung.com) wrote: It was 2014-11-21 pią 21:36, when Lennart Poettering wrote: On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case, as sd-network (which will eventually be a public API of libsystems) needs the directory to be around to install an inotify watch. If the directory doesn't exist, and the API is used it will fail entirely, which is suboptimal, given that networkd might be installed later on, and things should then just start to work. Will it be necessary for this directory to be owned by systemd-network even without networkd? Yes. If networkd is compile-time enable the dir should exist and be properly owned, even if it networkd is split off into a separate binary package and currently not installed. And what if the networkd is disabled? Does the directory must exist? Now if networkd is disabled /run/systemd/netif* are not in tmpfiles.d/systemd.conf. Is this correct? No, if you disable networkd at compile-time the directory is not needed (and using the sd-network library will rightly fail). The reason we need to be able to use the sd-network library in case networkd is enabled, but not installed is that you should be able to start listening, _then_ install networkd, and then be notified of events as if networkd was always installed. However, that only really makes sense if you do enable networkd at comiple-time, but ship it as a separate package. If you disable networkd at compile-time, and then want to introduce it in the distro (as separate package or as part of systemd), I don't think it is unreasonable to expect to have to restart daemons that can optionally integrate with networkd before they start picking up network events. My two cents. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
On Tue, 02.12.14 10:24, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Will it be necessary for this directory to be owned by systemd-network even without networkd? Yes. If networkd is compile-time enable the dir should exist and be properly owned, even if it networkd is split off into a separate binary package and currently not installed. And what if the networkd is disabled? Does the directory must exist? Now if networkd is disabled /run/systemd/netif* are not in tmpfiles.d/systemd.conf. Is this correct? If networkd is compile-time disabled then the directory should go away too. If networkd is compile-time enabled but its split-off binary package not installed then the directory should exist however, since the user might install the package later at which time clients using sd-network should magically start to work. But that they can only if the dir already exists which they can place their inotify watch in. 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] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
It was 2014-12-02 wto 10:31, when Tom Gundersen wrote: On Tue, Dec 2, 2014 at 10:24 AM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2014-12-02 wto 00:35, when Lennart Poettering wrote: On Mon, 24.11.14 09:30, Łukasz Stelmach (l.stelm...@samsung.com) wrote: It was 2014-11-21 pią 21:36, when Lennart Poettering wrote: On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case [...] Will it be necessary for this directory to be owned by systemd-network even without networkd? Yes. If networkd is compile-time enable the dir should exist and be properly owned, even if it networkd is split off into a separate binary package and currently not installed. And what if the networkd is disabled? Does the directory must exist? Now if networkd is disabled /run/systemd/netif* are not in tmpfiles.d/systemd.conf. Is this correct? No, if you disable networkd at compile-time the directory is not needed (and using the sd-network library will rightly fail). [...] My two cents. That gives about three with Lennart's ;-) Thanks. -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpi3VhhEFhKi.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
On Mon, 24.11.14 09:30, Łukasz Stelmach (l.stelm...@samsung.com) wrote: It was 2014-11-21 pią 21:36, when Lennart Poettering wrote: On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case, as sd-network (which will eventually be a public API of libsystems) needs the directory to be around to install an inotify watch. If the directory doesn't exist, and the API is used it will fail entirely, which is suboptimal, given that networkd might be installed later on, and things should then just start to work. Will it be necessary for this directory to be owned by systemd-network even without networkd? Yes. If networkd is compile-time enable the dir should exist and be properly owned, even if it networkd is split off into a separate binary package and currently not installed. Your patch in the version Zbigniew commited looks correct in this regard! Thanks! 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] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
It was 2014-11-21 pią 21:36, when Lennart Poettering wrote: On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case, as sd-network (which will eventually be a public API of libsystems) needs the directory to be around to install an inotify watch. If the directory doesn't exist, and the API is used it will fail entirely, which is suboptimal, given that networkd might be installed later on, and things should then just start to work. Will it be necessary for this directory to be owned by systemd-network even without networkd? -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpii7s5h9dwS.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. --- Alternatively the files may be prepared to be processed with M4, which may be useful to conditionaly include lines for other optional services. Makefile.am | 10 ++ sysusers.d/systemd-networkd.conf | 8 sysusers.d/systemd.conf | 1 - tmpfiles.d/systemd-networkd.conf | 12 tmpfiles.d/systemd.conf | 3 --- 5 files changed, 30 insertions(+), 4 deletions(-) create mode 100644 sysusers.d/systemd-networkd.conf create mode 100644 tmpfiles.d/systemd-networkd.conf diff --git a/Makefile.am b/Makefile.am index 3f9f3fa..8f0f290 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5164,6 +5164,16 @@ networkctl_LDADD = \ libsystemd-shared.la \ libsystemd-network.la +if ENABLE_TMPFILES +dist_tmpfiles_DATA += \ + tmpfiles.d/systemd-networkd.conf +endif + +if ENABLE_SYSUSERS +dist_sysusers_DATA += \ + sysusers.d/systemd-networkd.conf +endif + test_network_SOURCES = \ src/network/test-network.c diff --git a/sysusers.d/systemd-networkd.conf b/sysusers.d/systemd-networkd.conf new file mode 100644 index 000..208148d --- /dev/null +++ b/sysusers.d/systemd-networkd.conf @@ -0,0 +1,8 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +u systemd-network - systemd Network Management diff --git a/sysusers.d/systemd.conf b/sysusers.d/systemd.conf index 95437b8..3da0901 100644 --- a/sysusers.d/systemd.conf +++ b/sysusers.d/systemd.conf @@ -7,6 +7,5 @@ g systemd-journal - - u systemd-bus-proxy - systemd Bus Proxy -u systemd-network - systemd Network Management u systemd-resolve - systemd Resolver u systemd-timesync - systemd Time Synchronization diff --git a/tmpfiles.d/systemd-networkd.conf b/tmpfiles.d/systemd-networkd.conf new file mode 100644 index 000..2419755 --- /dev/null +++ b/tmpfiles.d/systemd-networkd.conf @@ -0,0 +1,12 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +# See tmpfiles.d(5) for details + +d /run/systemd/netif 0755 systemd-network systemd-network - +d /run/systemd/netif/links 0755 systemd-network systemd-network - +d /run/systemd/netif/leases 0755 systemd-network systemd-network - diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index 9ca5ad2..57fc261 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -16,9 +16,6 @@ d /run/systemd/sessions 0755 root root - d /run/systemd/users 0755 root root - d /run/systemd/machines 0755 root root - d /run/systemd/shutdown 0755 root root - -d /run/systemd/netif 0755 systemd-network systemd-network - -d /run/systemd/netif/links 0755 systemd-network systemd-network - -d /run/systemd/netif/leases 0755 systemd-network systemd-network - d /run/log 0755 root root - -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case, as sd-network (which will eventually be a public API of libsystems) needs the directory to be around to install an inotify watch. If the directory doesn't exist, and the API is used it will fail entirely, which is suboptimal, given that networkd might be installed later on, and things should then just start to work. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
