VMware WS: Wechsel zw. Multi/Single-CPU WIN XP Guest

Installiert man als Linuxer ein Windows-System in einer virtuellen VMware Workstation, so wählt man beim ersten Anlauf i.d.R. eine virtuelle Maschine mit einem Prozessor. Leute, die die VMware Workstation auf einem Linux Host mit Quadcore Prozessor einsetzen, werden aber früher oder später mal ausprobieren, wie sich ein Win XP Pro Gastsystem verhält, wenn man in der virtuellen Maschine 2 Prozessoren  aktiviert.

Stellt man dann fest, dass die Performance nicht so berauschend ist, möchte man ggf. wieder zu einem virtuellen Gast mit nur einem Prozessor zurückkehren. Leider ist es dabei nicht mit einer entsprechenden Einstellung der Prozessoranzahl unter VMware getan. Win XP Pro zeigt dann im Gerätemanager zwar brav an, dass nur ein Prozessor läuft.  Aktiv ist aber immer noch der Mehrprozessor HAL. Woran erkennt man das ?

 
Einstellungen unter “Computer” im Win XP Gerätemanager

Welcher HAL (+ Windows Kernel) läuft und welche Alternativen man grundsätzlich hat, erkennt man, indem man sich im Gerätemanager die Einstellungen unter “Computer” ansieht.

Hat man Win XP in der virtuellen Maschine zunächst normal für einen Prozessor installiert, so findet man dort zumeist einen Eintrag

“ACPI -PC” vor.

Geht man nun per rechtem Mausklick auf “Treiber aktualisieren” und läßt sich dort alle Möglichkeiten anzeigen, so bekommt man eine Auswahl von vier Varianten:

HAL32-Auswahl

WIN XP Pro schaltet nach einem Wechsel der virtuellen Maschine vom Single- zum Mehrprozessor-System automatisch zum “ACPI-Multiprocessor – HAL” um. Wechselt man also  in einen Zustand mit 2 Prozessoren, so ändert sich der Eintrag unter “Computer” auf “ACPI-Multiprocessor-PC”; die Auswahl unter “Treiber aktualisieren” bleibt aber (meist ?) erhalten.

Das eigentliche Problem kann nun entstehen, wenn man die virtuelle Maschine wieder auf einen Prozessor reduziert. Danach ist der HAL nicht korrekt eingestellt; die Auswahlmöglichkeiten bei “Treiber aktualisieren” sind aber leider auch verschwunden! Und dies ändert sich auch nicht mehr, wenn man die virtuelle Maschine wieder auf 2 Prozessoren umstellt.

Das war zumindest bei mir der Fall. (Im Internet liest man, dass zumindest der Win 2003 Server ein anderes Verhalten zeigt und die Auswahlmöglichkeiten in jedem Zustand anbietet – beschwören möchte ich daher das bei mir festgestellte Verhalten nicht.)

Mein virtuelles Windows-System jedenfalls lief nach dem Downgrade auf 1 Prozessor weiter mit dem Multiprozessor HAL und ließ sich nicht mehr umstellen. Beim Forschen im Internet kam ich bei MS zu der Information, dass ein solcher Downgrade-Vorgang nicht unterstützt würde und eine Neuinstallation von Windows notwendig sei. Auch über ältere (aber nicht zu alte) Wiederherstellungspunkte des Systems kam ich nicht zum Ziel. Im Gegenteil: Weil da ja noch 2 Prozessoren vorausgesetzt waren, die Maschine laut VMWare-Einstellung aber nur noch 1 Prozessor hat, streikt die Wiederherstellung.

Wie kann man dieser Situation durch kluges und vorausschauendes Management entkommen ?

 
Varianten für eine Rückkehr zum Single-Prozessor-Zustand  und deren Vorbereitung

1) Variante 1:

