[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Norbert Lange]

This supports 4 plugins, each will be added at the right
spot if enabled, based on the template coming with systemd.

The sed replacements are carefully written to be idempotent,
and to be robust enough to be combined with the other
available packages (nss_mdns4) in any installation order.

nss-systemd is used for the DynamicUser features,
which is a defacto necessity for systemd.
It handles transient users/groups without
touching the /etc/{passwd,group} files on disk.

nss-myhostname allows resolving the hostname,
again without touching files in /etc.

nss-mymachines adds name resolution from containers
supported by machined.
users from the containers might end up in system groups,
so groups should be merged.

nss-resolve is part of resolved, and required for
consistent dns lookups.

we anchor nss_resolve to appear after files, if mymachines is also
used, remove that first (and add it back later). Other packages
(mdns4) move around the dns entry, so replacing that is not a
good option.

if mdns4 is installed aswell, then resolved will take precedence
for host lookups.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
v3:
*   basically a rewrite
*   tested together with nss_mdns4 replacements
---
 package/systemd/systemd.mk | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 8e01a0db5b..2e6c81bd75 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -473,7 +473,27 @@ define SYSTEMD_INSTALL_MACHINEID_HOOK
 	touch $(TARGET_DIR)/etc/machine-id
 endef
 
+# anchor nss_resolve after files, if mymachines is also used, remove that first
+# and add it back. this is necessary as other packages (mdns) move around
+# the dns entry.
+
+define SYSTEMD_ADD_NSSCONFIG_HOOK
+	$(SED) '/^passwd:/ {/systemd/! s/$$/ systemd/}' \
+		-e '/^group:/ {/systemd/! s/$$/ systemd/}' \
+		$(if $(BR2_PACKAGE_SYSTEMD_RESOLVED), \
+			-e '/^hosts:/ s/[[:space:]]*mymachines//' \
+			-e '/^hosts:/ {/resolve/! s/files/files resolve [!UNAVAIL=return]/}' ) \
+		$(if $(BR2_PACKAGE_SYSTEMD_MYHOSTNAME), \
+			-e '/^hosts:/ {/myhostname/! s/$$/ myhostname/}' ) \
+		$(if $(BR2_PACKAGE_SYSTEMD_MACHINED), \
+			-e '/^passwd:/ {/mymachines/! s/files/files mymachines/}' \
+			-e '/^group:/ {/mymachines/! s/files/files [SUCCESS=merge] mymachines [SUCCESS=merge]/}' \
+			-e '/^hosts:/ {/mymachines/! s/files/files mymachines/}' ) \
+		$(TARGET_DIR)/etc/nsswitch.conf
+endef
+
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
+	SYSTEMD_ADD_NSSCONFIG_HOOK \
 	SYSTEMD_INSTALL_INIT_HOOK \
 	SYSTEMD_INSTALL_MACHINEID_HOOK \
 	SYSTEMD_INSTALL_RESOLVCONF_HOOK
-- 
2.27.0

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Yann E. MORIN]

Norbert, All,

On 2020-07-04 01:49 +0200, Norbert Lange spake thusly:
> This supports 4 plugins, each will be added at the right
> spot if enabled, based on the template coming with systemd.
[--SNIP--]
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> v3:
> *   basically a rewrite
> *   tested together with nss_mdns4 replacements
> ---
>  package/systemd/systemd.mk | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 8e01a0db5b..2e6c81bd75 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -473,7 +473,27 @@ define SYSTEMD_INSTALL_MACHINEID_HOOK
>  	touch $(TARGET_DIR)/etc/machine-id
>  endef
>  
> +# anchor nss_resolve after files, if mymachines is also used, remove that first
> +# and add it back. this is necessary as other packages (mdns) move around
> +# the dns entry.
> +
> +define SYSTEMD_ADD_NSSCONFIG_HOOK
> +	$(SED) '/^passwd:/ {/systemd/! s/$$/ systemd/}' \
> +		-e '/^group:/ {/systemd/! s/$$/ systemd/}' \
> +		$(if $(BR2_PACKAGE_SYSTEMD_RESOLVED), \
> +			-e '/^hosts:/ s/[[:space:]]*mymachines//' \
> +			-e '/^hosts:/ {/resolve/! s/files/files resolve [!UNAVAIL=return]/}' ) \
> +		$(if $(BR2_PACKAGE_SYSTEMD_MYHOSTNAME), \
> +			-e '/^hosts:/ {/myhostname/! s/$$/ myhostname/}' ) \
> +		$(if $(BR2_PACKAGE_SYSTEMD_MACHINED), \
> +			-e '/^passwd:/ {/mymachines/! s/files/files mymachines/}' \
> +			-e '/^group:/ {/mymachines/! s/files/files [SUCCESS=merge] mymachines [SUCCESS=merge]/}' \
> +			-e '/^hosts:/ {/mymachines/! s/files/files mymachines/}' ) \
> +		$(TARGET_DIR)/etc/nsswitch.conf
> +endef
> +
>  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
> +	SYSTEMD_ADD_NSSCONFIG_HOOK \

