Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Unison – Synchronisation mit GUI

Posted on by

Die gestrige Frage meiner geschätzten Gattin, wie ich es denn eigentlich so schnell schaffen würde, ein für unser Geschäft wichtiges Verzeichnis zwischen einem Linux-PC und einem Linux-Server, einem Windows XP-Laptop und einem anderen Linux-PC abzugleichen, ist vielleicht auch für andere Linux-User interessant.

Mein Freund und Konsolen-Liebhaber Michael würde nun antworten: “rsync”. Ich bin aber ein fauler Mensch. Und gerade im Konfliktfall muss man die Arbeitsweise und die Antworten von Rsync schon recht gut verstehen. Michael würde nun weiter sagen: Na, dann schreib dir halt ein Script. Meine Antwort darauf ist: Das haben andere schon gemacht – plus eine GUI dazu entwickelt.

Ein Beispiel für eine nette Applikation in diesem Umfeld stellt meiner Meinung nach “Unison” dar. Ich liste mal kurz die für mich wichtigen Eigenschaften auf:

  • Unison benutzt rsync, ist damit relativ schnell und vermittelt zwischen den Welten Linux, Unix, Mac OX und Windows.
  • Unison hat eine leicht zu überblickende und leicht zu bedienende graphische Oberfläche.
  • Unison erlaubt die Organisation der Abgleichvorgänge über Profile.
  • Unison gleicht Verzeichnisse natürlich auf Wunsch rekursiv ab.
  • Unison zeigt vor dem Abgleich an, was sich geändert hat.
  • Unison stellt Abgleichkonflikte in verständlicher Weise dar und gibt die Möglichkeit diese Konflikte pro Datei zu lösen.
  • Unison kann zusammen mit ssh benutzt werden.
  • Unison funktioniert auch über das Internet.
  • Unison funktioniert auch lokal – die abzugleichenden Verzeichnisse können auf ein und demselben Rechner liegen.

Letzteres ist besonders in Kombination mit NFS, Samba und smb4k interessant. Wenn keine größeren Sicherheitsanforderungen im lokalen Netz vorliegen und man die entsprechenden Rechte hat, hängt man die Laufwerke/Directories des Fremdrechners, auf dem sich das abzugleichende Verzeichnis befindet, einfach in das eigene Filesystem ein und führt dann den Abgleich durch. Das geht rasch und bequem.

Unison hat aber auch einen großen Nachteil – es funktioniert nicht, wenn der UTF8-Zeichensatz für Verzeichnis- oder Dateinamen ausgenutzt wird. Leider ! Wenn man aber im abzugleichenden Bereich diszipliniert mit konventionellen Dateinamen (ASCII 7) arbeitet, steht dem Einsatz von Unison als Synchronisationstool nichts im Wege – auch nicht für Arbeitsgruppen im Firmenumfeld.

Ein weiterer “Nachteil” ist ggf. der, dass man einen Abgleich zwischen mehreren Systemen durch sukzessive paarweise Abgleichvorgänge herbeiführen muss.

Dennoch: Einen Blick und einen Testlauf ist das einfach zu installierende Tool auf jeden Fall wert !

Apache 2, Zeichensätze und Direktiven

Posted on by

Gestern hielt mich ein kleines Problemchen mit der Zeichensatzauswahl auf Apache Server unter SLES 9 auf.

Problembeschreibung

Mehrere von meiner Firma entwickelte Webseiten waren per Metatag-?nweisung vom ISO-8859-1 Zeichensatz

<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>

auf UTF-8 umgestellt:

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>

Bei den anschließenden Test mit einem Browser auf dem Server selbst sahen die Webseiten OK aus. Umlaute wurden korrekt dargestellt. Chaotisch wurde es jedoch, als wir die Seiten auf einem separaten Client-PC betrachten wollten. Alle Umlaute waren falsch. Zwar half eine explizite Umstellung des zu wählenden Zeichensatzes im Browser – aber eigentlich wünscht man sich hier eine automatische, richtige Wahl.

Ein Test derselben Web-Seiten auf einem anderen Apache-Server ergab dagegen gute Ergebnisse. Die Sache hatte also nichts mit Browser-Einstellungen oder anderen Client-Problemen zu tun.

Response Header

Weiter kommt man in einem solchen Fall zunächst dadurch, indem man sich ansieht, was der Server dem Browser nach der Seitenanfrage eigentlich so übermittelt. Den sog. “Response Header” kann man sich u.a. mit Funktionen des Firefox-Browsers ansehen. Die notwendige Angaben erhält man im aktuellen FF über den Menüpunkt:

“Extras” -> “Web Developer” -> “Information” -> “View Response Headers”.

Hier kam dann tatsächlich die Angabe, dass als Zeichensatz ISO-8859-1 gelten soll – und zwar über die Header-Zeile:

Content-Type: text/html; charset=iso-8859-1

Beim dem anderen getesteten Server, mit dem der Browser “richtig” zusammenarbeitete, war im Response Header dagegen gar keine Vorgabe zum Zeichensatz eingetragen. Der Befund, dass die Schwierigkeiten mit Servereinstellungen zu tun hatten, bestätigten sich also.

Leider sind die Einstellungen zu Zeichensätzen für den Apache2 in unterschiedlichen Linux-Distributionen auch in unterschiedlichen Dateien untergebracht. Ein wenig Suchen nach Begriffen wie “Charset” oder “ISO-8859” in den Dateien der Apache2-Konfigurationsdateien ist im Einszelfall daher ggf. notwendig.

Zeichensatzvorgaben auf dem Apache unter SLES 9

Bei SLES9 wird man in der Datei

/etc/apache2/mod_mime-defaults.conf

fündig. Auf anderen Servern können die Einstellungen aber auch in einer Datei “/etc/apache2/conf.d/charset” vorgegeben sein!

Dort werden nach Language-Festlegungen Vorgaben für Zeichensätze in der Form

AddCharset ISO-8859-1 .iso8859-1 .latin1
AddCharset utf-8 .utf8

getroffen. Wegen der Zeile für utf-8 wundert man sich vielleicht, wieso dann im obigen Beispiel im Response Header die Vorgabe ISO-8859-1 auftaucht. Der Grund ist/war auf dem “problematischen” Server die zusätzliche Zeile

AddDefaultCharset ISO-8859-1.

Ein testweises Auskommentieren und Neustarten des Apache2-Servers zeigte dann tatsächlich, dass diese Zeile die Ursache für die “Probleme” auf dem Browser bzw. die ISO-8859-1 Zeile im Response Header darstellte.

An dieser Stelle ist nun aber ein wenig Kontemplation gefragt, denn ein generelles Auskommentieren kann ja ggf. auch ein Sicherheitsrisiko darstellen. Und was macht man, wenn man Einstellungen auf einem Server treffen muss, über dessen Apache-Konfigurationsdateien man keinen Einfluss hat? Dies ist ja die typische Situation bei Hostern. Zudem fragt man sich, wie man
vorgehen muss, wenn man auf folgende Situationen trifft:

a) Man benötigt für die Dateien in ganz bestimmten definierten Verzeichnissen Charset-Vorgaben, die dem Default nicht entsprechen.

b) Man hat einen Mix aus Seiten mit unterschiedlichen Charset-Festlegungen im gleichen Verzeichnis.

Ich versuche weiter unten, nach einem Blick in die Apache-Konfiguration meinen “best guess” abzugeben.

Was sagt die Apache-Doku ?

In der Apache Dokumentation auf der Webseite “http://httpd.apache.org/docs/2.0/mod/core.html” finden sich u.a. folgende Hinweise (die Hervorhebungen habe ich vorgenommen)

Description: Default charset parameter to be added when a response content-type is text/plain or text/html
Syntax: AddDefaultCharset On|Off|charset
Default: AddDefaultCharset Off
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Core
Module:coreThis directive specifies a default value for the media type charset parameter (the name of a character encoding) to be added to a response if and only if the response’s content-type is either text/plain or text/html.

This should override any charset specified in the body of the response via a META element, though the exact behavior is often dependent on the user’s client configuration.

A setting of AddDefaultCharset Off disables this functionality. AddDefaultCharset On enables a default charset of iso-8859-1. Any other value is assumed to be the charset to be used, which should be one of the IANA registered charset values for use in MIME media types. For example:

AddDefaultCharset utf-8

AddDefaultCharset should only be used when all of the text resources to which it applies are known to be in that character encoding and it is too inconvenient to label their charset individually.

One such example is to add the charset parameter to resources containing generated content, such as legacy CGI scripts, that might be vulnerable to cross-site scripting attacks due to user-provided data being included in the output. Note, however, that a better solution is to just fix (or delete) those scripts, since setting a default charset does not protect users that have enabled the “auto-detect character encoding” feature on their browser.

Einige ergänzende Kommentare:

Ist die Direktive AddDefaultCharset gesetzt, so fügt Apache Zeichensatzinfos zum Content-Type-Header von HTTP-Antworten hinzu. Z.B.:

Content-Type: text/html; charset=iso-8859-1

Ist eine solche Angabe vorhanden, so übersteuert das bei den meisten Browsern eine evtl. vorhandene Meta-Tag-Angabe zu Zeichensätzen in der empfangenen HTML-Datei. (Dies war ja gerade die Ursache des oben beschriebenen Problems).

Man beachte, dass man lt. der obigen Beschreibung ein solches Verhalten auch durch

AddDefaultCharset Off

explizit abschalten kann.

Ferner kann man – soweit sonstige Einstellungen das zulassen – die Direktive “AddDefaultCharset” auch zusammen mit “.htaccess”-Dateien, also verzeichnisspezifisch, einsetzen.

Lösungsansätze für die Zeichensatzsteuerung

Auf den von mir selbst verwalteten Servern setze ich grundsätzlich eine serverweite Einstellung ein – in meinem Fall ISO-8859-1 (per AddDefaultCharset ISO-8859-1 ) in den globalen Apache-Einstellungen (bei SLES 9 in /etc/apache2/mod_mime-defaults.conf).

Ein Grund hierfür sind die Sicherheitsbedenken, die in der Apache-Doku bzgl. des
Abschaltens anklingen und auf die man in diversen Internet-Artikeln treffen kann.

Virtuelle Domainen mit spezifischen Default Zeichensätzen

Für größere Kunden-Projekte (Webseiten-Entwicklung) lege ich mir zumeist separate virtuelle Domainen an. (Das erleichtert später den Aufruf der Seiten beim Testen, macht die Umgebung kontrollierbarer und spiegelt schon in der Entwicklungsphase mehr die Realität der Kundensicht wieder.) Habe ich eine durchgehend einheitliche Zeichensatzverwendung für die Webseiten der virtuellen Domaine zu erwarten, setze ich den Default-Zeichensatz in der Konfiguration der virtuellen Domaine per “AddDefaultCharset” auf den entsprechenden Wert.

Einsatz von “.htaccess”-Dateien für verzeichnisspezifische Festlegungen

Muss ich mit unterschiedlichen Zeichensätzen der zu erstellenden Webseiten rechnen, so versuche ich eine Strategie zu fahren, bei der man die Dateien mit jeweils gleichen Zeichensätzen in Verzeichnissen bündelt. Dann kann man nämlich zum “.htaccess”-Mechanismus greifen und die verzeichnisspezifischen Einstellungen über die Festlegungen in zugehörigen “.htaccess”-Dateien treffen. Alternativ kann man auf Servern, die der eigenen Kontrolle unterstehen, aber auch über gezielte Direktiven in <Directory>-Abschnitten zur jeweiligen Domaine vorgehen.

Über den Einsatz von “.htaccess”-Dateien erschlägt man übrigens evtl. Probleme bei den meisten Providern – soweit sie den “.htaccess”-Mechanismus überhaupt zulassen.

Verzeichnisspezifisches Abschalten des Default Zeichensatzes kann u.U. eine Möglichkeit sein

Hat man einen Mix aus Dateien mit unterschiedlichen Zeichensätzen in ein und demselben Verzeichnis einer (virtuellen) Domaine zu erwarten, so schalte man entweder die Zeichensatzvorgabe für die gesamte Domaine oder das Verzeichnis ab (“AddDefaultCharset Off”). In letzterem Fall natürlich wieder über eine “.htaccess”-Datei.

Der gezielte Einsatz von Dateiendungen

Will man zu keinem der oben genannten Mittel greifen, so kann man immer noch über Dateiendungen arbeiten. Die Zusatzangaben zu Datei-Endungen in den Direktiven “AddCharset” legen nämlich fest, auf welche Dateien der Zeichensatz angewendet werden soll.

AddCharset utf-8   .utf8

Eine betroffene Datei “test.html” muss dann halt in “test.html.utf8” umbenannt werden. Nach gleichem Muster verfährt man für Dateien mit anderen Zeichensätzen – also: Datei-Endung für den Zeichensatz vorgeben und hinten an den Dateinamen anhängen.

Links und weitere Informationen

Grundsätzliches :
http://httpd.apache.org/docs/2.0/mod/core.html

Generelle Möglichkeiten, die Zeichensatz-Regeln des Apache-Servers für spezielle Verzeichnisse oder Files anzupassen, werden unter folgenden Links diskutiert:
http://www.w3.org/International/questions/qa-htaccess-charset
http://www.linuxforen.de/forums/showthread.php?t=229702

Das Vorgehen zur konsequente Umstellung eines LAMP Servers auf UTF-8 kann man z.B. unter folgenden Links nachlesen:
http://wiki.hetzner.de/index.php/Utf-8
http://www.xaranetblog.de/page/5/

Ärger beim Wechsel von OO 2.4 zu OO 3

Posted on by

Nachfolgend die Beschreibung einiger Nicklichkeiten, die mir heute an produktiven Arbeitsplätzen auffielen, bei denen gerade von Openoffice 2.4 auf Openoffice 3.0.1 bzw. 3.1.0.6 gewechselt worden war:

Impress 3.0.1 und Einzüge der Gliederungspunkte

Hatte man sich im Master einer OO 2.4 odp-Datei die Bullets und die Einzüge der verschiedenen Gliederungsebenen mühsam über die Formatierung der “Nummerierung und Aufzählungszeichen” hingebastelt, so freut man sich natürlich, wenn man das Dokument unter OO 3.0.1 öffnet und die Gliederungspunkte seiner Präsentationsseiten an den alten Stellen vorfindet. Die Freude wird jedoch schlagartig getrübt, wenn man dann in einer solchen Liste von Gliederungspunkten einen neuen Punkt einfügen will, ihn mit der Tab-Taste auf die richtige Ebene bringt und der neue Punkt plötzlich nach rechts oder links verschoben auftaucht, während alle alten Punkte auf der Zielebene da verharren, wo sie waren.

Als Ursache entpuppt sich nach ein wenig Spielerei eine Korrektur des Berechnungsverfahrens für die Einzüge in Kombination mit evtl. Einzugsvorgaben in den Formatvorlagen für die Gliederungsebenen “Gliederung 1, Gleiderung 2, … ” : Hatte man in OO 2.4 in der Formatbeschreibung der “Gliederung x” einen Einzug definiert und gleichzeitig eine Positionierung der Bullets und Texte über die “Nummerierung” vorgenommen, so zog der durch die “Nummerierung” vorgegebene Einzug. Der Einzug der Formatvorlage “Gliederung x” blieb unwirksam.

In OO 3 wird dagegen der Gesamteinzug (richtigerweise) so berechnet, dass der Absatzeinzug zunächst über die Vorgabe für die “Gliederung x” vorgegeben wird. Additiv hinzu kommt dann der über die Nummerierungsformatierung definierte Einzug. Hatte man also im OO 2.4 odp-Dokument Einzüge für die Gliederungs-Formatvorlagen definiert, so werden diese Einzüge für neu angelegte Gliederungspunkte unter OO 3.0.1 plötzlich wirksam. Das Peinliche an der Sache ist das, dass man es sich bei der Übernahme der 2.4 Objekte zu einfach gemacht hat: Dort bleibt nämlich zunächst alles beim alten. Nur jeder neu (!) angelegte Gliederungspunkt verrutscht. Für den Anwender ist dies zunächst ein völlig undurchschaubares Verhalten.

Das Ganze funktioniert nach dem Muster: Wir haben die Berechnung der Einzüge verändert. Damit die Anwender beim Öffnen von Dokumenten aus früheren OO-Versionen nicht gleich erschrecken, lassen wir die Positionierung der alten Gliederungspunkte trotz neuer Berechnungsvorschrift unverändert. Die neue Positionsberechnung wenden wir nur auf neue Punkte an.

Dies ist ein Beispiel dafür, wie man durch Behebung eines Fehlers und gleichzeitige inkonsequente Übertragung der Berechnungsvorschriften auf alte Dokumente-Einträge den unbedarften Anwender vorübergehend in den Wahnsinn treiben kann.

Um die aus dem 2.4-er-Stand übernommen Gliederungspunkte mit den neuen Gliederungspunkten bzgl. des Einzugs gleichzuschalten, kann man übrigens die Einzugsdefinitionen für die Formatvorlagen “Gliederung x” in einem betroffenen Dokument komplett auf 0 stellen.

Impress 3.x und die Position von Tabulatoren

Hat man das Lineal eingeblendet und fügt einem Gliederungsabsatz einen Tabulator hinzu und schiebt diesen dann im Linealbereich per Maus auf die Position 22.0 cm, so würde man als naiver Anwender erwarten, dass ein Öffnen der Maske zum Editieren der Tabulatoreigenschaften des Absatzes einem dann eine Position von “22.0 cm” anzeigt. Dies ist jedoch nicht der Fall: Je nach Einzugsdefinition der Formatvorlage “Gliederung x” wird ein anderer Wert angezeigt. Nur die Addition des Absatzeinzugs mit der Tabulatorposition ergibt die graphisch vorgegebene Wunschposition 22.0 cm. Die Tabulatorposition ist also relativ zum Einzug zu verstehen.

Wäre man umgekehrt von vornherein über die Eingabemaske für Tabuatoreigenschaften vorgegangen und hätte dort die Tabulatorposition auf 22.0cm vorgegeben, so hätte man sich gewundert, warum der Tabulator im graphischen Lineal nicht bei 22.0 cm steht. Hier vermisse ich einen kleinen entsprechenden Hinweis für den User in der Maske zur Tabulatorpflege.

Ausbleibender Screenupdate beim Löschen eingefügter Zeilen mit Formeln in Calc 3.0.1

Man füge 2 Zeilen in ein OO 3.0.1 ods-Tabellendokument ein – mit folgenden Eigenschaften:
Zeile 1: Spalte A: Beliebiger Text / Spalte C: Zahlenwert 50 / Spalte D: Zahlenwert 1 / Spalte F : Funktion WENN(D1=1;C1;0)
Zeile 2: Spalte A: Beliebiger Text / Spalte C: Zahlenwert 80 / Spalte D: Zahlenwert 0 / Spalte F : Funktion WENN(D2=1;C2;0)