Eine Variante ist die, die gesamte virtuelle Maschine schon vor dem ersten Wechsel auf mehrere Prozessoren zu klonen. Hat man genügend Platz, so ist dies mit Sicherheit der beste Weg. Man probiert die Mehrprozessor-Variante aus, fährt in der Zeit keine Updates, speichert neue Files auf einem Netzlaufwerk und kann ggf. wieder zurück zur älteren Version. Nicht brauchbar ist diese Methode ggf., wenn man während der Experimentierzeit ernsthafte Veränderungen am System vorgenommen hat, die man später nicht verlieren will.

2) Variante 2

Eine zweite Variante besteht aus meiner Sicht darin, mit VMware Snapshots zu arbeiten. Allerdings habe ich eine Rückkehr zu Snapshots vor und nach einem Wechsel der Prozessoranzahl bislang nie ausprobiert. Sollte aber funktionieren. Wichtig ist es, den ersten Snapshot vor dem Wechsel zum Multiprozessor-Zustand anzulegen – und zur Sicherheit auch noch einen weiteren danach.

3) Variante 3

Variante 3 ist laut einer Diskussion im VMware-Forum unsicher und möglicherweise mit Nebenwirkungen versehen. Bei mir hat sie aber funktioniert. Dennoch – keine Garantie von mir, dass das immer gut geht.

Die Methode besteht darin, noch vor dem ersten Wechsel von einer Single-Prozessor-Installation auf ein Multiprozessor-System (!) das “system32”-Verzeichnis zu sichern. Darin befinden sich mindestens 3 Dateien, die man später benötigt, um zum alten Zustand mit einem Single-Prozessor HAL zurückzukommen :

hal.dll, ntkmlpa.exe, ntoskml.exe

Diese Dateien haben im Multiprozessor und im Single-Prozessor-Zustand übrigens unterschiedliche Größe, was für sich spricht. (Ggf. findet man im system32-Verzeichnis auch die Dateien halacpi.dll und halmacpi.dll vor, wie manche Zeitgenossen behaupten – dann mitsichern.)   

Genau das Gleiche – also die Sicherung des system32-Verzeichnisses – macht man dann nach der Aufrüstung der virtuellen Maschine – also im Multiprozessor-Zustand. Man hat dann also die oben genannten Dateien in den unterschiedlichen Zuständen (für eine 1 Prozessor-Umgebung und für eine Mehrprozessor-Umgebung) zur Verfügung. (Das Backup des gesamten Verzeichnisses führe ich nur zur Sicherheit durch.)

Will man dann in den Single-Prozessor-Zustand zurück, so stellt man zunächst VMware auf 1 Prozessor um. Danach bootet man den Win XP Gast (ggf. im abgesicherten Modus mit Netzwerk) und kopiert dann von einer externen Quelle die oben genannten 3 gesicherten Dateien für den Single Prozessor Zustand ins “system32”-Verzeichnis. Nach einem Reboot findet man dann Win XP hoffentlich im ordnungsgemäßen Zustand – in meinem Fall mit einem ausgewählten “ACPI PC”-HAL vor. Auch die vier Wahlmöglichkeiten sollten dann wieder angezeigt werden.

Übrigens: Auch ein anschließender erneutet Wechsel zurück in den Multiprozessor-Zustand funktionierte problemfrei.

4) Variante 4

Die letzte Variante entspricht im wesentlichen der dritten. Allerdings wird hier eine andere Quelle für die drei fraglichen D ateien verwendet. In Frage kommt z.B. die Win XP Pro Installations CD.

Dort muss man das I386 Verzeichnis öffnen. Im SP2.Cab muss man halacpi.dll, ntkrnlpa.exe und ntoskrnl.exe extrahieren und in einem Verzeichnis abspeichern. Danach halacpi.dll in hal.dll umbenennen und alle drei Files in den system32-Ordner kopieren.

Ggf. kann man aber auch die Dateien von einem laufenden anderen Windows System mit 1 Prozessor holen. Vorher aber prüfen, dass dort tatsächlich der ACPI-Hal läuft, wenn das Ziel – nämlich die virtuelle Maschine – selbst den ACPI HAL verwendet.

Variante 4 ist dann von Interesse, wenn man die Sicherungen/Snapshots etc. für den ursprünglichen Einprozessor-Zustand nicht oder nicht mehr hat.

In meinem Fall habe ich die 3 Dateien für den Single-Prozessor-Zustand übrigens von einer anderen Windows-Installation auf einem  Einzelprozessor-System geholt.

Ich hoffe, dass hilft den experimentierfreudigen Lesern und VMware-Enthusiasten weiter.

In jedem Fall gilt:  Trotz aller Features von VMware wie Klonen und Snapshots lohnt sich ein Backup der virtuellen Windows-Systeme, wenn man trotz Linux ernsthaft damit arbeiten muss.

Flackern beim Seitenwechsel im MS IE

Viele Websites beinhalten Seiten, die vom Grundaufbau/Layout her völlig identisch aussehen. D.h., sie beinhalten viele begrenzende oder Hintergrunds-Elemente, die auf allen Seiten völlig gleich aussehen.

Bei einem Wechsel zwischen zwei Seiten erwartet man dann, dass die identisch aussehenden Seitenelemente während des Wechsel ohne jedes Flackern dargestellt werden. Der Wechsel soll für das Auge des Betrachters also so ablaufen, als ob nur die unterschiedlichen Seitenanteile im Wechsel neu aufgebaut werden. Die identisch aussehenden Elemente sollen beim Seitenwechsel dagegen als völlig statisch erscheinen. Es soll vor allem zu keinem Flackern beim Seitenaufbau kommen. Flackereffekte (kurzzeitige Hell-Dunkel-Wechsel in bestimmten Seitenbereichen) wirken auf die meisten Betrachter irritierend.

Leider stellt man aber immer wieder fest, dass es gerade bei komplexeren Seiten im MS IE zu diesem unangenehmen Flackern kommt – oft genau in den Bereichen, die beim Seitenwechsel eigentlich unverändert bleiben. Dagegen kann man bei Browsern wie Firefox, Opera, Konquerer oft  einen stabilen, flackerfreien Bildwechsel während des Renderns der neuen Seiten konstatieren. (Ausnahmen stellen Seiten dar, die Flash-Elemente beinhalten.) Wir haben das Problem schon des öfteren mit gewöhnlichen HTML-Seiten, aber auch im Zusammenhang mit PHP-Seiten festgestellt.

Wie kann man als Entwickler das nervige Flackern im MS IE in den Griff bekommen ?

Hierfür gibt es nach unserer Erfahrung mindestens zwei Tricks:

Trick 1: MS IE spezifisches Metatag

Im MS IE kann man den Seitenwechsel mit (teils spektakulären) Effekten unterlegen, die eine bestimmte Zeitdauer haben. Die Render-Engine arbeitet in diesem Modus anders als gewöhnlich. Wir nutzen das an dieser Stelle zur Vermeidung des Flackerns aus. Zur Parametrierung der Effekte dient ein Metatag der folgenden Form

<meta http-equiv=”Page-Enter” content=”revealtrans(duration=0.1,transition=5)” >

Der Parameter “duration” gibt die Zeitdauer des Effektes in Sekunden an, der Parameter “transition” den ausgewählten Effekt. In unserem Fall wird die Seite von oben nach unten aufgebaut (abgerollt) – die Zeitdauer ist allerdings so kurz gewählt, dass man das praktisch nicht merkt. Der von uns gewünschte Seiteneffekt ist allerdings der, dass ein Seitenwechsel nun in vielen Fällen völlig stabil und ohne jedes Flackern vor sich geht.

Weitere Information zu “revealtrans” findet man im Internet.

Trick 2: Einbau von Dummy-DIVs mit einer Opacity-Anweisung

Auch wenn man auf einem Layer der Webseite mit hohem z-Index ein Dummy-DIV mit einer Opacity-Vorgabe integriert, reagiert die Render-Engine des MS IE positiv im Sinne der Flackerfreiheit. Ein Element der Form :