As I already said: ths must be a target-finalize hook, not a
post-install hook.

Regards,
Yann E. MORIN.

>  	SYSTEMD_INSTALL_INIT_HOOK \
>  	SYSTEMD_INSTALL_MACHINEID_HOOK \
>  	SYSTEMD_INSTALL_RESOLVCONF_HOOK
> -- 
> 2.27.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Norbert Lange]

Am Sa., 4. Juli 2020 um 10:00 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> On 2020-07-04 01:49 +0200, Norbert Lange spake thusly:
> > This supports 4 plugins, each will be added at the right
> > spot if enabled, based on the template coming with systemd.
> [--SNIP--]
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > ---
> > v3:
> > *   basically a rewrite
> > *   tested together with nss_mdns4 replacements
> > ---
> >  package/systemd/systemd.mk | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > index 8e01a0db5b..2e6c81bd75 100644
> > --- a/package/systemd/systemd.mk
> > +++ b/package/systemd/systemd.mk
> > @@ -473,7 +473,27 @@ define SYSTEMD_INSTALL_MACHINEID_HOOK
> >       touch $(TARGET_DIR)/etc/machine-id
> >  endef
> >
> > +# anchor nss_resolve after files, if mymachines is also used, remove that first
> > +# and add it back. this is necessary as other packages (mdns) move around
> > +# the dns entry.
> > +
> > +define SYSTEMD_ADD_NSSCONFIG_HOOK
> > +     $(SED) '/^passwd:/ {/systemd/! s/$$/ systemd/}' \
> > +             -e '/^group:/ {/systemd/! s/$$/ systemd/}' \
> > +             $(if $(BR2_PACKAGE_SYSTEMD_RESOLVED), \
> > +                     -e '/^hosts:/ s/[[:space:]]*mymachines//' \
> > +                     -e '/^hosts:/ {/resolve/! s/files/files resolve [!UNAVAIL=return]/}' ) \
> > +             $(if $(BR2_PACKAGE_SYSTEMD_MYHOSTNAME), \
> > +                     -e '/^hosts:/ {/myhostname/! s/$$/ myhostname/}' ) \
> > +             $(if $(BR2_PACKAGE_SYSTEMD_MACHINED), \
> > +                     -e '/^passwd:/ {/mymachines/! s/files/files mymachines/}' \
> > +                     -e '/^group:/ {/mymachines/! s/files/files [SUCCESS=merge] mymachines [SUCCESS=merge]/}' \
> > +                     -e '/^hosts:/ {/mymachines/! s/files/files mymachines/}' ) \
> > +             $(TARGET_DIR)/etc/nsswitch.conf
> > +endef
> > +
> >  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
> > +     SYSTEMD_ADD_NSSCONFIG_HOOK \
>
> As I already said: ths must be a target-finalize hook, not a
> post-install hook.

I missed that, but I still don't see the argument for that,
did post a v4 as I dont want to get stuck on that.

If the NSSCONFIG_HOOK needs to run after glibc is installed,
this could and IMHO should be done by a dependency to glibc?
There aren't that much "phases" in buildroot, if you want to operate on
the final nsswitch.cfg you now only have PRE_CMD_HOOKS left.

