1.10.2009 von rmo.

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 !

Geschrieben in Netzwerk, Erfahrungsberichte | Keine Kommentare »

17.9.2009 von rmo.

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 !

Geschrieben in Netzwerk, Erfahrungsberichte | Keine Kommentare »

1.12.2008 von rmo.

Beim Web-Entwickeln stößt man ab und zu auf das Problem, dass man zum Testen auf seinem Apache2-Webserver schnell mal zwei separate Domainen benötigt, um typische Situation bei Web-Providern nachzustellen:

Auf den gehosteten Servern findet man regelmäßig Verhältnisse vor, bei denen einem in einer abgekapselten “chroot”-Umgebung zwei oder mehr Verzeichnisse bereitgestellt werden, denen dann unterschiedliche Domainen zugeordnet sid oder zugeordnet werden können. Und als Entwickler möchte man gerne domainenübergreifende PHP-Klassenbibliotheken in Verzeichnissen außerhalb der eigentlichen Domainen installieren und testen, ob die Klassen auch ordentlich in allen Domainen gezogen werden …. oder man hat mit ähnlichen domainübergreifenden Problemstellungen zu tun …..(Dass man Bibliotheken in domainunabhängigen, übergeordneten Verzeichnissen des Webservers installiert, hat seinen Grund übrigens nicht nur in der Vermeidung von Doppelpflege, sondern es dient u.U. auch der Sicherheit.)

Möchte man ähnliche Situationen auf einem eigenen Apache-Server nachstellen, greift man am besten - wie der Webprovider auch - zu namensbasierten virtuellen Domainen.
Das folgende einfache Beispiel zeigt, wie man zwei solcher zusätzlicher Domainen auf einem Opensuse-System einrichten kann und wie man dafür sorgt, dass der ursprüngliche Zugriff auf den Server erhalten bleibt. Wir gehen von folgendem Szenario aus: Es laufe ein Webserver unter der beispielhaften Adresse “server.mydomain.de”. Ihm sei die IP-Adresse “192.168.0.10″ zugeordnet. Die DNS-Einstellungen im Netzwerk seien so, dass man den Webserver unter “http://server.mydomain.de” oder “http.//server” erreicht. Der Web-Server selbst sei im Moment so eingerichtet, dass in der Haupt-Konfigurations-Datei

/etc/apache2/http.conf

über eine inkludierte Datei die erforderlichen Port- und SSL-Einstellungen des Webservers vorgegeben werden. Das entsprechende Include-Statement in der httpd.conf findet sich meist an deren Anfang

Include /etc/apache2/listen.conf

Später werde auch die Default-Konfiguration des Servers über eine weitere Konfigurationsdatei (globale Einstellungen für den Defaultserver) in die “httpd.conf” geladen. Dies geschieht z.B. über den Eintrag

Include /etc/apache2/default-server.conf

Ein nachfolgender Eintrag in der httpd.conf sorge dafür, dass Definitionen für virtuelle Domainen aus dem Verzeichnis “/etc/apache2/vhosts.d” geladen werden, sobald wir (s.u.) solche Definitionen angelegt haben:

