Infos

Sie befinden sich in den Archiven der Kategorie LAMP / Webentwicklung.

Calendar
Mai 2012
M D M D F S S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

Archiv der Kategorie LAMP / Webentwicklung

Vererbung von ext3-/ext4-Gruppenrechten

Immer mal wieder fragt mich jemand, was er tun muss, damit Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden.

Problemstellung

Das Problem der Vererbung von GIDs und Gruppenrechten tritt z.B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen. Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das “chmod”-Kommando vornehmen müsste.

Offenbar ist das Thema weniger trivial, als man meinen möchte. Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen. Das stimmt so leider nicht - und so mancher beginnt dann mit

“chgrp -R”     und     “chmod -R”

zu experimentieren. Was auch nicht hilft, weil das nur einmalige - wenn auch rekursive - Änderungen im betroffenen Zweig des Dateibaums herbeiführt. Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten.

Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen. Wir wollen hier aber eine native Lösung für beschreiben.

Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit.

Vorgehen

Wir nehmen zwei User eines Systems - “alpha” (uid 1001; dieser User wird der Entwicklunsgleiter) und “beta” (uid 1002). Beide seine Mitglieder der Gruppe “users” (gid 100). umask habe den Standardwert

umask 022

Was ist nun zu tun?

Schritt 1: Anlegen einer gemeinsamen Usergruppe
Als root: Anlegen einer neuen Gruppe “entwickler” (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z.B. mit Hilfe von Yast; ansonsten mit “groupadd” und “usermod -A” - siehe die man-Seiten).

Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind
Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option “acl” gemounted wird. In der Datei “/etc/fstab” sollte sich dafür ein Eintrag der Form

/dev/myFileSystem     /myMountPoint     ext4     acl,user_xattr     1 2

finden. “myFileSystem” steht hier für das betroffene Filesystem. “/myMountPoint” steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird. Entscheidend ist die Option “acl”.

Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit
Als root oder Entwicklungsleiter “alpha”: Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung
chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-Bits
Als Entwicklungsleiter “alpha”:

chmod   g+s     /myMountPoint/Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses “/myMountPoint/Entwicklung” angelegt werden, die die Gruppenzugehörigkeit zur Gruppe “entwicklung”.

Schritt 5: Setzen der ACL-Maske
Als Entwicklungsleiter “alpha”:

cd  /myMountPoint

setfacl -m     m::rwx     Entwicklung

Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis “Entwicklung”.

Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse
Als Entwicklungsleiter “alpha”:

cd   /myMountPoint

setfacl -dm     g:entwicklung:rwx     Entwicklung

Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse
Als Gruppenmitglied “beta”:

cd   /myMountPoint/Entwicklung

touch   test
ls -l
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul 20:18     test

mkdir   testdir
ls -l
drwxrwsr-x+ 2     beta     entwicklung     4096     20. Jul     21:20     testdir

touch   testdir/test2
ls -l   testdir
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul     21:22     test2

Viel Spaß nun beim Arbeiten in der Gruppe !

Links
http://wiki.ubuntuusers.de/chmod#SGID-Bit
http://wiki.ubuntuusers.de/ACL#Verzeichnisse

Flackern beim Seitenwechsel im MS IE - Nachtrag

In einem der letzten Blog-Beiträge ging es um das Flackern des MS IE beim Seitenwechsel. Dort hatte ich zwei Tricks aufgeführt, mit denen man ohne Serveränderungen in manchen Fällen - leider nicht immer - eine Verbesserung herbeiführen kann.

In diesem Beitrag möchte ich kurz auf die Behandlung von MS IE-Flackern bei der Integration von Hintergrundsbildern für die gesamte Webseite eingehen. Da gibt es eine Geschichte, die es sehr verständlich macht, warum viele Webseiten-Entwickler den MS IE verfluchen.

Also - wie lädt man typischerweise Hintergrundsbilder für die gesamte HTML-Seite? Im -Tag per css-Anweisung. Typischerweise haben dann viele Seiten einer Domain dasselbe Hintergrundsbild und einen im wesentlichen gleichen Aufbau - es ändern sich beim Seitenwechsel nur ganz bestimmte BEreiche der Seite. Dann will man natürlich, dass ein Seitenwechsel sanft vor sich geht und der Hintergrund nicht flackert. Das Hintergrundsbild und alle anderen unveränderten Seitenelemente sollen beim Seitenwechsel statisch angezeigt, nicht neu aufgebaut oder neu geladen werden. Wozu gibt es schließlich den Browser-Cache …

Leider wird man aber beim MS IE in Abhängigkeit von der MS IE-Version feststellen, dass es dort bei Seitenwechseln, bei denen sich das Hintergrundsbild und wesentliche Anteile der Webseite (Grundaufbau) nicht ändern, dennoch zu Flackern kommt. Der Hintergrund wird kurz weiß, das Bild wird neu geladen. Das passiert ggf. nicht immer aber, doch sehr häufig. Wenn man genauer forscht, wird man feststellen, dass das Flackern besonders häufig oder immer bei Seiten auftaucht, bei denen zusätzlich zu den Hintergrundsbildern Flash-Elementen oder Javascript-Anteile vorkommen.

Deshalb sind ggf. zwei Tricks zu kombinieren, um das Flackern weg zu bekommen:

Fall 1) Es wird kein Javascript in der Webseite benutzt