Norbert

>
> Regards,
> Yann E. MORIN.
>
> >       SYSTEMD_INSTALL_INIT_HOOK \
> >       SYSTEMD_INSTALL_MACHINEID_HOOK \
> >       SYSTEMD_INSTALL_RESOLVCONF_HOOK
> > --
> > 2.27.0
> >
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Yann E. MORIN]

Norbert, All,

On 2020-07-04 19:15 +0200, Norbert Lange spake thusly:
> Am Sa., 4. Juli 2020 um 10:00 Uhr schrieb Yann E. MORIN
> <yann.morin.1998@free.fr>:
> > On 2020-07-04 01:49 +0200, Norbert Lange spake thusly:
> > > This supports 4 plugins, each will be added at the right
> > > spot if enabled, based on the template coming with systemd.
[--SNIP--]
> > >  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
> > > +     SYSTEMD_ADD_NSSCONFIG_HOOK \
> > As I already said: ths must be a target-finalize hook, not a
> > post-install hook.
> I missed that, but I still don't see the argument for that,
> did post a v4 as I dont want to get stuck on that.
> 
> If the NSSCONFIG_HOOK needs to run after glibc is installed,
> this could and IMHO should be done by a dependency to glibc?

This has nothing to do on a dependency to glibc: glibc is part of the
toolchain, and the dependency to the toolchain is a given for all target
packages: it is enfirced by the infrastructure. And so, glibc is always
built and installed before any target package.

However, there are three other nss plugins, and they already do the
nsswith.conf tweaks as a target-finalize hook.

So, for consistency with those, systemd must also do the tweaking as a
target-finalize hook. But that is not the main reason...

The main reason is per-paclkage directories and top-level parallel build.

nsswitch.conf is a file installed by one package, so opther packages
should not modify it during their build/install steps, otherwise this
will play badly with per-package directories, which is needed for
top-level parallel build.

Indeed, systemd and nss-pam-ldap (for example) have no dependency one on
the other (and that's OK, because there actually is no dependency,
runtime or build time, so we don't want to introduce it).

So, they would each get their own private copy of nsswitch.conf, and the
one seen and modified by systemd will not contain the changes in the one
seen and modified by nss-pam-ldap, and conversely.

But at the end, each per-package target/ dir are collected to eventually
form the final and complete target/ directory.

And now we have an issue: the nsswitch.conf from two packages are
different, and the last to be copied will win, thus anihilating the
changes from a previous package.

But the target-finalize hooks are called after this gathering of ppd
target/ is done, so it works on the final and definitive nsswitch.conf.

TL;DR: if you need to modify the file of another package, do it in a
target-finalize hook.

> There aren't that much "phases" in buildroot, if you want to operate on
> the final nsswitch.cfg you now only have PRE_CMD_HOOKS left.

No, that is exactly what target-finalize is for. ROOTFS_PRE_CMD_HOOKS
are not here to modify the files, but to fixup the layout is some very
rare corner cases (and the rare corner case I am talking about, was
exactly having systemd run on a read-only filesystem with a working
factory; go check the commit logs for the gory details ;-) ).

Thanks for your v4! :-)  I'll handle itm soonish.

BTW, I have a new version of dbus-broker that is working and clean; I'll
send it later too (test running while I write this email).

Regards,
Yann E. MORIN.

> Norbert
> 
> >
> > Regards,
> > Yann E. MORIN.
> >
> > >       SYSTEMD_INSTALL_INIT_HOOK \
> > >       SYSTEMD_INSTALL_MACHINEID_HOOK \
> > >       SYSTEMD_INSTALL_RESOLVCONF_HOOK
> > > --
> > > 2.27.0
> > >
> >
> > --
> > .-----------------.--------------------.------------------.--------------------.
> > |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> > | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> > | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> > '------------------------------^-------^------------------^--------------------'

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Norbert Lange]

