Vorgeschichte: die User authentifizieren sich über NIS (Version 2.12). Der gesamte Bestand wurde erfolgreich vom ursprünglichen (SUSE-9.2) auf einen neuen (Debian-4.0) Rechner gezogen (NIS Version 2.19) — die User können sich weiterhin einloggen, können weiterhin arbeiten wie gehabt. Jedoch funktionieren auf den Fedora-Maschinen (!) keinerlei Cron-Jobs mehr…
Das Logfile ist mit diesen Meldungen hier gespickt:
Dec 10 10:45:01 rechner crond[23968]: CRON (dau) ERROR: failed to open PAM security session: Success Dec 10 10:45:01 rechner crond[23968]: CRON (dau) ERROR: cannot set security context Dec 10 10:45:01 rechner crond[23969]: Authentication service cannot retrieve authentication info |
Entgegen allem, was man per Google so findet, passiert das auch auf einer Maschine, auf der SELinux nicht aktiviert ist. Prüfen lässt sich das übrigens folgendermassen:
$ /usr/sbin/getenforce Disabled |
Und die /etc/nsswitch.conf ist ebenfalls korrekt (die User können sich ja einloggen):
passwd: files nis compat shadow: files nis compat group: files nis compat |
Auch die Schaltung von PAM in den Debug-Modus bringt keine Erleuchtung:
auth.log:Dec 9 11:34:01 www crond[10964]: pam_unix(crond:account): could not identify user (from getpwnam(dau)) auth.log:Dec 9 11:34:01 www crond[10965]: pam_unix(crond:account): could not identify user (from getpwnam(dau)) |
Unzweifelhaft ist jedoch, dass es ausschliesslich die NIS-User betrifft — die Cron-Jobs der lokalen User laufen nach wie vor fehlerfrei. Die Fehlermeldung kann unter anderem auch dann auftreten, wenn für den User der entsprechende Eintrag in der shadow fehlt oder er nicht zugreifbar ist… Gewissheit bringt hier
$ ypcat shadow.byname | grep dau dau:$1$Oiiblafaselblafas.ely4t3GSbtmF/:14222:0:99999:7::: |
(Beachtet hierzu bitte die Fussnote!)
Was man per Google so findet ist der Tip: NIS platt machen und komplett neu aufsetzen. Die User danken einem sowas und die Chefs sowieso! Geht aber auch einfacher, schaut euch mal die /etc/pam.d/crond eures Fedora-Systems an:
auth sufficient pam_rootok.so debug auth required pam_env.so debug auth include system-auth debug account required pam_access.so debug account required pam_permit.so debug account include system-auth debug session required pam_loginuid.so debug session include system-auth debug |
Nun bewegt die Datei mal da weg (mv /etc/pam.d/cond /etc/pam.d/crond.WEG) und legt eine neue /etc/pam.d/crond an mit folgendem Inhalt (geklaut von einem Debian-System, auf dem der Quatsch reibungslos funktioniert):
account required pam_unix.so auth required pam_unix.so nullok auth required pam_env.so session required pam_unix.so |
Wenn ihr es debuggen wollt, setzt das Keyword debug an jedes Zeilenende. Aha — urplötzlich tut crond wieder, was er soll! Und das ganz ohne plattmachen und User verärgern…
Fussnote Auch den httpd kann man darauf trimmen, User-Authentifizierung per pam_unix.so zuzulassen; eine entsprechende /etc/pam.d/httpd kann in etwa so aussehen:
auth required pam_unix.so account required pam_unix.so |
Wenn das dann dennoch nicht funktioniert und der NIS-Server immer wieder sowas hier vermeldet…
Dec 9 17:17:36 ypservhost ypserv[11784]: refused connect from 192.168.1.1:51815 to procedure ypproc_match ($NISDOMAIN,shadow.byname;-1) |
… dann schaut mal, ob in der /etc/ypserv.conf die folgende Zeile ein- oder auskommentiert ist:
* : * : shadow.byname : port |
Ist die Anweisung aktiv (sprich: keine Raute am Zeilenanfang), so wird der Zugriff auf shadow.byname gesperrt; in dem Falle bekommt ihr bei der ypcat shadow.byname-Anfrage auch keine Antwort. Zeile auskommentieren und Dienst durchstarten schafft hier Abhilfe, aber seid euch im Klaren, was das für die Sicherheit des Systems gegebenenfalls bedeuten kann!
0