Druckerfreigabe auf 3 UCS-Servern

german

#1

Hallo,

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?


#2

Hallo,

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:

ucr get hostname ucr get domainname
interessant.

Mit freundlichen Grüßen,
Tim Petersen


#3

Hallo,

offensichtlich hat es doch was mit dem Listener zu tun:

Transaction-ID: 8709
Notifier-ID: 15844

Hier das betreffende LDAP-Objekt (anonymisiert):

# lp1, printers, domain.de dn: cn=lp1,cn=printers,dc=domain,dc=de cn: lp1 univentionPrinterSambaName: lp1 objectClass: top objectClass: univentionPrinter univentionPrinterURI: lpd://176.16.1.150/lp univentionPrinterSpoolHost: backup.domain.de univentionPrinterSpoolHost: master.domain.de univentionPrinterSpoolHost: slave.domain.de univentionPrinterLocation: Testort11 univentionPrinterModel: None univentionPrinterQuotaSupport: 0 univentionPrinterACLtype: allow all

Die Einträge für Domain und Hostname sind auf allen drei Servern korrekt.

Viele Grüße
ckorn


#4

Hallo,

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.

Mit freundlichen Grüßen,
Tim Petersen


#5

Hallo Herr Petersen,

ich antworte stellvertretend für Herr Korn.

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.


#6

Hallo,

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.

Mit freundlichen Grüßen,
Tim Petersen


#7

Hallo Herr Petersen,

das Support-Bundle ist geschnürt, allerdings überschreitet es mit ca 380MB deutlich das Upload-Maximum auf upload.univention.de.

Ist es möglich das Archiv zu splitten und die einzelnen Teile so hochzuladen, dass Sie diese einander zuordnen können?


#8

Hallo,

sie können das Archiv beispielsweise mit dem Linux-Kommando “split” teilen. Die zu verwendene Syntax lautet:

split -d -b140m "Name des Ausgangsarchives" "Prefix der zu erstellenden Splitfiles"

Also beispielsweise:

split -d -b140m supportarchiv.tar.gz supportarchiv

Es werden in der Folge dann die 140MB Dateien “supportarchiv00”, “supportarchiv01” und “supportarchiv02” erstellt, welche Sie uns gern zukommen lassen können.

Mit freundlichen Grüßen,
Tim Petersen


#9

Hallo Herr Petersen,

vielen Dank für die kurze Anleitung. Folgende drei Archivnamen sind den Uploads zugeteilt worden:

upload_KklUc0.bin
upload_kKWvjH.bin
upload_ZQ2ez8.bin

Noch als kurze Info, die Ordner belegen nach dem entpacken 7,9 GB Speicherplatz.


#10

Hallo,

vermutlich ist das gleiche Problem bereits am Thema “Samba Shares werden nicht angelegt” behandelt worden:

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.

Mit freundlichen Grüßen,
Tim Petersen