Am Sa., 4. Juli 2020 um 21:27 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> On 2020-07-04 19:15 +0200, Norbert Lange spake thusly:
> > Am Sa., 4. Juli 2020 um 10:00 Uhr schrieb Yann E. MORIN
> > <yann.morin.1998@free.fr>:
> > > On 2020-07-04 01:49 +0200, Norbert Lange spake thusly:
> > > > This supports 4 plugins, each will be added at the right
> > > > spot if enabled, based on the template coming with systemd.
> [--SNIP--]
> > > >  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
> > > > +     SYSTEMD_ADD_NSSCONFIG_HOOK \
> > > As I already said: ths must be a target-finalize hook, not a
> > > post-install hook.
> > I missed that, but I still don't see the argument for that,
> > did post a v4 as I dont want to get stuck on that.
> >
> > If the NSSCONFIG_HOOK needs to run after glibc is installed,
> > this could and IMHO should be done by a dependency to glibc?
>
> This has nothing to do on a dependency to glibc: glibc is part of the
> toolchain, and the dependency to the toolchain is a given for all target
> packages: it is enfirced by the infrastructure. And so, glibc is always
> built and installed before any target package.
>
> However, there are three other nss plugins, and they already do the
> nsswith.conf tweaks as a target-finalize hook.
>
> So, for consistency with those, systemd must also do the tweaking as a
> target-finalize hook. But that is not the main reason...
>
> The main reason is per-paclkage directories and top-level parallel build.
>
> nsswitch.conf is a file installed by one package, so opther packages
> should not modify it during their build/install steps, otherwise this
> will play badly with per-package directories, which is needed for
> top-level parallel build.
>
> Indeed, systemd and nss-pam-ldap (for example) have no dependency one on
> the other (and that's OK, because there actually is no dependency,
> runtime or build time, so we don't want to introduce it).
>
> So, they would each get their own private copy of nsswitch.conf, and the
> one seen and modified by systemd will not contain the changes in the one
> seen and modified by nss-pam-ldap, and conversely.
>
> But at the end, each per-package target/ dir are collected to eventually
> form the final and complete target/ directory.
>
> And now we have an issue: the nsswitch.conf from two packages are
> different, and the last to be copied will win, thus anihilating the
> changes from a previous package.

Ok, thanks for clearing that up.

> But the target-finalize hooks are called after this gathering of ppd
> target/ is done, so it works on the final and definitive nsswitch.conf.
>
> TL;DR: if you need to modify the file of another package, do it in a
> target-finalize hook.
>
> > There aren't that much "phases" in buildroot, if you want to operate on
> > the final nsswitch.cfg you now only have PRE_CMD_HOOKS left.
>
> No, that is exactly what target-finalize is for. ROOTFS_PRE_CMD_HOOKS
> are not here to modify the files, but to fixup the layout is some very
> rare corner cases (and the rare corner case I am talking about, was
> exactly having systemd run on a read-only filesystem with a working
> factory; go check the commit logs for the gory details ;-) ).

I meant if you need an order like
systemd (fixup nsswitch.conf) -> mdns4 (fixup nsswitch.conf) ->
systemd (pickup nsswitch.conf *after all modifications*)

then you are out of luck, and need to use ROOTFS_PRE_CMD_HOOKS,
or use some weird tricks like in [1], where I re-add PURGE_LOCALES.
(I will redo those patches, doing that cleanup in systemd.mk).

Yeah, I see'n that trickery with tmpfiles.d ;)
But I guess multiple lists of PRE_CMD / TARGET_FINALIZE HOOKS would ease
some pains (like adding _EARLY and _LATE variants).

Btw, I use a different approach by pre-creating all used directories,
and mounting /var/tmp as tmpfs. This allows startup without any errors,
intended for when it's not possible to mount the usual overlayfs for RW access.

>
> Thanks for your v4! :-)  I'll handle itm soonish.
>
> BTW, I have a new version of dbus-broker that is working and clean; I'll
> send it later too (test running while I write this email).

Great, I hope I'll get my stuff upstream in time for systemd 246,
should be able to build a pretty lean systemd rootfs with ~16MB size
(~23MB today) then.

Norbert

[1] - https://patchwork.ozlabs.org/project/buildroot/patch/20200206093633.251413-9-nolange79 at gmail.com/

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Yann E. MORIN]

Norbert, All,

