crond · YP · Tut nicht...
Diesen Beitrag schrieb ich 15 Jahre und 10 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
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… Derweil ist das Logfile 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 folgendermaßen:
$ /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 ausschließlich 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:::
Was man per Google so findet ist der Tipp: 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…
Und jetzt die Fußnote: 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!