Univention Bugzilla – Bug 27577
Rechner-Passwortwechsel sollte überarbeitet werden
Last modified: 2012-07-20 15:25:21 CEST
Wie an Ticket Ticket#2012060621001237 berichtet, könnte der Mechanismus zum Wechseln der Rechner Passwörter robuster sein. Der Vorgang sollte überarbeitet werden.
Es wurde hier angemerkt, dass z.B. die Rückgabewert der Skripte geprüft werden könnten, ausserdem steigt der Mechanismus aus, wenn der UDM CLI Aufruf länger als 10 Sek. braucht. Bzgl. nicht neugestarteten BIND besteht Bug 27517
Ok, ich schau mir das script server_password_change im Quellpaket univention-server mal an. Das grundsätzliche Konzept (wie in /usr/lib/univention-server/server_password_change.d/README.API beschrieben) möchte ich erst mal lassen wie es ist, aber durch mehr Abfragen von return values sollte der Vorgang robuster werden.
Nach gründlicher Prüfung aller scripts werde ich nur in server_password_change zusätzliche Fehlerabfragen einbauen. Die scripts 50univention-mail-server, univention-bind und univention-nscd sehen völlig in Ordnung aus. Da war wirklich nur der schwere Bug #27517, der wohl heftige Folgefehler verursachte. Im script server_password_change werde ich einige zusätzliche Abfragen auf return codes machen und danach einen sauberen rollback auslösen. Wichtig ist dabei vor allem: - ganz am Anfang (wenn rollback noch möglich ist) alle Fehler zu erkennen - ganz am Ende (wenn kein rollback mehr möglich ist) sicherzustellen, dass sämtliche scripts durchlaufen, auch wenn dabei eine einzelne Aktion fehlgeschlagen ist - alle fehlgeschlagenen Aktionen im log auftauchen Nach Rücksprache mit Tobias werde ich noch mal prüfen - ob die 10 Sekunden timeout für UDM CLI (Dauer ist leider fest eingebrannt im Quellkode) doch hochgesetzt werden können (entweder im Quellkode oder per UCR Variable). - ob die CPU-Last oder die I/O-Last den UDM CLI so langsam machen, dass ein timeout auftritt - alles Testen mit einem LDAP backend (univention-bind script) gemacht wird, weil diese Anordnung den Fehler beim Kunden hervorgerufen hat
Neben den o.g. Änderungen habe ich noch zusätzliche Abfragen eingebaut: - wenn LDAP nicht abfragbar, dann kein Passwort ändern - wenn nachgeordnete skripts gestartet werden, dann immer ALLE - wenn Passwort mit UDM geändert, dann wird überprüft, ob univention-ldapsearch damit funktioniert - diese Prüfung wird im Sekundentakt bis zu 10 mal wiederholt Sobald also ein Fehler gefunden wird, beendet sich das script und lässt den Rechner in einem kleinstmöglich geänderten Zustand zurück, um spätere manuelle Eingriffe zu erleichtern. All das habe ich etliche Male auf einer VM getestet.
(In reply to comment #4) > Neben den o.g. Änderungen habe ich noch zusätzliche Abfragen eingebaut: > - wenn Passwort mit UDM geändert, dann wird überprüft, ob > univention-ldapsearch damit funktioniert > - diese Prüfung wird im Sekundentakt bis zu 10 mal wiederholt > > Sobald also ein Fehler gefunden wird, beendet sich das script und lässt den > Rechner in einem kleinstmöglich geänderten Zustand zurück, um spätere manuelle > Eingriffe zu erleichtern. All das habe ich etliche Male auf einer VM getestet. Das Skript sollte prüfen, ob die Änderung des Maschinenpassworts auf dem Master erfolgreich war (ldapsearch mit Maschinenkonto gegen den Master). Ist die Änderung auf dem Master fehlgeschlagen, sollte das Skript ohne Änderung der machine.secret abbrechen (aber die Skripte mit "nochange" noch ausführen). War die Änderung auf dem Master erfolgreich, sollte einige Zeit auf die Replikation des Passworts gewartet werden. Nach Ablauf der Wartezeit sollte das Passwort sowohl in das lokale LDAP und als auch in die machine.secret geschrieben werden. Achtung: das Skript muss auch auf dem Master selbst funktionieren! Dort sind "LDAP auf Master" und "lokales LDAP" identisch.
Stimmt, ich hab es so geändert wie von Sönke vorgeschlagen. Nach der Änderung des Passworts mit UDM wird nun also erst auf LDAP master nachgeschaut, ob die Änderung erfolgreich war und danach noch mal dass gleich auf dem lokalen LDAP. Es wird in beiden Fällen 30 Sekunden lang im Sekundentakt der Test wiederholt. Falls einer der beiden fehlschlägt, gibt es einen kompletten rollback. Im changelog des Handbuchs habe ich eine Eintragung gemacht. Bei den Tests habe ich die verschiedenen Varianten an Fehlschlägen durchprobiert. In jedem einzelnen Fall (egal ob Passwort erfolgreich geändert oder nicht) war der server anschließend in einem arbeitsfähigem Zustand mit konsistentem Passwort in /etc/machine.secret und im LDAP. Auch die log-Meldungen waren genau wie erwartet.
Verified: - Code Review → OK - Changelog → OK - PWD von unterschiedlichen Systemen ändern (Master, Backup, Slave, Member) → OK - In allen Fällen einmal die ACLs so ändern, dass es nicht geht → OK: das alte Passwort wird wieder aktiviert - Replikation deaktivieren → OK: auf Slave und Backup wird das alte Passwort wieder aktiviert - Werden Mails verschickt? → OK: nur im Fehlerfall
Auf einem UCS3.0-1 errata91 Slave fiel nach update auf interim-2 auf, dass server_password_change die Passwortänderung immer wieder zurückgenommen hat. Das Skript stellte fest, dass das Passwort zwar auf dem Master korrekt geändert worden war, aber es lokal nicht ankam. Ursache scheint zu sein, dass der Listener weiterhin versucht mit dem alten /etc/machine.secret einen LDAP-Bind zum Master vorzunehmen, dabei scheitert und daher das aktualisierte Passwort nicht in das lokale LDAP synchronisieren kann. Vorschlag wäre, nach Feststellung der erolgreichen Passwortänderung auf dem Master und vor dem Test der erfolgreichen Replikation das neue Passwort nach /etc/machine.secret zu schreiben, den listener neu zu starten und erst dann den Lesetest gegen das lokale LDAP zu starten. Wenn dieser dann doch fehlschlägt, muss dann zusätzlich /etc/machine.secret wieder auf das alte Passowrt zurückgesetzt werden.
Stimmt, da musste noch was geändert werden. Ich hab das script jetzt so geändert, dass das /etc/machine.secret.old nun schon einen Schritt früher geändert wird, damit der Listener eine Chance bekommt, die Replikation schon mit dem neuen Passwort durchzuführen. Nachdem meine Test-Umgebung ordentlich gejoint war, hat dann /usr/lib/univention-server/server_password_change auch auf master und backup ordentlich funktioniert. Auch bei simuliertem Ausfall der LDAP-Verbindung erkannte das script die Situation und hinterließ einen server mit konsistentem Passwort, auf dem anschließend auch weiter Aufrufe des script laufen konnten. Diese Lösung sollten nun auf servern mit allen bekannten Rollen funktionieren.
(In reply to comment #9) > Stimmt, da musste noch was geändert werden. Ich hab das script jetzt so > geändert, dass das /etc/machine.secret.old nun schon einen Schritt früher > geändert wird, damit der Listener eine Chance bekommt, die Replikation schon > mit dem neuen Passwort durchzuführen. Nachdem meine Test-Umgebung ordentlich > gejoint war, hat dann /usr/lib/univention-server/server_password_change auch > auf master und backup ordentlich funktioniert. Auch bei simuliertem Ausfall der > LDAP-Verbindung erkannte das script die Situation und hinterließ einen server > mit konsistentem Passwort, auf dem anschließend auch weiter Aufrufe des script > laufen konnten. > > Diese Lösung sollten nun auf servern mit allen bekannten Rollen funktionieren. Es fehlt jetzt noch der Restart des Listeners, nachdem das neue Passwort im LDAP des Masters gesetzt wurde.
Nach dem Wechsel des machine.secret von old nach new (bzw. beim rollback) wird nun der listener neu gestartet. Der Timeout für die ldap-Tests (gegen Master und lokale) wurde auf 60s erhöht.
OK, damit funktioniert es.
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".