<div style=”position:absolute; width:0.5em; height:0.5em; top:0.1em; left:0.1em; filter: alpha(opacity=66); -moz-opacity: .66; opacity: .66; z-index:10;”></div>

ist an sich zwar völlig sinnlos (da ohne Hintergrundsfarbe), zieht aber dennoch die Flackerfreiheit des Seitenaufbaus nach sich. (Ausschlaggebend für den MS IE ist dabei übrigens die “filter”-Anweisung.)

Viel Spass in Zukunft beim “Beruhigen” des MS IE.

Nachtrag am 18.11.2009: 

Im Falle von Hintergrundsbildern, die per CSS in Tags eingebunden werden, helfen die obigen Tricks in der Regel nichts. Siehe aber die Hinweise von Anne zu weiteren Möglichkeiten im Kommentar ! Danke, Anne !

Nachtrag am 28.11.2009

Anne hat mich darauf aufmerksam gemacht, dass beim MS IE in vielen Fällen auch der unauffällige Einbau eines kleinen Dummy-Flash-Films, der eigentlich nichts tut, zur Stabilisierung des Bildaufbaus und zur Vermeidung von Flackereffekten hilft. Wegen evtl. Schwierigkeiten mit Flash-Filmen in Gecko/Mozilla-Browsern ist das aber kein Trick, den man generalisieren könnte.

Interessant ist auch, dass im Moment das
gleichzeitige Öffnen mehrer Tabs mit Webseiten, die per SWFObjects 2.x eingebaute Flashfilme beinhalten, im Firefox zu Flackereffekten beim Seitenwechsel führt – zumindest unter Linux.  Es ist ein Leiden !

Ferner hat mich Anne mit einigen Beispielen, bei denen im BODY-Tag Hintergrundsbilder per CSS verankert wurden, davon überzeugt, dass es im MS IE (alle Versionen) manchmal sogar von Nachteil sein kann, den “revealtrans”-Effekt einzusetzen. Besser ist es da anscheinend, das Bild, das man im Body-Tag untergebracht hat, nochmal in Form eines gewöhnlichen IMG-Tags in einem DIV zu hinterlegen, das man per z-index unter allen anderen Seitenelementen einfügt.

OK, OK, ich gebe auf – es gibt keine Standardrezepte – man muss halt herumexperimentieren.

Wenn man Zeit hätte, könnte man ja die Sache mal systematisch untersuchen – Seitenwechsel bei vorhandenen Hintergrundsbildern, beim Vorhandensein  von Flash und das in allen gängigen Browsern unter Linux und  MS Windows.  Ach ja, man müßte dann auch noch die unterschiedlichen Arten der Einbindung von Flashfilmen berücksichtigen …..

samba – unix extensions bug?

Vor kurzem habe ich ca. 2 Stunden damit verbracht, mich mit einem vermutlichen Fehler in der Samba-Server-Version 3.2.7 unter Kernel 2.6.27 herumzuschlagen. (Die Kernelversion galt sowohl für den betroffenen Server wie auch die Linux-Clients).

Der Fehler bestand darin, dass “force create mode” und “force directory mode” Einstellungen des Samba-Servers ignoriert wurden, wenn User von unseren Linux-Clients aus Dateien/Verzeichnisse im Share anlegen wollten. Das hatte bei uns in der Praxis insofern Folgen, als die reibungslose Arbeit in der Gruppe u.a. von den Rechten der erzeugten Dateien abhing.

Die “force…”-Einstellungen waren gerade deshalb gesetzt worden, damit weder Windows- noch Linux-User der Samba-Shares über die Rechte-Einstellungen nachdenken mussten.

Das Problem im Detail und die Bedeutung der “unix extensions”

Ich habe für einen Share auf einem Samba-Server folgende Einstellungen vorgegeben:

[aux]

comment = aux
inherit acls = Yes
path = /samba/ann_aux
read only = No
create mask = 0664
force create mode = 0664
force user = myuser

