Package: nslcd
Version: 0.9.4-3
Severity: important
Dear Maintainer,
the behaviour reported for Wheezy in #766606 still persists with Jessie. I see
it now on a fresh install: k5start doesn't come up on boot. Issuing
/etc/init.d/nslcd restart after boot works perfectly.
Situation after boot:
root@frengel:~# systemctl status nslcd -l
● nslcd.service - LSB: LDAP connection daemon
Loaded: loaded (/etc/init.d/nslcd)
Active: active (running) since Mi 2015-05-27 21:51:15 CEST; 1min 16s ago
Process: 630 ExecStart=/etc/init.d/nslcd start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/nslcd.service
└─674 /usr/sbin/nslcd
Mai 27 21:51:39 frengel nslcd[674]: [b71efb] <group/member="administrator"> no available LDAP server found: Local error
Mai 27 21:51:39 frengel nslcd[674]: [b71efb] <group/member="administrator"> no available LDAP server found: Server is unavailable
Mai 27 21:51:42 frengel nslcd[674]: [e2a9e3] <group/member="administrator"> no available LDAP server found: Server is unavailable
Mai 27 21:51:42 frengel nslcd[674]: [e2a9e3] <group/member="administrator"> no available LDAP server found: Server is unavailable
Mai 27 21:51:42 frengel nslcd[674]: [45e146] <group/member="administrator"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Mai 27 21:51:42 frengel nslcd[674]: [45e146] <group/member="administrator"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Mai 27 21:51:47 frengel nslcd[674]: [5f007c] <group/member="root"> no available LDAP server found: Server is unavailable
Mai 27 21:51:47 frengel nslcd[674]: [5f007c] <group/member="root"> no available LDAP server found: Server is unavailable
Mai 27 21:51:47 frengel nslcd[674]: [d062c2] <group/member="root"> no available LDAP server found: Server is unavailable
Mai 27 21:51:47 frengel nslcd[674]: [d062c2] <group/member="root"> no available LDAP server found: Server is unavailable
Fortunately both users are local. Situation after restart of nslcd:
● nslcd.service - LSB: LDAP connection daemon
Loaded: loaded (/etc/init.d/nslcd)
Active: active (running) since Mi 2015-05-27 21:53:40 CEST; 8s ago
Process: 1118 ExecStop=/etc/init.d/nslcd stop (code=exited, status=0/SUCCESS)
Process: 1132 ExecStart=/etc/init.d/nslcd start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/nslcd.service
├─1140 /usr/bin/k5start -b -p /var/run/nslcd/k5start_nslcd.pid -o nslcd -g nslcd -m 600 -f /etc/krb5.keytab -K 60 -u [email protected] -k /var/run/nslcd/nslcd.tkt
└─1143 /usr/sbin/nslcd
Mai 27 21:53:40 frengel nslcd[1132]: Starting Keep alive Kerberos ticket: k5start.
Mai 27 21:53:40 frengel nslcd[1143]: version 0.9.4 starting
Mai 27 21:53:40 frengel nslcd[1143]: accepting connections
Mai 27 21:53:40 frengel nslcd[1132]: Starting LDAP connection daemon: nslcd.
This is in the logs about k5start:
root@frengel:~# grep k5start /var/log/syslog
May 27 21:51:15 frengel nslcd[630]: Starting Keep alive Kerberos ticket: k5startk5start: error getting credentials: Cannot contact any KDC for realm 'AD.MICROSULT.DE'
May 27 21:53:40 frengel nslcd[1118]: Stopping Keep alive Kerberos ticket: k5startNo process in pidfile '/var/run/nslcd/k5start_nslcd.pid' found running; none killed.
May 27 21:53:40 frengel nslcd[1132]: Starting Keep alive Kerberos ticket: k5start.
It smells like the resolver is not up when k5start tries to figure out the KDC.
The system is configured by DHCP.
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nslcd depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.56
ii libc6 2.19-18
ii libgssapi-krb5-2 1.12.1+dfsg-19
ii libldap-2.4-2 2.4.40+dfsg-1
Versions of packages nslcd recommends:
ii bind9-host [host] 1:9.9.5.dfsg-9
ii host 1:9.9.5.dfsg-9
ii ldap-utils 2.4.40+dfsg-1
ii libnss-ldapd [libnss-ldap] 0.9.4-3
ii libpam-krb5 4.6-3+b1
ii libpam-ldapd [libpam-ldap] 0.9.4-3
pn nscd <none>
ii nslcd-utils 0.9.4-3
Versions of packages nslcd suggests:
ii kstart 4.1-3
-- Configuration Files:
/etc/default/nslcd changed:
K5START_PRINCIPAL="FRENGEL\[email protected]"
-- debconf information:
nslcd/ldap-bindpw: (password omitted)
nslcd/ldap-cacertfile: /etc/ssl/certs/ca-certificates.crt
nslcd/ldap-sasl-authzid:
nslcd/ldap-reqcert:
libraries/restart-without-asking: false
nslcd/ldap-sasl-authcid:
nslcd/ldap-binddn:
nslcd/ldap-sasl-secprops:
nslcd/restart-services:
nslcd/ldap-auth-type: none
* nslcd/ldap-uris: ldap://ad.microsult.de
nslcd/ldap-sasl-realm:
nslcd/xdm-needs-restart:
nslcd/ldap-starttls: false
nslcd/disable-screensaver:
nslcd/ldap-sasl-mech:
nslcd/restart-failed:
* nslcd/ldap-base: DC=ad,DC=microsult,DC=de
nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
I tried to mitigate the bug by adding the following to /etc/rc.local:
if [ ! -f /var/run/nslcd/nslcd.tkt ]; then
systemctl restart nslcd
systemctl restart kdm
fi
When I run this script as root after log in everything runs fine. I get
a valid ticket nslcd:nslcd 600 /var/run/nslcd/nslcd.tkt.
The boot up sequence however produces a total of two files called
/var/run/nslcd/nslcd.tkt_######, with the hashes representing some
random characters. These files are empty, root:root 600. If I omit the
rc. local entry I just get one of these. Of course none without the
random extension.
I suspected a permission issue. But changing /etc/krb5.keytab to 644
didn't change the situation. /etc/krb5.conf ist 644 anyway.
With the script shown it regularly happens that 2 instances of nslcd are
running, but of course no k5start. Shouldn't restart terminate the prior
instance?
I now use a stop, killall nslcd, start sequence. Again it works fine
when started by root immediately after boot, but it fails if run from
systemd.
It also fails if run from cron with @reboot.
Last time I got a different error message: Jun 03 00:08:54 frengel
nslcd[762]: GSSAPI Error: Unspecified GSS failure. Minor code may
provide more information (No Kerberos credentials available)
Still poking at the mist,
- lars.
Acknowledgement sent
to Youssef Eldakar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Arthur de Jong <[email protected]>.
(Mon, 01 Feb 2016 14:33:13 GMT) (full text, mbox, link).
I am experiencing the same issue.
I thought that implementing the init as systemd units could be the
solution. I attempted the following, but nslcd-kstart.service so far fails
to start during the boot process, starts successfully when invoked manually
after the system is up:
# nslcd-kstart.service
[Unit]
Description=Keep alive Kerberos ticket for nslcd
After=network.target auditd.service systemd-resolved.service
[Service]
#EnvironmentFile=-/etc/default/nslcd-kstart
ExecStart=/usr/bin/k5start -b -p /var/run/nslcd/nslcd-kstart.pid -f
/etc/libnss-ldap.keytab -u nssldap -o nslcd -g nslcd -m 600 -k
/tmp/.nssldapcc -K 60
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=nslcd-kstart.service
---
# nslcd.service
[Unit]
Description=LDAP connection daemon
After=network.target auditd.service nslcd-kstart.service
[Service]
#EnvironmentFile=-/etc/default/nslcd
ExecStart=/usr/sbin/nslcd
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=nslcd.service
---
I have no previous experience writing systemd unit files, and so I could be
doing something wrong. Any suggestions would be appreciated.
Youssef Eldakar
Bibliotheca Alexandrina
Acknowledgement sent
to Youssef Eldakar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Arthur de Jong <[email protected]>.
(Mon, 01 Feb 2016 15:27:08 GMT) (full text, mbox, link).
It is silly, but if I add
RestartSec=2s
to both unit files, nslcd is successful during the boot process.
This does not feel like a real fix, however.
Youssef Eldakar
Bibliotheca Alexandrina
Acknowledgement sent
to Youssef Eldakar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Arthur de Jong <[email protected]>.
(Tue, 02 Feb 2016 14:57:04 GMT) (full text, mbox, link).
To check, I put KDC IP address in krb5.conf. Yet, the issue persisted,
suggesting this does not have to do with name resolution not being
available early on in the boot process.
Youssef Eldakar
Bibliotheca Alexandrina
Acknowledgement sent
to Youssef Eldakar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Arthur de Jong <[email protected]>.
(Thu, 03 Mar 2016 07:12:03 GMT) (full text, mbox, link).
This page on the systemd wiki sheds light on the issue:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
According to the page, ideally, the ticket refresh (k5start) should be
implemented such that it is able to react in a friendly way to network
changes. I take this as implying that nslcd should start without
depending on Kerberos ticket initialization and instead attempt to
obtain credentials on demand.
As temporary workaround, I installed the following in cron.d:
*/3 * * * * root if [ \( ! -e /var/run/nslcd/k5start_nslcd.pid -o ! -e
/var/run/nslcd/nslcd.pid \) -a -f /etc/libnss-ldap.keytab -a -r
/etc/libnss-ldap.keytab ]; then systemctl restart nslcd; fi
On Mon, Feb 1, 2016 at 5:25 PM, Youssef Eldakar
<[email protected]> wrote:
> It is silly, but if I add
>
> RestartSec=2s
>
> to both unit files, nslcd is successful during the boot process.
>
> This does not feel like a real fix, however.
>
> Youssef Eldakar
> Bibliotheca Alexandrina
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.