Monthly Archives: October 2008

Openoffice 2.4 unter MS Win mit Samba-Zugriff

Posted on by

Beim zunehmenden Einsatz von Openoffice im Unternehmen werden auch die Windows-Mitarbeiter gezwungen, sich immer mehr Dokumenten zu widmen, die unter Linux mit Openoffice erstellt wurden. Bei uns z.B. werden etliche Openoffice-Dokumente über zwei Samba-Server unter Linux (SLES 9 und Opensuse 10.3) bereitgestellt. Leider funktioniert der direkte Zugriff auf die entsprechenden Samba-Freigaben im Netzwerk von einem MS Win Client aus mit OO 2.4 nicht immer reibungslos. Die meisten Probleme – auch das nachfolgende – lassen sich aber durch einen einfachen Trick umgehen:

Fehler: Lange Verzögerungen beim Speichern von OO-Dokumenten auf Samba-Shares
Wie von anderen Dateien und Programmen her gewohnt, öffnet z.B. meine Frau und Mitarbeiterin oftmals Dateien direkt über den Windows-Datei-Explorer, indem sie die entsprechende Datei unter der Netzwerkumgebung sucht und dann anklickt. Ihr fiel nun auf, dass beim Speichern von Office-Dokumenten, die sie direkt über einen solchen Zugriff auf eine Freigabe in der Windows “Netzwerkumgebung” geöffnet hatte, manchmal mit einer deutlichen Verzögerung von bis zu 10 Sekunden zwischengespeichert wurde. Dies geschah ausschließlich bei Openoffice-Dokumenten.

Fehlerursache:
Misstrauisch geworden, habe ich mir dann die Fehlerlogs des Samba-Servers angesehen und ein paar Experimente angestellt. Ergebnis:

Beim Initiieren des Datentransfers durch Openoffice muss der richtige Samba-Service (sprich die Freigabe) angesprochen werden. Hierbei wird leider regelmäßig genau das letzte alphanumerische Zeichen des Service, der über den Dateiexplorer bzw. den “Öffnen”-Dialog von Openoffice unter MS Win gewählt wurde, nicht an den Server übermittelt. Dies ist im Samba-Fehlerprotokoll und auch über Ethereal nachweisbar.
Ich halte das für einen Bug der bei mir installierten Openoffice-Version.

Mir ist dabei übrigens nicht klar, aufgrund welcher Mechanismen das Speichern schließlich doch gelingt. Das erscheint mir sehr dubios und wäre auch unter Sicherheitsaspekten sicher eine weitergehende Analyse wert, für die mir aber gerade die Zeit fehlt. Festzuhalten ist nach ein paar Recherchen im Internet wohl Folgendes:

1) Openoffice unterstützt Samba bzw. CIFS nativ nicht wirklich korrekt.
2) Es gab und gibt sowohl unter Samba als auch bei NFS Probleme mit dem jeweiligen File-Locking-Mechanismus.
3) Das oben beschriebene Problem, bei dem nach meinem Verständnis eigentlich Windows den Zugriff auf den Samba-Share vorwegnimmt, ist ggf. ein zusätzliches.

Umgehung des Problems:
Der Fehler lässt sich unter MS Win XP (SP3) komplett umgehen, indem man Openoffice einfach jede Arbeit für den Remote-Zugriff abnimmt. Man benutze dazu vorab die Möglichkeit des Dateiexplorers zum Verbinden eines Netzlaufwerks unter dem Menüpunkt “Extras -> Netzwerklaufwerk verbinden …”. Dann gibt es keinerlei Probleme und auch das Fehlerprotokoll des jeweiligen Samba-Servers bleibt frei von Fehlermeldungen.

Hinweis zum Zugriff auf Samba-Ressourcen unter Linux:
Auch unter Linux (speziell für Debian und Ubuntu) sind in Foren des öfteren Fehler und Probleme beim Zugriff auf Dateien in Samba-Freigaben geschildert worden. Darunter auch der oben beschriebene Verzögerungseffekt beim Speichern. Inwieweit diese Probleme eine ähnliche Ursache haben, haben wir nicht untersucht.
Unter Opensuse ist mir persönlich hier nie etwas aufgefallen. Dies liegt aber evtl. daran, dass ich hier eine native Unterstützung des CIFS-Protokolls sowieso nicht voraussetze und die erforderlichen Samba-Freigaben immer vorab im Linux-Dateibaum mounte (oft per Smb4K). Dies entspricht dem oben beschriebenen Verfahren; auch hier nehmen wir Openoffice die Samba-Interaktion ab.