Dieser Share wird in unserem Netz – wie gesagt – nicht nur von Win-XP Clients (natürlich in einer virtuellen Umgebung unter Linux) aus benutzt, sondern auch von Anwendern auf reinen Linux-Systemen. Dabei stellten wir dann fest, dass für einen berechtigten Linux-User zwar die “force user”-Vorgabe ausgeführt wurde, die Dateirechte jedoch immer auf “rw-,r–,r–“ gesetzt wurden, statt wie erwartet (“OR” – Kombination der Berechtigungs-Bits!) auf “rw-,rw-,r–“.

Der Rechtekamm “rw-,r–,r–“ entsprach nicht den “force create mode”-Einstellungen des Servers, sondern vielmehr den umask-Einstellungen für den betreffenden User auf dem Linux-Client.

Dagegen funktionierten die obigen Einstellungen auf einem deutlich älteren Samba-Server für ein anderes Share. Was also war der Unterschied zwischen den Servern? Nach einigem Suchen im Internet und Vergleichen kam ich dann dahinter, dass die Option “unix extensions” auf dem neueren Server gesetzt ist – defaultmäßig auf “yes”.

Dieser Parameter steuert für CIFS Shares die Anzeige und Nutzung von Linux-Rechten im Zusammenspiel zwischen Samba-Servern und Linux/Unix-Clients. Ich zitiere von “http://wiki.ubuntuusers.de/Samba_Server/smb.conf” :

CIFS Unix Extensionsunix extensions = yes

Dieser Parameter ermöglicht durch z.B. Samba Client/cifs auch auf dem Client die Original Dateirechte und Zeitstempel zu sehen und zu verwenden. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions deaktiviert werden.
Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Dieser Parameter ermöglicht durch z.B. Samba Client/cifs auch auf dem Client die Original Dateirechte und Zeitstempel zu sehen und zu verwenden. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions deaktiviert werden.
Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Weiter findet man unter “http://wiki.ubuntuusers.de/Samba_Client_cifs” folgende Ausführungen

Sind die CIFS-UNIX-Erweiterungen aktiv (auf dem Samba-Server: unix extensions = yes, Standard), so werden die echten Besitz- und
Zugriffsrechte zwischen Server und Client übertragen. Ändert man auf dem Client mittels chmod oder chown oder über den Eigenschaften-Dialog der GUI die Rechte, ist die Änderung ebenso auch auf dem Server und auf allen anderen Clients wirksam, die auf die Freigabe zugreifen.
Die Angaben in der Datei /etc/samba/smb.conf auf dem Server legen dabei den Rahmen fest, in dem Zugriffsrechte auf dem Client Gültigkeit haben. Ist z.B. eine Freigabe in smb.conf nur zum Lesen freigegeben, können für sie von keinem Client aus Schreibrechte festgelegt werden. Ist sie aber in smb.conf auch für Schreibzugriffe freigegeben, kann sie von jedem Client aus mittels chmod für “nur lesen” eingeschränkt werden. Ebenso können Freigaben, die auf dem Server den Status “nur lesen” haben, aber in smb.conf mit Schreibrechten eingetragen sind, vom Client aus mit Schreibrechten versehen werden.
Die UNIX-Erweiterungen haben Vorrang vor anderen Angaben für Besitz- und Zugriffsrechte. Sollten in der Mount-Befehlszeile oder im Eintrag in /etc/fstab solche Angaben vorhanden sein, so werden diese bei aktiven UNIX-Erweiterungen ignoriert.

Unter “http://us1.samba.org/samba/docs/man/manpages-3/smb.conf.5.html” liest man

unix extensions (G)
This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features such as symbolic links, hard links, etc… These extensions require a similarly enabled client, and are of no current use to Windows clients.
Default: unix extensions = yes

