Libreoffice 4.3.5, Opensuse 13.1, langsames Laden von Dateien bei nicht erreichbarem Printserver

Vor einiger Zeit klagten ein Kunde und ein Bekannter von mir darüber, dass sich Libreoffice [LO] beim Öffnen und erstmaligen Laden einer Datei sehr viel Zeit lasse. Wörtlich: Man kann sich erstmal einen Kaffe machen. Diese Meldungen trudelten bei uns sowohl für Windows- wie auch Linux-Systeme ein.

Ich konnte das zunächst nicht glauben; der Effekt ließ sich in unserem Netzwerk auf keinem PC oder Laptop (weder unter Opensuse 13.2 noch unter Opensuse 13.1) nachvollziehen.

Nun war ich vor kurzem ein paar Tage mit meinem Laptop (Opensuse 13.1 mit LO 4.5.3) unterwegs und musste selbst unter dem beschriebenen Problem leiden. Es dauerte einige Zeit, bis ich herausfand, was die Ursache war:

Ist

  • der Druck unter Linux oder Windows für einen Server konfiguriert
  • und wird für die Kommunikation zum Server z.B. das ipp-Protokoll eingesetzt
  • und ist irgendeine Netzwerkkarte aktiv, aber der aktuell eingestellte Druckerserver über das Netz nicht erreichbar,

so wartet Libreoffice zunächst minutenlang vergeblich auf Antworten von dem nicht zu findenden Drucker-Server, bevor es anfängt den Inhalt einer zu ladenden Datei zu rendern.

Ist dagegen ein Druckerserver oder ein lokaler Drucker erreichbar oder aber überhaupt kein Netzwerk aktiv, so öffnet LO die zu ladenden Dateien ohne Zeitverlust. In unserem Netz übernimmt ein permanent erreichbarer CUPS-Server die zentrale Ansteuerung verschiedener Druckerwarteschlangen; deshalb war das Problem auf Systemen innerhalb unseres Netzwerkes nicht nachvollziehbar.

Das Ganze ist natürlich für Libreoffice wenig werbewirksam. Liebe Libreoffice-Entwickler: Es soll tatsächlich Leute geben, die sich mit Ihrem Laptop zwischen verschiedenen Netzen daheim und am Arbeitsplatz bewegen - und manchmal ist halt keiner der eingestellten Drucker oder Druckerserver erreichbar, obwohl man z.B. an einem WLAN hängt. Dann sollte man nicht 3 bis 4 Minuten warten müssen, bevor eine simple Calc-Datei geladen wird.

Ein Workaround besteht bei Bedarf darin, die Druckereinstellungen (temporär) so umzustellen, dass erst gar nicht nach einem Netzwerkdrucker gesucht wird. Unter Linux ist das relativ einfach - unter Windows muss man sich durch die entsprechenden Punkte der Systemsteuerung quälen und die eingestellten Netzwerkdrucker entfernen. Das Dumme ist, dass man bei Rückkehr ins heimische Netz die Netzwerkdrucker wieder in den lokalen Druckeinstellungen aktivieren muss.

Ich denke, die Libreoffice-Entwickler haben hier wirklich etwas zu korrigieren. Es ist für Leute, die sich mit ihren Laptops evtl. täglich zwischen verschiedenen Arbeitsplätzen und Netzwerken hin und her bewegen müssen, nicht zumutbar, ihre Druckereinstellungen laufend anpassen zu müssen. Das Fehlen oder die Nichterreichbarkeit eines Druckerservers oder Druckers sollte nicht zum vollständigen Stopp des Datei-Ladens und -Renderns führen. Besser wäre hier ein Dialog, in dem der User über das Suchen nach dem Druckerserver informiert wird und ggf. diesen Schritt auch überspringen kann.

Hofen wir mal, dass das Problem mit einer der nächsten LO-Versionen wieder verschwindet.

Remote Druckerverwaltung

Einführung

Durch die diversen Distributionen - in meinem Fall durch Opensuse - ist man bzgl. der Drucker-Einrichtung ziemlich verwöhnt und greift gerne zu graphischen Verwaltungstools. Hat man aber einen laufenden CUPS-Druckerserver erst einmal aufgesetzt, so ist die Druckerverwaltung vom Arbeitsplatz-PC (!) aus über ein Terminal oftmals zeitsparender. Allerdings muss man dann einige nützliche Befehle aus dem CUPS-Umfeld parat haben. Wir stellen auf dieser Seite einige Kommandos aus der täglichen Praxis zusammen.

