Es gibt meiner Meinung nach in der Doku oder im Filesystem beim CUPS einen Fehler. Die Doku https://docs.software-univention.de/handbuch-4.3.html#print::ppdlisten sagt:
Der Pfad zur PPD-Datei, relativ zu dem Verzeichnis /usr/share/ppd/. Soll beispielweise die Datei /usr/share/ppd/laserjet.ppd verwendet werden, so ist hier laserjet.ppd einzutragen.
Von den erzeugten Scripts in /var/cache/univention-printserver wird “univention-lpadmin” aufgerufen welches seinerseits wieder “lpadmin” aufruft. “lpadmin” schaut nach /usr/share/cups/model um PPDs zu finden. Im Verzeichnis /usr/share/cups/model existier ein Symlink der ppd heisst und auf /usr/share/ppd zeigt. Macht man die LDAP-Einträge so, wie in der Doku beschrieben, dann werden die PPDs nicht gefunden. Damit es funktioniert gibt es zwei Lösungsmöglichkeiten:
- Dem Pfad im LDAP ppd/ voranstellen.
- Den Symlinkt ändern, so dass das ppd verschwindet.
Jetzt kann man sich aussuchen, ob die Doku oder der Symlink falsch ist.
Beim Restart des “cupsd” ergibt sich noch ein Timing-Problem. Der “cupsd” ist nicht schnell genug da und die Scripte für das Anlegen der Drucker werden zu bald ausgeführt, was dazu führt, dass die ersten einen Timeout bekommen können. Ein “sleep 2” an geeigneter Stelle in der /etc/init.d/cupsd schafft Abhilfe.
Ausserdem fällt auf, dass wenn man im LDAP Änderungen an Druckern vornimmt, dass die Drucker dann immer im CUPS neu angelegt werden. Das hat den unangenehmen Nebeneffekt, dass alle Standardeinstellungen die man dort im Treiber gemacht hat verloren gehen. Eine gute Lösung für das Problem fällt mir spontan auch nicht ein …
Huhu,
zum Pfad kann ich nur sagen, dass es so wie im Handbuch beschrieben bei mir durchaus funktioniert. Ich habe PPDs in /usr/share/ppd/custom, z.B. /usr/share/ppd/custom/Ricoh-MP_C3004-pxlcolor-Ricoh.ppd, und im LDAP ist in der Druckertreiberliste Ricoh dann custom/Ricoh-MP_C3004-pxlcolor-Ricoh.ppd eingetragen (alle Werte eben copy-pasted).
Ein Vergleich der Checksummen von /etc/cups/ppd/<druckername>.ppd und /usr/share/ppd/custom/Ricoh-MP_C3004-pxlcolor-Ricoh.ppd zeigt, dass sie identisch sind.
Ich tippe daher auf einen Tippfehler irgendwo bei Ihnen.
Zu dem Timing-Problem kann ich nichts sagen. Ein sleep … ist aber nie die richtige Lösung, weil komplett der Wert komplett beliebig ist und in manchen Fällen dann eben auch wieder nicht ausreichen würde. Hier wäre es sinnvoll, wenn Sie einen Bug dafür einstellen würden. Andernfalls gerät der Hinweis hier im Forum schlicht in Vergessenheit.
m.
Huhu,
ich kann das inzwischen nachstellen. Änderungen am bestehenden Drucker führen zur folgenden Fehlermeldung in /var/log/univention/listener.log:
07.11.18 09:20:12.583 LISTENER ( PROCESS ) : updating 'cn=aurora,cn=printers,dc=bs,dc=linet-services,dc=de' command m
07.11.18 09:20:12.627 LISTENER ( WARN ) : cups-printers: info: univention-lpadmin -u allow:all -o auth-info-required=none -p aurora -m foomatic-rip/Apple-ImageWriter-iwhi.ppd -v socket://aurora.bs.linet-services.de:9100 -E
lpadmin: Unable to copy PPD file.
The command "/usr/sbin/lpadmin -u allow:all -o auth-info-required=none -p aurora -m foomatic-rip/Apple-ImageWriter-iwhi.ppd -v socket://aurora.bs.linet-services.de:9100 -E -h localhost" returned 1
07.11.18 09:20:12.972 LISTENER ( ERROR ) : cups-printers: Failed to execute the univention-lpadmin command. Please check the cups state.
Die PPD in /etc/cups/ppds/aurora.ppd wurde in der Tat nicht ausgetauscht, sondern ist noch die vorherige. Das neue Druckermodell, das ich ausgewählt hatte, war übrigens kein manuell angelegtes, sondern eines von Univention mitgeliefertes — und bei all den von Univention selber angelegten ist ebenfalls nur der relative Pfad ab /usr/share/ppds eingetragen, z.B. foomatic-rip/Apple-ImageWriter-iwhi.ppd.
Jetzt weiß ich allerdings nicht, warum der Drucker initial richtig angelegt wurde. Ich hatte die PPD definitiv nicht manuell nach /etc/cups/ppds/ kopiert. Evtl. ist das irgendwann mit einem Update kaputt gegangen.
Wenn ich neue Symlinks zu allen Unterverzeichnissen in /usr/share/ppd anlege (sudo ln -s /usr/share/ppd/* /usr/share/cups/model/), so klappt’s auch mit dem anschließenden Modifizieren des Drucker-Eintrags im LDAP sowie via lpadmin.
Mir scheint, dass dieser Bug damit zu tun hat bzw. ein Symptom derselben unterliegenden Ursache ist.
Dieser Bug wiederum scheint zu suggerieren, dass /usr/share/cups/model selber schon ein Symlink nach /usr/share/ppd sein sollte. Das ergibt dann mit den relativen Dateinamen auch wieder Sinn.
Gruß
mosu
Nachtrag: ich hab entsprechende Informationen zu beiden Bugs hinzugefügt.
Weiterer Nachtrag: In einem meiner Testsysteme hingegen ist /usr/share/cups/model der erwartete Symlink nach /usr/share/ppd. Hmm, die Umstellung von Verzeichnis auf Symlink scheint also nur unter bestimmten Bedingungen fehlzuschlagen.