On 2020-07-04 22:49 +0200, Norbert Lange spake thusly:
> Am Sa., 4. Juli 2020 um 21:27 Uhr schrieb Yann E. MORIN
> <yann.morin.1998@free.fr>:
> > No, that is exactly what target-finalize is for. ROOTFS_PRE_CMD_HOOKS
> > are not here to modify the files, but to fixup the layout is some very
> > rare corner cases (and the rare corner case I am talking about, was
> > exactly having systemd run on a read-only filesystem with a working
> > factory; go check the commit logs for the gory details ;-) ).
> 
> I meant if you need an order like
> systemd (fixup nsswitch.conf) -> mdns4 (fixup nsswitch.conf) ->
> systemd (pickup nsswitch.conf *after all modifications*)
> 
> then you are out of luck, and need to use ROOTFS_PRE_CMD_HOOKS,

Not even, becasue if two packages define ROOTFS_PRE_CMD_HOOKS, then
those are always run in alphabetical order (based on the package name).

So it's back to square one: there is no way to define dependency order
for hooks inside a step.

> or use some weird tricks like in [1], where I re-add PURGE_LOCALES.
> (I will redo those patches, doing that cleanup in systemd.mk).

Yes, I saw it, and I haven't replied yet because:

  - I don't like that nasty trick, but...
  - I don't have an alternative solution to offer. Not yet...

So I'd have to think about it yet more...

> Yeah, I see'n that trickery with tmpfiles.d ;)
> But I guess multiple lists of PRE_CMD / TARGET_FINALIZE HOOKS would ease
> some pains (like adding _EARLY and _LATE variants).

That would not be very helpful either, because we would tehn want to
have early hooks to run before some other early hooks. This is an
endless errand...

And in the end, if as a end-user of Buildroot,there are things you
really want to be done in a specific order, then there always is the
possibility to provide a post-build script.

> Btw, I use a different approach by pre-creating all used directories,
> and mounting /var/tmp as tmpfs. This allows startup without any errors,
> intended for when it's not possible to mount the usual overlayfs for RW access.

It was my understanding that, should /var be read-only, systemd would
automatically mount a tmpfs on it and populate it with its counterpart
from the factory.

Or something along those lines...

> > Thanks for your v4! :-)  I'll handle itm soonish.
> >
> > BTW, I have a new version of dbus-broker that is working and clean; I'll
> > send it later too (test running while I write this email).
> 
> Great, I hope I'll get my stuff upstream in time for systemd 246,
> should be able to build a pretty lean systemd rootfs with ~16MB size
> (~23MB today) then.

I would say that size should not be the driving force ehind those
changes, because 16MiB is already a lot. If you really are after size,
then sysv-init, busybox, or even openrc are better alternatives (busybox
would make for a ~1.5MiB runtime on uClibc, so a minimalist systemd-based
system is already an order of magnitude bigger than that).

Rather, I think the "surface attack", unused components or unwanted
components, is a better approach to sell these changes.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Norbert Lange]

Am Sa., 4. Juli 2020 um 23:38 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> On 2020-07-04 22:49 +0200, Norbert Lange spake thusly:
> > Am Sa., 4. Juli 2020 um 21:27 Uhr schrieb Yann E. MORIN
> > <yann.morin.1998@free.fr>:
> > > No, that is exactly what target-finalize is for. ROOTFS_PRE_CMD_HOOKS
> > > are not here to modify the files, but to fixup the layout is some very
> > > rare corner cases (and the rare corner case I am talking about, was
> > > exactly having systemd run on a read-only filesystem with a working
> > > factory; go check the commit logs for the gory details ;-) ).
> >
> > I meant if you need an order like
> > systemd (fixup nsswitch.conf) -> mdns4 (fixup nsswitch.conf) ->
> > systemd (pickup nsswitch.conf *after all modifications*)
> >
> > then you are out of luck, and need to use ROOTFS_PRE_CMD_HOOKS,
>
> Not even, becasue if two packages define ROOTFS_PRE_CMD_HOOKS, then
> those are always run in alphabetical order (based on the package name).
>
> So it's back to square one: there is no way to define dependency order
> for hooks inside a step.
>
> > or use some weird tricks like in [1], where I re-add PURGE_LOCALES.
> > (I will redo those patches, doing that cleanup in systemd.mk).
>
> Yes, I saw it, and I haven't replied yet because:
>
>   - I don't like that nasty trick, but...
>   - I don't have an alternative solution to offer. Not yet...
>
> So I'd have to think about it yet more...
>
> > Yeah, I see'n that trickery with tmpfiles.d ;)
> > But I guess multiple lists of PRE_CMD / TARGET_FINALIZE HOOKS would ease
> > some pains (like adding _EARLY and _LATE variants).
>
> That would not be very helpful either, because we would tehn want to
> have early hooks to run before some other early hooks. This is an
> endless errand...

