Antw: Re: systemd-tmpfiles-setup.service failed due to LDAP resolving

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 22.05.2019 um 10:30
in
Nachricht <20190522083028.GA30001@gardel-login>:
> On Mi, 22.05.19 10:02, Ulrich Windl (Ulrich.Windl@xxxxxx‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Obviously the owner of a temporary directory cannot be an LDAP user:
> 
> system users should really not be located on LDAP:

OK, but it's a challenge to keep the UIDs in sync on multiple hosts for local
users.

> 
>
https://systemd.io/UIDS‑GIDS.html#notes‑on‑resolvability‑of‑user‑and‑group‑names

> 
>> May 22 09:02:48 v04 systemd‑tmpfiles[1056]: nss‑ldap: do_open:
do_start_tls
>> failed:stat=‑1
>> May 22 09:02:48 v04 systemd‑tmpfiles[1056]: nss_ldap: could not search
LDAP
>> server ‑ Server is unavailable
>> May 22 09:02:48 v04 systemd[1]: systemd‑tmpfiles‑setup.service: Main
process
>> exited, code=exited, status=1/FAILURE
> 
> Hmm, we actually log about all errors we encounter. Is it possible
> that the nss‑ldap module (which iirc is obsolete and unmaintained
> these days?) does an exit(1) or so?

It seems I had overlooked the message (maybe because "systemd-tmpfiles:
nss-ldap: do_open: do_start_tls failed:stat=-1" continue after the last
error):
systemd-tmpfiles[3051]: [/usr/lib/tmpfiles.d/FCmonitor.conf:1] Unknown group
'nagios'.

> 
> Either way, if we receive an error from NSS and don't log about it,
> that'd be a bug, but please confirm with a current systemd version, or
> contact your downstream who will do that and then propagate this to
> us.
> 
> You can also set the "SYSTEMD_LOG_LEVEL=debug" env var to get more
> detailed output. i.e. use "systemctl edit systemd‑tmpfiles.service",
> then type in:
> 
> [Service]
> Environment=SYSTEMD_LOG_LEVEL=debug
> 
> then save and reboot.
> 
>> The basic problem is that LDAP needs network (which isn't up at this
point).
>> But still, it's hard to tell from the logged messages which entry actually
>> caused the problem. From what I see "root" is the only user being used,
and
>> that user is local in /etc/passwd. /etc/nsswitch.conf has "passwd: 
> compat"...
>>
>> I can create the missing directories later running "systemctl start
>> systemd‑tmpfiles‑setup", but SLES has:
>> /usr/lib/tmpfiles.d/systemd‑nologin.conf:F! /run/nologin 0644 ‑ ‑ ‑ "System
is
>> booting up. See pam_nologin(8)"
>>
>> Which effectively locks out users when doing so.
> 
> You can invoke the binary from shell prompt:
> 
>    systemd‑tmpfiles ‑‑create ‑‑clean ‑‑remove
> 
> If you don't specify ‑‑boot then lines like the /run/nologin one won't
> be honoured.

OK, my solution was to "rm /run/nologin".

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel