seit heute morgen haben wir keinen Zugriff mehr auf die E-Mails. Die Anmeldung schlägt fehl. In der Nacht scheint das Skript für den server_password_change gelaufen zu sein. Im Log steht ständig folgende Fehlermeldung: ldap_bind: Invalid credentials (49)
Ein univention-ldapsearch -x bringt den gleichen Fehler.
Ein ldapsearch -x funktioniert aber. In der Datei /etc/ldap.secret steht das richtige Passwort drin.
Ein manuelles ausführen des server_password_change ergibt folgende Meldung:
/usr/lib/univention-server/server_password_change
failed to contact LDAP server: cannot connect with univention-ldapsearch
Die Umgebung:
Univention Master 3.1.1 security-patchlevel: 6, erratalevel: 165
Es wäre toll, wenn wir schnell Hilfe bekommen!
Danke!
als schnellen Workaround können Sie für das Rechnerkonto in der UMC das Passwort setzen welches aktuell auf dem System in der Datei /etc/machine.secret steht. Die Verbindung sollte dann direkt wieder nöglich sein.
ein generelles Problem mit dem Server Password Change ist uns nicht bekannt, weshalb wir nicht dazu raten die Rotation komplett zu deaktivieren. In den Fällen in denen der Mechanismus nicht funktioniert ist dies meist ein Indiz für andere Probleme in der Umgebung.
Im konkreten Fall deutet die Logdatei darauf hin dass der Server Password Change Prozess zwei mal parallel läuft, auch die Scripte unter “server_password_change.d” werden mehrfach im “prechange”-Modus ausgeführt.Starting server password change (Mon Sep 9 01:03:41 CEST 2013)
Proceeding with regular server password change scheduled for today
...
Starting server password change (Mon Sep 9 01:03:51 CEST 2013)
Proceeding with regular server password change scheduled for today
Wenn es sich hierbei nicht um einen copy & paste Fehler handelt sollten Sie ggf. prüfen ob /usr/lib/univention-server/server_password_change, z.B. per Cron, mehrfach gestartet wird (entsprechende Hinweise sollten sich auch in der syslog finden). Normalerweise wird, wenn das neue Password nicht für die Authentifikation gegen den DC-Master verwendet werden kann, das alte Passwort weiter verwendet (“resetting old server password for …, because access to local LDAP did not work with the new password”). Alle alten Passwörter sind auf dem System in der Datei /etc/machine.secret.old zu finden.
Ferner sollten Sie ggf. prüfen warum Sie das Rechnerobjekt in der UMC nicht bearbeiten können, dies ist normalerweise problemlos möglich.
Ich weiß nicht ob das in dem Zusammenhang hilfreich ist und bin auch kein “Linux-Spezialist”:
Mir fehlte am Montag Morgen eine der regelmäßigen Emails von Bacula (Vollzugsmeldung über erfolgreiches Backup).
Bei der Suche nach der möglichen Ursache stellte sich in den Logs heraus, dass postfix anscheinend gestoppt war und kurz nach dem (erfolgreichen) Passwort Change wieder gestartet wurde.
Ein Grund warum postfix gestoppt war, habe ich nicht gefunden, nur der Start war in den Logs verzeichnet und zwar zeitlich unmittelbar nach dem Server Password Change.
Die Bacula Mail um 0:05 ist noch gekommen, die um 1:05 fehlt (Backup war aber erfolgreich), die um 2:05 ist wieder vorhanden.
Falls das der Sache dienlich ist, kann ich Logs zur Verfügung stellen.
(DC-Master, UCS 3.1-1 / Errata bis 180 / ist nicht Mail-Server konfigriert, es werden nur Status-Mails an den DC Backup/Zarafa gesendet)
Entschuldigung dass ich mich so lange nicht gemeldet habe. hier der Logfileauszug und cron
Sep 9 01:03:43 ucs2 postfix/master[2242]: terminating on signal 15
Sep 9 01:03:44 ucs2 server-password-change: stopping bind9 due to upcoming server password change
Sep 9 01:03:44 ucs2 named[1134]: shutting down
Sep 9 01:03:44 ucs2 named[1134]: stopping command channel on 127.0.0.1#953
Sep 9 01:03:44 ucs2 named[1134]: no longer listening on ::#53
Sep 9 01:03:44 ucs2 named[1134]: no longer listening on 127.0.0.1#53
Sep 9 01:03:44 ucs2 named[1134]: no longer listening on 10.10.10.2#53
Sep 9 01:03:44 ucs2 named[1132]: shutting down
Sep 9 01:03:44 ucs2 named[1132]: stopping command channel on 127.0.0.1#55555
Sep 9 01:03:44 ucs2 named[1132]: no longer listening on ::#7777
Sep 9 01:03:44 ucs2 named[1132]: no longer listening on 127.0.0.1#7777
Sep 9 01:03:44 ucs2 named[1132]: no longer listening on 172.16.10.2#7777
Sep 9 01:03:44 ucs2 named[1132]: exiting
Sep 9 01:03:44 ucs2 named[1134]: exiting
Sep 9 01:03:48 ucs2 postfix[12948]: fatal: the postfix command must not run as a set-uid process
Sep 9 01:03:56 ucs2 postfix[13113]: fatal: the postfix command must not run as a set-uid process
Sep 9 01:04:05 ucs2 server-password-change: starting postfix after server password change
Sep 9 01:04:06 ucs2 postfix/master[13240]: daemon started -- version 2.7.1, configuration /etc/postfix
@Meybohm
Da kein Zugriff mehr auf das LDAP möglich war, konnte auch die UMC nicht mehr ins Ldap schreiben. Der Befehl von DBGTMaster über Konsole funktionierte zum Glück noch.