Hinweis zum Zugriff auf Openoffice-Dokumente auf einem OX5-Server
Ein Umfeld, in dem der Remote-Zugriff auf Openoffice-Dateien von “Konqueror”
aus immer scheitert, ist übrigens der der OX5-Groupware-Server. Dieser bietet Dateien über eine Weboberfläche und entsprechende Java-Scriptlets an. Konqueror setzt nun voraus, dass Openoffice den Zugriff auf die Resource des Webservers selbst handhaben kann Dies kann Openoffice nachweislich aber leider nicht. Firefox hingegen geht hier so vor, dass es die betreffende Datei herunterlädt und in einer temporären Datei des Linux-Systems zwischenspeichert. Mit dieser temporären Datei kann Openoffice dann wieder anstandslos arbeiten. Ich habe den Fehler gemeldet, aber bisher weder von den KDE noch den OO- oder OX5-Leuten eine hinreichende Resonanz erhalten. Es hilf der Einsatz von Firefox oder unter Konqueror auch ein Zugriff über die WEBDAV-Schnittstelle des OX5 . Dies führt hier aber zu weit.

Firefox 3 – bikubisch schlechte Performance

Posted on by

Vor kurzem noch habe ich mich darüber geärgert, dass die Mozilla-Entwickler der Linux-Variante des Firefox 3.0 keine bikubische Bildinterpolation bei der Skalierung der Seiten verpasst hatten. Dies erschien mir doch als gravierender Nachteil gegenüber der Windows-Variante. Nun nach weiteren Erfahrungen – insbesondere von Kunden – sehe ich das etwas differenzierter.

Warum ?

1) Die Mozilla-Entwickler haben lt. einer Forums-Diskussion unter MS Windows auf Interpolations-Methoden (Routinen) der Microsoft GUI zurückgegriffen. Das ist insofern bedenkenswert, als hier zeitintensiver externer Code mit internen Darstellungsroutinen des Browsers verkoppelt werden muss.

2) Der Preis der unheiligen Allianz mit der Windows-GUI entpuppt sich als extrem hoch:

Man erhält nach dem Zoomen der Webseiten zwar schöne glatte Bilder – aber die Performance beim Scrollen von Bildern und IFRAMES in einer vergrößerten Zoomstufe des Browsers ist im FF 3.0 unter aller Sau und erheblich schlechter als im FF 2.X oder im MS IE 7. Die Scroll-Performance ist bereits auch ohne vergrößernden Zoom schlechter als im FF 2.0 – aber so richtig übel wird es nach dem Vergrößern (Zoomen) der Seiten: horizontales und vertikales Scrollen von Iframes mit größeren Bildern führt zu abenteuerlichen Schlingerbewegungen des Bildes, das offenbar in mehrere Bereiche unterteilt wird, die unterschiedlich schnell transportiert werden.

Hier wird deutlich erkennbar, dass die Bilder zerlegt (gekachelt) werden und dass die (vermutlich laufend) stattfindende Interpolation der Kacheln zu erheblichen Zeitverlusten während des Scrollings führt. Der MS IE 7 hat dieses Problem offenbar viel besser gelöst. Hier muss man sich wirklich fragen, wie die Mozilla-Entwickler die Loops für das Darstellen des Scrolling der IFRAMES und der enthaltenen Bilder (bzw. deren Kacheln) mit der externen Interpolationsroutine von MS verknüpft haben. Die Verlangsamung des Scrollens ist in mir bekannten Fällen gegenüber dem FF 2.0 jedenfalls nachweislich haarsträubend.

Dass es sich um ein reines Problem des FF 3.0 unter MS Windows handelt, zeigt sich denn auch an der Linux-Variante des FF 3.0: Hier funktioniert das Scrollen auch großer Bilder in IFRAMES in hohen Zoomstufen glatt und verzerrungs- bzw. ruckelfrei. Und um Mißverständnissen vorzubeugen: das liegt nicht an Parameter-Einstellungen zum “sanften Bildlauf” !

Fazit:
Wer sich mit den Teufel einlässt, muss wissen, was er tut, oder er bezahlt einen hohen Preis. Ich habe bereits den ersten Kunden, der unter Windows wieder von FF 3.0 auf MS IE umgestiegen ist.

Mir ist im Übrigen völlig unverständlich, warum die Mozilla-Entwickler nicht ein eigenes bikubisches Interpolationsverfahren in den Browser integrieren und sich diesbzgl. von der MS GUI unabhängig machen. Wie man solche Routinen aufsetzen muss, kann man an der GLIB-Komponente von PHP lernen. Es ist eine alte Erfahrung, dass man selbst entwickelten Code letztlich viel besser in performance-relevante Abläufe einbinden oder an solche Abläufe anpassen kann als externen Code.

Aber was reg ich mich auf?

Unter Linux geht das Scrollen ja immer noch performant ! Und das ist mir – ehrlich gesagt – fast lieber als glatte Bilder …

Remote Druckerverwaltung

Posted on by

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.