Re: [systemd-devel] Antw: [EXT] Re: tmpfiles chicken-egg problem
Am 26.08.20 um 16:01 schrieb Ulrich Windl: Lennart Poettering schrieb am 26.08.2020 um 15:40 > in > Nachricht <20200826134031.GA257903@gardel-login>: >> On Mi, 26.08.20 08:37, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) > wrote: >> >>> Hi! >>> >>> I see this problem in SLES12 (systemd‑228‑157.12.5.x86_64): On boot systemd > >> tries to use LDAP to resolve user names, resulting in an error like this: >>> systemd‑tmpfiles: nss‑ldap: do_open: do_start_tls failed:stat=‑1 >> >> Files and directories managed by systemd‑tmpfiles have to be owned by >> *system* users and groups. If you declare files/dirs that are owned by >> non‑system users, then you are on your own, and things will fall apart. >> >> A system user must be resolvable during the entire runtime of the >> system, i.e. managed in /etc/passwd and /etc/group, not in LDAP. >> >> This is extensively documented in tmpfiles.d(5) or here: >> >> https://systemd.io/UIDS‑GIDS/#notes‑on‑resolvability‑of‑user‑and‑group‑names > >> >> Hence, if this happens your setup is borked in some way: some entries >> in tmpfiles.d/ drop‑ins are owned by users/groups managed by LDAP. Fix >> that, and everything should be fine. > > It's all transitional in some way. In the past a system user was a user with a > UID below the UIDs given to interactive users. Directories existed right from > the beginning of the boot, and the user had to be known when a corresponding > process had to be started. Not earlier. Systemd redefined the world, so don't > point at the world if things are broken now... did you skip the follow-up paragraph by intention to repeat "Systemd redefined the world, so don't point at the world"? just create directories when the process has to be startet eiter by ExecStartPre or RuntimeDirectory/StateDirectory and you are done And besides that, we actually push people towards using RuntimeDirectory=, StateDirectory=, … and stuff so that these dirs are created when the service is started and not earlier, for services where that works. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Re: tmpfiles chicken-egg problem
>>> Lennart Poettering schrieb am 26.08.2020 um 15:40 in Nachricht <20200826134031.GA257903@gardel-login>: > On Mi, 26.08.20 08:37, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> Hi! >> >> I see this problem in SLES12 (systemd‑228‑157.12.5.x86_64): On boot systemd > tries to use LDAP to resolve user names, resulting in an error like this: >> systemd‑tmpfiles: nss‑ldap: do_open: do_start_tls failed:stat=‑1 > > Files and directories managed by systemd‑tmpfiles have to be owned by > *system* users and groups. If you declare files/dirs that are owned by > non‑system users, then you are on your own, and things will fall apart. > > A system user must be resolvable during the entire runtime of the > system, i.e. managed in /etc/passwd and /etc/group, not in LDAP. > > This is extensively documented in tmpfiles.d(5) or here: > > https://systemd.io/UIDS‑GIDS/#notes‑on‑resolvability‑of‑user‑and‑group‑names > > Hence, if this happens your setup is borked in some way: some entries > in tmpfiles.d/ drop‑ins are owned by users/groups managed by LDAP. Fix > that, and everything should be fine. It's all transitional in some way. In the past a system user was a user with a UID below the UIDs given to interactive users. Directories existed right from the beginning of the boot, and the user had to be known when a corresponding process had to be started. Not earlier. Systemd redefined the world, so don't point at the world if things are broken now... I know that it's not all perfect, and I'm working on it... wondering: if I'd un-tar the temporary directorires on boot, the UDIs would be stored correctly in the tar... That would add compatibility to pre-systemd times... [...] Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: tmpfiles chicken-egg problem
On Mi, 26.08.20 16:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > Hence, if this happens your setup is borked in some way: some entries > > in tmpfiles.d/ drop‑ins are owned by users/groups managed by LDAP. Fix > > that, and everything should be fine. > > It's all transitional in some way. In the past a system user was a user with a > UID below the UIDs given to interactive users. This didn't change, system users are still the ones with the low UIDs. > Directories existed right from the beginning of the boot, and the > user had to be known when a corresponding process had to be > started. Not earlier. Systemd redefined the world, so don't point at > the world if things are broken now... Nah, the the major difference is that we document this behaviour, and previously it just failed miraculously with no explanation in the docs, because there were no docs on the requirements. tmpfiles.d/ replaces a bunch of early boot shell scripts, that's all. tmpfiles.d/ is run in early boot, just like those early boot shell scripts it replaces. And what applied to them applies to tmpfiles.d/ here, except we actually spell it out in the man page and the docs otherwise. And besides that, we actually push people towards using RuntimeDirectory=, StateDirectory=, … and stuff so that these dirs are created when the service is started and not earlier, for services where that works. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