Nun füge man eine leere Zeile zwischen diesen beiden Zeilen ein. Im nächsten Schritt versuche man, die eben eingefügte Zeile zu löschen (per Kontextmenü). Auf dem PC, auf dem ich heute gearbeitet habe, verschwand dann das Kontextmenü nur teilweise und die zu löschende Zeile blieb stehen. Erst ein über andere Aktionen erzwungener Screenupdate (z.B. durch ein kurzes Scrollen mit der Maus) führte zum gewünschten Ergebnis in der Tabellenansicht. Wehe dem User, der den Screenupdate nicht erzwingt und in die verbleibene (optisch) nicht gelöschte Zeile etwas reinschreibt. Beim nächsten Screenupdate verschwindet dann die gelöschte Zeile doch und die Änderung hat sich leider 1 Zeile tiefer ausgewirkt.

Das Problem taucht nicht auf, wenn man keine Formeln in den Zellen der Zeile hat. Naiv würde ich mal vermuten, dass die Ursache eines solchen Bugs darin liegt, dass man in einem Modell-View-Kontext vergessen hat, nach dem Updaten aller Formelergebnisse im Modell-Bereich auch den View wieder upzudaten.

Der Fehler taucht in aktuelleren Versionen von Calc nicht mehr auf. Dennoch war er in der produktiven Umgebung , in der ich heute arbeiten musste, fast ein Show-Stopper.

Probleme beim Öffnen von doc-Dokumenten in OO 3.1.0.6, die mit Writer 2.4 erzeugt wurden

Meine Frau und ich müssen ab und zu mit doc-Dokumenten umgehen oder solche ausliefern. Das machen wir natürlich – soweit möglich – mit OO. Blöd nur, wenn man ein Dokument mit wichtigen Tabellen, das man mit Writer 2.4 erzeugt und ins “doc”-Format umgewandelt hatte, nun mit Writer 3.1.0.6 öffnet und die Tabellen nicht mehr sieht. Noch blöder, wenn die Tabellen Basisdaten für eine Rechnung enthalten haben und der Kunde bestimmte Rechnungspositionen gerade jetzt am Telefon diskutieren will. Peinlich auch, dass die “doc”-Datei mit Writer und nicht mit MS Word erzeugt worden war. Ursache des Fehlers ist wie so oft eine Änderung in der Berechnung der Tabellenposition – besonders hart trifft der Bug Tabellen, die im Originaldokument etwas über den Rand des allgemeinen Textbereichs hinaus verschoben positioniert waren.

Wenn man ins Detail gehen wollte, könnte man an dieser Stelle noch eine Seite lang über wechselnde Positionen von Absätzen, Tabellen und Tabelleninhalten je nach 3.x-Version von OO berichten. Dafür bin ich heute aber zu müde.

Fazit: Eine bessere QS würde dem OO-Projekt gut tun

Liebes OO-Entwicklungs- und Release-Team! Bitte verbessert eure QS! In produktiven Umgebungen müssen sonst nämlich der Admin oder im schlimmeren Fall die Anwender Beta-Tester für neue OO-Versionen spielen. Das erinnert an MS, kostet einfach zu viele Nerven und verbessert den Ruf von OO überhaupt nicht. Es passt auch nicht zu den vollmundigen “latest und greatest” -Beschreibungen von neuen OO-Releases, die man auf der OO-Website lesen muss.

Ich kann jedem Admin nur raten, sich ein paar Werkstudenten zu holen und jede neue OO-Version gründlich und ausführlich zu testen, bevor er sie produktiv schaltet.
Dabei lohnen sich besonders Tests älterer Dateien und der Blick auf die Formatierung der dortigen Inhalte wie auch Tests von Dokumenten, die mit älteren OO-Version in MS-Formate umgewandelt wurden und nun mit einer neuen OO-Version geöffnet werden.

Einstweilen warten wir bei anracon auf die Version 3.1.1 !