wir möchten einen Drucker über drei UCS-Servern, jeweils 2.4-3, verfügbar machen.
server1: master
server2: slave
server3: backup
Trägt man den Drucker über den UDM des Masters für alle drei Server ein, so wird dieser nur auf dem slave und auf dem backup verfügbar gemacht. Aber nicht auf dem master.
Der Eintrag taucht in allen lokalen LDAP-Servern auf. Auf slave und backup tauchen auch die entsprechenden Listener-Einträge auf und die /etc/cups/printers.conf wurde auch korrekt angepasst. Funktioniert also.
Nur auf dem Master wird die /etc/cups/printers.conf nicht angepasst. Auch bei höherem debug-level steht nichts im listener-log.
Wie kriegen wir den Drucker noch auf dem Master verfügbar?
normalerweise müsste eine entsprechende Meldung in der listener.log und der syslog erscheinen, sofern univention-lpadmin den Drucker nicht korrekt anlegen konnte.
Zusätzlich müsste in diesem Fall ein Skript unterhalb von “/var/cache/univention-printserver” erstellt worden sein.
Wurde das Paket “univention-printserver” korrekt auf dem Master installiert? Sollten sich keine Hinweise in der listener.log, sowie keine entsprechenden Skripte unterhalb von “/var/cache/univention-printserver” (auf dem Master) finden lassen, wäre es denkbar, dass der Listener auf dem Master nicht korrekt läuft.
Um dies zu überprüfen können Sie die Notifier-ID sowie die Transaction-ID des Masters vergleichen:
tail -1 /var/lib/univention-ldap/notify/transaction
cat /var/lib/univention-directory-listener/notifier_id
Beide Werte müssten gleich sein.
Zusätzlich wäre die Ausgabe von ldapsearch auf das Druckerobjekt sowie die Ausgabe der Befehle:
was sind aktuell die letzten Meldungen in der listener.log auf dem Master?
Könnten Sie einmal verifizieren, dass der Listener aktuell noch läuft? Sollte dem so sein, können Sie den Listener mittels /etc/init.d/univention-directory-listener stop beenden.
Sie sollten im Anschluss verifizieren, dass der Dienst auch tatsächlich gestoppt wurde. Andernfalls müsste das Verhalten weiter untersucht werden.
Hierzu könnten Sie uns die Ausgabe der Befehle:
strace -ttT -f -p LISTENER-PID
und
ps aux
zukommen lassen.
Die Ausgaben sollten Sie je in eine Datei umleiten und uns diese per feedback@univention.de zukommen lassen. Danach können Sie den laufenden Listener-Prozess mit kill stoppen.
Im Anschluss sollten Sie das Debug-Level auf 4 stellen und den Listener über das Initksript wieder starten:
ucr set listener/debug/level=4
/etc/init.d/univention-directory-listener start
Sollte die Syncronisation weiterhin nicht funktionieren, so können Sie uns gern die listener.log über feedback@univention.de zur Verfügung stellen.
Der Listener lässt sich mit /etc/init.d/univention-directory-listener stop korrekt beenden, er taucht bei einem
ps aux
nicht mehr auf.
Auch nachdem der Debug-Level des Listeners auf 4 gestellt und dieser wieder gestartet wird, taucht bei einer Änderung der Druckerkonfiguration nichts im listener.log auf.
Sollten Sie dennoch den listener.log benötigen, obwohl nichts auftaucht, werden wir diesen so schnell wie möglich nachliefern.
um hier schneller zu einer Lösung finden zu können, wäre es hilfreich, wenn Sie uns ein nach SDB-Artikel 1174 auf dem Master erstelltes Univention-Support-Archiv zukommen lassen würden.
Auf diesem Weg stünden uns direkt weitere evt. relevante Informationen zur Verfügung.
Es werden in der Folge dann die 140MB Dateien “supportarchiv00”, “supportarchiv01” und “supportarchiv02” erstellt, welche Sie uns gern zukommen lassen können.
Ein möglicher Workaround besteht darin, den Notifier sowie den Listener auf dem DC-Master anzuhalten, die Transaktionen in der transaction-Datei ("/var/lib/univention-ldap/notify/transaction") neu zu Nummerieren (beginnend bei 1) und die Notifier-ID (in der Datei “/var/lib/univention-directory-listener/notifier_id”) auf “1” zurück zu setzen.
Anschließend können Notifier und Listener wieder gestartet und alleangeschlossenen Systeme neu gejoint werden.
Bitte beachten Sie dass hierbei für alle bereits im LDAP vorgenommenen Änderungen zu zuständigen Listener-Module noch einmal ausgeführt werden, der Prozess kann daher einige Zeit in Anspruch nehmen und ggf. auch höhere Last auf dem System erzeugen. Diesen Workaround haben wir hier außerdem nicht getestet, weshalb Sie diesen Weg vorab gründlich in einer Testumgebung überprüfen sollten.
Eine nähere Analyse der Umstände die zu diesen Problemen geführt haben, sowie die Ausarbeitung eines entsprechend konkreten Lösungsweges für Ihre Umgebung, kann nicht im Rahmen der kostenlosen Unterstützung hier im Forum erfolgen. Sollte der dargebotene Workaround so für Sie nicht ausreichend sein, würde ich Sie daher bitten, sich diesbezüglich mit unserem Vertrieb (Telefonisch über +49 421 2223220 oder per Mail: vertrieb@univention.de) in Verbindung zu setzen, dieser wird Ihnen die Möglichkeiten und Angebote für eine weitere Unterstützung gerne erläutern.
Weiterhin ist aufgefallen, dass Logrotate scheinbar aktuell nicht korrekt funktioniert - aufgefallen ist dies an der Datei “/var/log/syslog_1”, welche scheinbar seit dem Februar 2011 logged und nunmehr 2GB groß ist. Dies sollten Sie darüberhinaus einmal überprüfen um einer vollgelaufenen Systempartition vorzubeugen.