Sure, but it would be enough to properly fix a few corner cases.

> And in the end, if as a end-user of Buildroot,there are things you
> really want to be done in a specific order, then there always is the
> possibility to provide a post-build script.

And everything you do might depend on several packages, and be broken in
the future. The more you get into buildroot the more reliable (tested) it gets,
only downside is that you have to clean up the mess first ;)

>
> > Btw, I use a different approach by pre-creating all used directories,
> > and mounting /var/tmp as tmpfs. This allows startup without any errors,
> > intended for when it's not possible to mount the usual overlayfs for RW access.
>
> It was my understanding that, should /var be read-only, systemd would
> automatically mount a tmpfs on it and populate it with its counterpart
> from the factory.

Nope, not to my knowlegde. there is the volatile-root service [1]
which can create you a tmpfs
and either use it as overlayfs over the whole rootfs, or AFAIU just
the rootfs /usr directory/mountpoint
will be used (/etc and /var being empty).
Thing is, this only works if systemd is running in the initramfs, Id
guess in buildroot you build either
the real root *or* the initramfs (v246 will have an option 'initrd'
for that reason)

> Or something along those lines...
>
> > > Thanks for your v4! :-)  I'll handle itm soonish.
> > >
> > > BTW, I have a new version of dbus-broker that is working and clean; I'll
> > > send it later too (test running while I write this email).
> >
> > Great, I hope I'll get my stuff upstream in time for systemd 246,
> > should be able to build a pretty lean systemd rootfs with ~16MB size
> > (~23MB today) then.
>
> I would say that size should not be the driving force ehind those
> changes, because 16MiB is already a lot. If you really are after size,
> then sysv-init, busybox, or even openrc are better alternatives (busybox
> would make for a ~1.5MiB runtime on uClibc, so a minimalist systemd-based
> system is already an order of magnitude bigger than that).

it's a matter of functionality vs size, I went from a busybox rootfs to systemd,
after adding supervisord, network supervision, socketactivation and eudev
and tying all together proved nontrivial.
I still dont like having sysv compatibility, dbus and services for
initrd if I dont use it.

> Rather, I think the "surface attack", unused components or unwanted
> components, is a better approach to sell these changes.

Size is a bad but easy to sell measurement for exactly that
(especially for non-techs).

Regards, Norbert

[1] - https://www.freedesktop.org/software/systemd/man/systemd-volatile-root.service.html

[Buildroot] [PATCH v3] package/systemd: register NSS plugins in nsswitch.conf

[Yann E. MORIN]

Norbert, All,

On 2020-07-05 00:17 +0200, Norbert Lange spake thusly:
> Am Sa., 4. Juli 2020 um 23:38 Uhr schrieb Yann E. MORIN
> <yann.morin.1998@free.fr>:
[--SNIP--]
> > It was my understanding that, should /var be read-only, systemd would
> > automatically mount a tmpfs on it and populate it with its counterpart
> > from the factory.
> Nope, not to my knowlegde.

Right, it is us mounting a tmpfs on /var when / is on a read-only
filesystem, but then as /var is then empty, then systemd populates it
with the content from the factory.

[--SNIP--]
> > Rather, I think the "surface attack", unused components or unwanted
> > components, is a better approach to sell these changes.
> Size is a bad but easy to sell measurement for exactly that
> (especially for non-techs).

Hey! You're not speaking top non-tech people here! ;-)

Or so I hope... [snicker] r-]

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'