Server-password-change

UCS - Univention Corporate Server
#1

Guten Tag,

ist passiert alle drei Wochen auf einem UCS version/erratalevel: 39, version/patchlevel: 1, version/releasename: Horn-Lehe, version/version: 3.0 dass der bind Dienst beendet wird. In der messages Datei steht dieser Eintrag:

May 26 01:06:45 pdc server-password-change: stopping postfix due to upcoming server password change
May 26 01:06:47 pdc server-password-change: stopping bind9 due to upcoming server password change
May 26 01:07:00 pdc server-password-change: starting postfix after server password change

Postfix wird in diesem Fall auch beendet, aber wieder gestartet. Warum wird hier bind nicht gestartet?

lg

#2

Ich habe noch diesen Eintrag in der /var/log/univention/server_password_change.log gefunden:

Starting server password change (Mon May 21 01:03:18 CEST 2012)
Starting server password change (Tue May 22 01:05:53 CEST 2012)
Starting server password change (Wed May 23 01:07:47 CEST 2012)
Starting server password change (Thu May 24 01:08:36 CEST 2012)
Starting server password change (Fri May 25 01:08:09 CEST 2012)
Starting server password change (Sat May 26 01:06:43 CEST 2012)
run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server prechange
Create mail/postfix/stoppedbyserverpasswordchange
Stopping Postfix Mail Transport Agent: postfix.
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-bind prechange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd prechange
E: Can`t find running daemon after 10 Seconds. (No socketfile)
run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server nochange
Multifile: /etc/postfix/ldap.distlist
Multifile: /etc/postfix/ldap.groups
Multifile: /etc/postfix/ldap.canonicalsender
Multifile: /etc/postfix/ldap.sharedfolderlocal
Multifile: /etc/postfix/ldap.virtualwithcanonical
Multifile: /etc/postfix/ldap.sharedfolderremote
Multifile: /etc/postfix/ldap.virtual
Multifile: /etc/postfix/ldap.canonicalrecipient
Multifile: /etc/postfix/ldap.transport
Multifile: /etc/postfix/ldap.virtualdomains
Starting Postfix Mail Transport Agent: postfix.
Unsetting mail/postfix/stoppedbyserverpasswordchange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-bind nochange
run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd nochange
failed to change server password for cn=pdc,cn=dc,cn=computers,$ldap_base
Starting server password change (Sun May 27 01:02:45 CEST 2012)

#3

Habe mir nun das bind Skript “/usr/lib/univention-server/server_password_change.d/univention-bind” etwas angeschaut, hier fehlt eine nochange Definition, welche den bind wieder startet…

lG

#4

Hallo,

vielen Dank für diesen ausführlichen Bericht. Ich habe dazu einen Eintrag in unserem Bug Tracker erzeugt, damit dieses Verhalten verbessert wird.

Mit freundlichen Grüßen
Tobias Scherer

#5

Hallo,

das klärt aber nicht das Problem… Warum kann das Passwort nicht geändert werden??

lG

#6

Hallo,

um welche UCS Version und Systemrolle handelt es sich bei dem System? War zur Zeit des PW Wechsels der LDAP Server und DC Master verfügbar? Gibt es ggf. weitere Hinweise im listener.log?
Sie können den Passwortwechsel von Hand anstoßen um das Verhalten näher zu untersuchen. Dazu müsste temporär

ucr set server/password/interval=1

gesetzt werden und das Skipt unter

/usr/lib/univention-server/server_password_change

aufgerufen werden.

Mit freundlichen Grüßen
Tobias Scherer

#7

Hallo,

führe ich das Skript per Hand aus, so läuft es auch Fehlerfrei durch…

Konnte nun aber schonmal feststellen, was genau die Fehlermeldung “E: Can`t find running daemon after 10 Seconds. (No socketfile)” erzeugt…

Das Skript “/usr/lib/univention-server/server_password_change” ruft den udm Befehl auf, um das Kennwort zu ändern:

/usr/sbin/univention-directory-manager computers/domaincontroller_master modify --binddn cn=pdc,cn=dc,cn=computers,dc=xxx,dc=at --bindpwd uvim50BL --dn cn=pdc,cn=dc,cn=computers,dc=xxx,dc=at --set password=0aG0JB31

Dieser erzeugt nach 10 Sekunden wartezeit die Fehlermeldung…

/usr/sbin/univention-directory-manager: Zeile 83:

socket_dir='/tmp/admincli_%s/' % os.getuid() socket_filename='sock' socket_path=(socket_dir+socket_filename) ... ... timeout=10 stime=int(time.time()) while not os.path.exists('%s' % socket_path): time.sleep(0.1) if int(time.time()) > stime+timeout: print 'E: Can`t find running daemon after %s Seconds. (No socketfile)' % timeout sys.exit(1)