Für Interessierte erwähne ich auch noch, dass auf dem Linux-Client beim Mounten eines CIFS-Shares auch ein Kernel-Parameter zur Nutzung der “unix extensions” gesetzt wird (bzw. gesetzt werden kann). Man werfe dazu nach dem Mounten des Samba-Shares einen Blick in das Verzeichnis “/proc/fs/cifs” und dort in die Datei “/proc/fs/cifs/LinuxExtensionsEnabled”. Ein

echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled

schaltet auf dem Client die Nutzung der vom Samba-Server angebotenen Unix-Extensions ab.

Soviel zur Theorie. Tatsächlich funktionieren die “Unix extensions” im Prinzip auch so wie vorgesehen – wenn man mal das “force create mode” außer Acht läßt :

  • Die User- und Gruppenrechte auf dem Samba-Server werden auf dem Linux-Client korrekt angezeigt. (Natürlich müssen auf dem Server und dem Client die gleichen UIDs und GIDs gesetzt sein wie auf dem Linux-Client!).
  • Jede Rechteänderung auf dem Linux-Client wird auf den Server übertragen.
  • Auch von MS Win-Clients aus funktioniert alles so wie vorgesehen – sogar das “force create mode” wird hier richtig ausgeführt.

Mein Problem besteht/bestand also darin, dass bei aktivierten “unix extensions” auf dem Samba-Server das gesetzte “force create mode” ignoriert wird, wenn man Dateien des Shares über einen Linux-Client anlegt. Das hätte ich schon aus Konsistenzgründen zu älteren Versionen des Samba-Servers nicht unbedingt so erwartet.

Die (vorrübergehende) Lösung

Probeweise habe ich den Samba-Server-Parameter “unix extensions” dann auf “no” gesetzt.

Danach wurden die Rechte von Files, die von Linux-Clients neu erzeugt wurden, tatsächlich wieder “korrekt” – d.h. gemäß der “force create mode”-Vorgaben – gesetzt. (Das Gleiche funktioniert natürlich auch, wenn man die entsprechenden Paramter für den Rechtemodus von Verzeichnissen benutzt.)

Blöd ist nur, dass die gewünschten und korrekt gesetzten User- und Gruppen-Rechte der Dateien auf dem Samba-Server nun natürlich nicht mehr auf den Linux-Clients angezeigt werden. Das war ja eigentlich der Sinn der “unix
extensions”. Aber damit kann man leben, wenn einem das Erzwingen von Rechten wirklich wichtig ist.

Eine Philosophie-Frage oder ein Bug ?

Nach diesen Erkenntnissen fragt man sich nun: Ist das eigentlich ein Bug ? Ich habe dazu zumindest einen Hinweis im Internet gefunden:

http://www.mail-archive.com/samba@lists.samba.org/msg99935.html und
http://www.mail-archive.com/samba@lists.samba.org/msg99936.html.

Natürlich könnte man aber auch wie folgt argumentieren: Wenn jemand die “unix extensions” benutzt, dann deshalb, weil man die Rechte auf dem Linux/Unix-Client selbst manipulieren will und soll. Irgendwie ist das ja der Kern der Sache. Also darf der User nicht voraussetzen, dass der Server die Rechtepolitik schon regeln wird. In meinem Fall hatte ich das auf Grund meiner Kenntnis des “force create mode”-Parameters explizit angenommen.

Andererseits:

Welche Chance hat ein Samba-Admin denn, wenn er trotz globalem “unix extensions” für bestimmte Shares auch für die User auf Linux-Clients vorgegebene Rechtekämme erzwingen will oder muss ? Lokal kann er ja für das betroffene Share die “unix extensions” nicht außer Kraft setzen – er muss auf dem Server also “force create mode” verwenden ! Aber das wird dann leider ignoriert !

Letztere Argumentation führt mich zu der Meinung, dass hier tatsächlich ein Bug vorliegt. Deshalb meine Aufforderung an die Samba- und Kernel-Profis: Bitte ändern – falls noch nicht geschehen !

 

Unison – Synchronisation mit GUI

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

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/