Aktivieren einer stehenden Druckerqueue auf einem CUPS-Server von einem Remote PC aus

Findet der CUPS-Server einen z.B. über USB angeschlossenen Drucker nicht beim Start, so wird dieser Drucker als "disabled" betrachtet, obwohl die Standard-) Queue für den Drucker noch Jobs entgegennimmt. Auch das Anschalten des Druckers hilft dann - je nach Systemkonfiguration - manchmal nicht. Das USB-Subsystem erkennt den Drucker zwar - CUPS bekommt davon aber ggf. nichts mit. Sitzt man nun an einem Remote-PC, so möchte man gerne die Druckerqueue wieder mit einem geeigneten Kommando aktivieren. Hier helfen für Remote-CUPS-Server die Kommandos

/usr/bin/lpstat
/usr/sbin/cupsenable
/usr/sbin/acccept
/usr/sbin/reject
/usr/sbin/lpadmin

"/usr/sbin/lpstat" liefert Informationen zum Drucker- bzw. Queuestatus (Acceptstatus, Aktivitätsstatus). "/usr/sbin/cupsenable" aktiviert einen Drucker - die Jobs in der Queue werden wieder abgearbeitet. "accept" sorgt dafür, dass die zugehörige Queue wieder Jobs entgegennimmt. Mit "lpadmin" kann man in unserem speziellen Fall beide Kommandos in einem Befehl kombinieren.

Im nachfolgenden Beispiel gehen wir nun auf die Option "-h" ein, die das Arbeiten von der Arbeitsplatzstation auf dem entfernten Server ermöglicht - wenn der Server das gem. Firewall- und cupsd-Konfiguration erlaubt.

Ein Beispiel-Szenario:'

Nehmen wir an, der Server hieße "oxi" und die stehende Queue "oxprinter". Ferner sei man als Druckeradministrator unter dem Usernamen "pad" auf dem Server mit den entsprechenden Rechten zur Queue-Verwaltung ausgestattet. Der User "pad" sei auch auf dem lokalen PC mit der gleichen UID eingerichtet (oder besser über LDAP zentral verwaltet). Zudem muss der 631 Port auf dem Server für den User "pad" vom Arbeitsplatzrechner aus zugänglich sein. Dies hat man in der Regel schon bei der Einrichtung des CUPS-Servers berücksichtigt. (Die nötigen Einstellungen nimmt man in der Datei /etc/cups/cupsd.conf vor.)

Dann hilft am Remote-Arbeitsplatzrechner folgende Kommandosequenz :

$> su pad
(Passworteingabe)
$> /usr/sbin/lpadmin -h oxi -p oxprinter -E

Man wird dann vom Server mit einer Passwortabfrage konfrontiert, die man entsprechend beantwortet. Danach läuft die Queue (hoffentlich) wieder an.

Die Option "-E" steht dabei übrigens für die Kombination aus "accept" und "enable";
die Option "-h" steht dabei für "host";
"-p" erwartet die Angabe der zu aktivierenden Druckerqueue.

Alternativ geht auch folgende Sequenz, wobei wir hier erst eine Abfrage des Acceptstatus der Queues und des Aktivitätstatus eingebaut haben:

$> lpstat -h oxi -a
(Anzeige Acceptstatus aller Printqueues.)
$> lpstat -h oxi -p
(Anzeige Aktivitätsstatus aller Printqueues.)
$> su pad
(Passworteingabe)
$> /usr/sbin/accept -h oxi oxprinter
(Passworteingabe)
$> /usr/sbin/cupsenable -h oxi oxprinter
(Passworteingabe)

Deaktivieren von Printern bzw. deren Queues:

Das Gegenstück zu "/usr/sbin/cupsenable" ist übrigens "usr/sbin/cupsdisable". Das Gegenteil von "/usr/sbin/accept" bewirkt das Kommando "/usr/sbin/reject".

Relevante Dateien:

Lokal: /usr/sbin/lpadmin, /usr/bin/lpstat, /usr/sbin/cupsenable, /usr/sbin/cupsdisable, /usr/sbin/accept, /usr/sbin/reject,
CUPS-Server: /etc/cups/cupsd.conf (zentrale Konfigurationsdatei für den Druckerserver)

Hinweis:
Interessanterweise wird das Kommando "lpadmin" im sonst sehr guten LPI-Buch "LPI LINUX CERTIFICATION IN A NUTSHELL" nicht angesprochen.