Nur warum wird dieser Fehler nur Abends erzeugt???

[quote]root@pdc:/tmp/admincli_0# ls -l
insgesamt 4
srw------- 1 root root 0 13. Jun 15:47 sock
-rw-r–r-- 1 root root 5 13. Jun 15:47 sock.run[/quote]

Wer erzeugt überhaupt diesen Socket?? Aus irgendeinem Grund kann dieser Abends (während die Sicherung läuft) nicht erstellt werden ?!?!

In den Statistiken kann ich erkennen, dass der Server während des Backups ziemlich ausgelastet ist… Eventuell ist hier der Timeout von 10 Sekunden zu niedrig gesetzt??

3.0.1 ist installiert, Domänencontroller Master handelt es sich…

// Edit:
Werde mich heute Abend am Server einloggen & während des Backups das Skript starten…

#8

Leider ist das server-password-change Skript heute total schief gelaufen :-(!!!

Sicherung startet beim Kunden um 21:00, habe nun das Skript per Hand angestoßen, der udm Befehl zum ändern des Server- Passwortes brauchte 3 Sekunden…
Am Wochenende werden auch noch zusätzlich die virtuellen Maschinen gesichert… Da kann das ändern vielleicht schonmal über 10 Sekunden benötigen…

Wäre es vielleicht möglich, das Timeout auf 30 Sekunden zu erhöhen…?

Und nun zum eigentlichen Problem, das Server Passwort ändern Skript ist heute Abend um 1:00 total schief gelaufen!!! Den halbe Vormittag funktionierte NICHTS mehr!
Grund: server-password-change Skript…

Dieses hat laut Log- Dateien das Passwort im udm zwar geändert, aber nicht in der /etc/machine.secret, somit ist beim Kunden die Produktion für STUNDEN gestanden!

Ich finde das server-password-change bei nährer Betrachtung etwas herzlog programmiert, ihr geht einfach davon aus, dass alle Befehle fehlerfrei funktionieren werden, überprüft aber nicht, ob diese tatsächlich fehlerfrei funktioniert haben!
Man bedenke, dass es sich hierbei um ein Skript handelt, wenn hier ein Fehler auftritt, der komplette Server, somit auch der komplette Betrieb steht!

1.) Ihr schreibt einfach das neue Passwort in die machine.secret, überprüft aber nicht, ob dieses auch tatsächlich geschrieben wurde (Sicherung, zuviele io, könnte kernel fehler produzieren?!..). Hier würde ein einfaches cat reichen, um zu sehen, ob es tatsächlich geschrieben wurde… Oder auch den return status des letzten Befehls überprüfen??!
Man sollte immer davon ausgehen, dass unter bestimmten Situationen jeder Befehl schief gehen kann…!

2.) Nach ändern des Passworts wird kein authentifizieren mit dem neuen Passwort getestet! Man sollte testen, ob ein auth mit dem neuen Passwort möglich ist, falls nicht, eventuell auf ältere Passwörter zurückspringen, bis der auth funktioniert!!!

3.) Habe ich zwar schon gemeldet, aber wenn das Passwort ändern fehlschlägt & nochange ausgeführt wird, wird der bind Dienst NICHT gestartet!!! Warum wurde dieser übersehen?? Eine der wichtigesten Komponenten!!!

Wurde das Skript auf bestimmte Fehlersituationen bei euch getestet?? Warum können dann solche Fehler auftreten?

Habe das Skript zum ändern des Passwortes beim Kunden vorerst deaktiviert…

lG

#9

Hallo,

vielen Dank für diesen ausführlichen Bericht. Wir werden den Vorgang des Passwortwechsels für Rechnerkonten überarbeiten.

Mit freundlichen Grüßen
Tobias Scherer

#10

Hallo,

freut mich, dass das Passwortwechsel von Rechnerkonten überarbeitet wird…

Ich finde einfach schade, dass solches erst passiert, nachdem ein Kunde sauer auf euer Produkt ist, und nicht schon während der Entwicklung über solche Dinge nachgedacht wurde…

Ich meine, es muss doch während der Testphase schon auffallen, dass bei der nochange- Phase der bind nicht mehr gestartet wird?!

#11

Da scheinen in der Tat unsere Tests versagt zu haben. Wir werden das umgehend untersuchen und beheben.

Vielen Dank für das umfangreiche Feedback und die Analyse!

Viele Grüße
Stefan Gohmann

Mastodon