Dann hilft es, das Hintergrundsbild nochmals (also zusätzlich zum Hintergrund im <BODY>) in einem DIV zu laden, das man per z-Index unter den gesamten übrigen Inhalt der Webseite legt. Hierzu benötigt man natürlich einen übergeordneten DIV-Container, in dem man das DIV für das Hintergrundsbild und ein DIV für den gesamten übrigen Inhalt absolut positioniert und übereinander legt.

Fall 2) Es wird Javascript benutzt, z.B. um Flash-Objekte in die Seite zu integrieren

Wir verwenden z.B. SWFObject und entsprechendes Javascript, um Flash zu integrieren. Es hat mich viele Tests gekostet, bis ich herausfand, dass allein schon das Einfügen eines Tags

<script type=”text/javascript”></script>

(also ohne jeden Code !) oder gar eines Tags

<script language=”JavaScript” src=”script/swfobject2.js” type=”text/JavaScript”></script>

im Header der HTML-Datei bereits ein Flackern beim Seitenwechsel zwischen Seiten mit Hintergrundsbildern auslöst. Für den Bruchteil einer Sekunde wird der Hintergrund weiß, das Bild wird neu geladen. Selbst wenn in der HTML-Seite keinerlei Javascript-Code ausgeführt wird. Unglaublich nicht ? Noch unglaublicher ist aber der Trick, der beim MS IE hilft:

Man kopiere den gesamten Script-Kram, soweit es die Logik der Seite zulässt, an das Ende des HTML-Codes und zwar unmittelbar vor das Ende des abschließenden </BODY>-Tags. Das ist zwar ungewöhnlich, aber kein Browser meckert einen formalen Fehler an. Und siehe da, auf einmal hört auch im MS IE das Flackern auf.

Das läßt tief blicken, in welcher Weise die Javascript-Engine in den MS IE integriert ist - Entschuldigung bei MS ist das ja eh eine Extrawurscht und nix Normales (JSCRIPT).

Leider kann es in einigen Fällen so sein, dass Javascript-Code zwingend vor dem Laden der übrigen HTML-Elemente ausgeführt werden muss. Dafür habe ich auch keine echte Lösung parat. Aber in vielen Fällen hilft der beschriebene Trick.

Überflüssig anzumerken, dass man den ganzen Quatsch so nicht braucht , wenn man Firefox benutzt. Gott sei Dank hat ja nun Firefox zumindest in Deutschland dem MS IE den Rang abgelaufen.

Reihenfolge relativ und absolut positionierter DIVs

Anne kam vor kurzem mit einem typischen Problem im Zusammenhang mit der Positionierung von relativ und absolut positionierten DIVs in einem Container-DIV.

Fast wie immer klappte alles im Firefox oder in Opera unter Linux (und Windows) - nur nicht im MS IE (7,8).

Worum ging es?

Das Container-DIV hatte nur die Aufgabe,  einen definierten Bereich innerhalb der Webseite vorzugeben und bei Bedarf Scrollbedarf zuzuschalten. Das DIV war in seiner Umgebung relativ positioniert.

Innerhalb des Containers hatte Anne eine Reihe aufeinanderfolgender, relativ positionierter  DIVs undefinierter Höhe.  Die Elemente der DIVs wurden durch Datenbankinhalte gefüllt. Insgesamt ergaben die relativ positionierten DIVs  einen Hintergrundsbereich innerhalb des Containers. Alle befanden sich in der gleichen Ebene, die durch eine z-Index festgelegt wurden.

Zusätzlich gab es ein weiteres DIV, das absolut positioniert wurde und für das ein höherer Wert im z-Index gewählt wurde. Dieses DIV sollte also immer vor den relativ positionierten DIVs angezeigt werden.

Also:

<div id=”container” …. >
 
<!– das absolut positionierte DIV –>
<div id=”abs” style=”position:absolute; …. z-index:10; “>
…..
</div>
 
<!– die relativ positionierten DIVs –>
<div id= “rel_1 ” style= “…; z_index:1; ” ….. > …. </div>
<div id= “rel_2 ” style= “…; z_index:1; ” ….. > ….  </div>
…..
…..
   
</div>

Im Firefox wurde das abslout positionierte DIV auch brav über allen anderen DIVs angezeigt; im MS IE7 dagegen nicht und im MS IE 8 nur, wenn der Seitenaufruf mit geänderten PHP-Parametern geschah. Ein reiner Seiten-Refresh führte immer zu einem Ausblenden des absolut positionierten DIVs.

Die Lösung 

Was hatte Anne falsch gemacht ? Aus meiner Sicht gar nichts. Außer, dass sie hätte davon ausgehen müssen, dass der MS IE ein wenig Hilfe benötigt:

Der MS IE kriegt die obige Reihenfolge nämlich nicht auf die Reihe - im wahrsten Sinne des Wortes !

Hätte Anne die Reihenfolge von vornherein wie folgt gewählt, wäre nichts passiert:

<div id=”container” …. >
 
<!– die relativ positionierten DIVs –>
<div id=”rel_1″ style=”…; z_index:1;” ….. > ….  </div>
<div id=”rel_2″ style=”…; z_index:1;” …..> ….  </div>
…..
…..
 
<!– das absolut positionierte DIV –>

<div id=”abs” style=”position:absolute; …. z-index:10; “>
…..
</div>
 
</div>

Merke:

Im MS IE ist es zwingen, die relativ positionierten DIVs vor den absolut definierten DIVs zu definieren. Sonst bekommt der MS IE den Ebenenaufbau nicht hin.

Arme Web-Designer ! Das ist kein Spass mit dem MS IE.