Include /etc/apache2/vhosts.d/*.conf

Auf andere Einträge in der Datei “httpd.conf” gehen wir im Moment nicht ein, da sie hier nicht von direkter Bedeutung sind.
Folgende Einträge in der “default-server.conf” sorgen vor der Umstellung auf virtuelle Domainen für den reibungslosen Betrieb.

DocumentRoot “/srv/www/htdocs”
<Directory “/srv/www/htdocs”>
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>

Alias /icons/ “/usr/share/apache2/icons/”

<Directory “/usr/share/apache2/icons”>
     Options Indexes MultiViews
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>
ScriptAlias /cgi-bin/ “/srv/www/cgi-bin/”
<Directory “/srv/www/cgi-bin”>
     AllowOverride None
     Options +ExecCGI -Includes
     Order allow,deny
     Allow from all
</Directory>
<IfModule mod_userdir.c>
     UserDir public_html
     Include /etc/apache2/mod_userdir.conf
</IfModule>
Include /etc/apache2/conf.d/*.conf
Include /etc/apache2/conf.d/apache2-manual?conf

Diese Einstellungen können später pro virtueller Domaine überschrieben werden. Das Apache2-Konzept ist hier sehr modular.

Einrichtung der virtuellen Domainen
Nun richten wir uns 3 virtuelle Domainen ein. Zwei davon werden zwei speziellen Verzeichnissen zugeordnet; die dritte ersetzt den bisherigen “Default-Server”. Die dritte virtuelle Default-Domaine ist deshalb wichtig und notwendig,

• weil bei einem “namebased virtual server” zunächst keine Default-Domaine existiert und der Standard-Default-Server keine Wirkung mehr hat und
• weil man die bisherigen User des Servers nicht dazu zwingen will, ihre Lesezeichen in Ihren Browsern grundlegend zu ändern.

Diese dritte Domaine darf in einer professionell genutzten Umgebung bei der Umstellung nicht vergessen werden.

Für die Umstellung ist zunächst ein Eintrag in der Datei “/etc/apache2/listen.conf” essentiell:

NameVirtualHost 192.168.0.10:80

Nachdem wir das erledigt haben, erstellen wir im Verzeichnis “/etc/apache2/vhosts.d” eine Datei “virtu.conf” für eine virtuelle Domaine “virtu.mydomain.de” mit folgendem Inhalt :

<VirtualHost 192.168.0.10:80>
     ServerAdmin your_admin_name@mydomain.de
     ServerName virtu.mydomain.de
     ServerAlias virtu
     DocumentRoot /srv/www/vitualdomains/virtu
     HostnameLookups Off
     UseCanonicalName Off
     ServerSignature On
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/virtualdomains/virtu”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Beachten Sie den Eintrag zum “DirectoryIndex” und “ServerAlias”. Letzterer macht die neue Domaine auch über eine Abkürzung (http://virtu) anstelle des voll qualifizierten Domainnamens ansprechbar. Der “DirectoryIndex” spezifiziert, welche Dateien aufgerufen werden sollen, wenn als Http-Adresse nur die Domaine (also das Verzeichnis) angesprochen wird. Diese Vorgabe gilt aber auch für Subverzeichnisse. Einträge aus der Datei “default-server.conf” bleiben weiterhin gültig, soweit sie nicht überschrieben wurden. Eine weitere Domaine kann etwas so aussehen:

<VirtualHost 192.168.0.10:80>
     ServerAdmin your_admin_name@mydomain.de
     ServerName virtual.mydomain.de
     ServerAlias virtual
     DocumentRoot /srv/www/vitualdomains/virtual
     HostnameLookups Off
     UseCanonicalName Off
     ServerSignature On
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/virtualdomains/virtual”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Abschließend möchten wir noch den Server mit einer Default-Domaine ausstatten, die für alle sonstigen Zwecke aufgerufen wird, und die der ursprünglichen Serverkonfiguration entspricht:

<VirtualHost 192.168.0.10:80>
     DocumentRoot /srv/www/htdocs
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/htdocs”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Man erkennt, dass hier der “ServerName”-Eintrag fehlt !
Bleibt nur noch, auf unserem DNS-Server (oder auf dem Client-Rechner in der “/etc/hosts”-Datei) dafür zu sorgen, dass “virtu.mydomain.de” und “virtual.mydomain.de” im Netzwerk auch unter der Adresse “192.168.0.10″ gefunden werden. Danach können wir den Webserver neu starten und erreichen in einem Browser über “http://virtu.mydomain.de” bzw. “http://virtual.mydomain.de” die neuen Domainen. Rufen wir nur “server.mydomain.de” oder “http://192.168.0.10″ auf, so erhalten wir diejenigen Seiten, die auch auf dem urssprünglichen Server schon angezeigt wurden.
Viel Spaß mit den neuen Domainen!
Wenn es funktioniert, dann ist es an der Zeit, sich mit weiteren Varianten und Möglichkeiten von virtuellen Domainen auf einem Apache-Server auseinanderzusetzen. Das obige Beispiel war nur eine sehr einfache Lösung zu fester IP-Adresse und einheitlichem Port.

Geschrieben in Netzwerk, LAMP / Webentwicklung, Erfahrungsberichte | Keine Kommentare »