crond · YP · Tut nicht…

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 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:::

(Beachtet hierzu bitte die Fußnote!)

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…

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!