Beschreibung: Prüfungskandidaten sollten wissen, wie man im Netzwerk freigegebene Dateisysteme mittels NFS einbindet, wie man NFS für den Export lokaler Dateisysteme konfiguriert und wie man den NFS-Server startet, anhält und neustartet. Ebenfalls enthalten ist die Installation und Konfiguration von Samba unter Verwendung des mitgelieferten GUI-Tools oder durch direkte Bearbeitung von /etc/smb.conf (Achtung: Bewußt ausgeschlossen sind fortgeschrittene Themen der NT-Domänen; einfaches Freigeben von Verzeichnissen und Druckern sowie das korrekte Einrichten von nmbd als WINS-Client sind jedoch enthalten).
Die wichtigsten Dateien, Bezeichnungen und Anwendungen:
Es gibt prinzipiell zwei grundlegende Techniken der Freigabe. Entweder ist ein Verzeichnis über das Network File System (NFS) freigegeben, oder über das Server Message Block Protokoll (SMB). NFS ist in der Regel von Unix/Linux Maschinen angeboten, SMB ist die Technik der Windows-Freigaben.
mount -t nfs hal:/usr/public /mnt
eingegeben. Normalerweise kann die Angabe des Dateisystemtyps (-t
nfs) auch weggelassen werden, da der mount-Befehl aus der
Struktur der Pfadangabe erkennt, daß es sich um NFS handeln muß.
Dieser Prozess kann natürlich auch automatisiert werden, damit das Verzeichnis bei jedem Start des Rechners wieder gemountet wird. Dazu muß wie bei lokalen Partitionen ein Eintrag in die Datei /etc/fstab gemacht werden. Unsere Beispielfreigabe würde folgenden Eintrag benötigen:
hal:/usr/public /mnt nfs defaults 0 0Dabei ist allerdings darauf zu achten, daß der Fileserver (in diesem Fall hal) schon läuft, bevor der Computer gestartet wird, dessen /etc/fstab diese Zeile enthält. Sonst versucht der Rechner das Verzeichnis von hal zu mounten und es kann eine ganze Weile dauern, bis der Timeout dafür sorgt, daß der Bootvorgang weitergeht.
Um eine SMB-Freigabe einzuhängen, wird entweder der spezielle Befehl smbmount benutzt, oder der normale mount-Befehl, zusammen mit dem Dateisystemtyp smbfs. Um also die Windows-Freigabe mit dem Freigabenamen public des Rechners winserver1 ins lokale Verzeichnis /mnt zu mounten, kann einer der beiden folgenden Befehle verwendet werden:
mount -t smbfs //winserver1/public /mnt smbmount //winserver1/public /mntAllerdings wird auf diese Weise immer nach einem Passwort gefragt, selbst wenn das Verzeichnis auf dem Windows-Rechner ohne Passwort freigegeben wurde. Mit den folgenden Optionen kann mit diesen Passwörtern umgegangen werden:
Diese Optionen werden dem mount-Befehl zusammen mit dem Schalter -o angegeben, also etwa
mount -t smbfs -o guest //winserver1/public /mntDer smbmount Befehl hängt diese Optionen - auch durch -o eingeleitet an den Befehl hinten an:
smbmount //winserver1/public /mnt -o guestUm den Prozeß zu automatisieren, wird wiederum ein Eintrag in die Datei /etc/fstab gemacht, der unbedingt als Option entweder guest oder Username und Passwort benötigt.
//winserver1/public /mnt smbfs defaults,guest 0 0Wenn die Windows-Freigabe die Angabe eines Usernamens und Passwortes erwartet, so könnten hier natürlich auch die Optionen username=... und password=... angegeben werden. Das ist aber keine gute Idee, denn die Datei /etc/fstab ist von allen Usern lesbar. Aus diesem Grund gibt es die Möglichkeit, hier einen Dateinamen anzugeben, mit der Option credentials=Dateiname. Die angegebene Datei kann dann Einträge der Form
username = Wert password = Wertenthalten. Diese Datei wird nicht von aller Welt lesbar sein, also sind die Passwörter sicher.
Technisch gesehen baut das Network-File-System auf einer Entwicklung auf, die Remote Procedure Call (RPC) genannt wird. Dieser "entfernte Prozeduraufruf" nutzt die Portnummern oberhalb 10000 um es zu ermöglichen, Client-Server Software zu steuern. Der Server stellt bestimmte Prozeduren zur Verfügung, die jeweils einer bestimmten Portnummer zugeordnet sind. Ein Client im Netz kann nun diese Prozeduren aufrufen, es entsteht eine Art gemischtes Programm, ein Teil läuft auf dem Client ab, ein anderer Teil auf dem Server.
Die Zuweisung der Ports für das RPC-System übernimmt der portmapper, ein Programm, das immer laufen muß, wenn ein Rechner RPC-Service anbieten will.
Die oben genannte Aufteilung macht sich NFS zu Nutzen, indem dieses System Prozeduren zur Verfügung stellt, die sich auf den Zugriff auf Dateisysteme beziehen. Diese Prozeduren werden jetzt vom NFS-Client aufgerufen, um Zugriff auf ein Dateisystem zu bekommen.
Die folgenden Voraussetzungen müssen erfüllt sein, um Verzeichnisse mit NFS freizugeben:
Ein Beispiel:
Auf dem Rechner hal existieren die User:
Username UID root 0 peter 501 hans 502Der Rechner hal exportiert sein /usr Verzeichnis jetzt an alle anderen Rechner im Netz. Dabei bleiben natürlich die Zugriffsrechte erhalten. Doch die exportierten Dateien
-rw-r----- root root geheim.txt -rw------- peter user noch_geheimer.txtwerden eben nicht nach Usernamen (root, peter) verwaltet sondern nach ihren User IDs also 0 und 501.
Der Rechner marvin will das freigegebene Verzeichnis von hal jetzt mounten. marvin hat jedoch andere User:
Username UID root 0 otto 501 hugo 502Die oben genannten UserIDs sind also auch auf marvin vergeben, was dazu führt, daß marvin jetzt mit den neuen Namen arbeitet, nicht nur mit den Namen sondern eben auch mit den Rechten dieser User. Die gemounteten Dateien sähen jetzt also so aus:
-rw-r----- root root geheim.txt -rw------- otto user noch_geheimer.txtDie ganze Sache hätte zur Folge, daß otto plötzlich Dateien lesen und beschreiben kann, die eigentlich peter gehören und für alle anderen unlesbar sein sollten.
In den Fällen, in denen diese Erscheinung unvermeidbar ist (weil es z.B. nicht möglich ist, alle User überall gleich zu nummerieren) kann ein Mechanismus angewandt werden, der etwas genauere Betrachtung verdient, das Squashing.
Diese Technik wird vorwiegend bei root-Zugängen angewandt; root hat immer die UserID 0 egal ob es sich um die selbe Person handelt oder nicht. Also kann dafür gesorgt werden, daß sich der root-Zugriff auf ein gemountetes Dateisystem in eine andere UserID verwandelt. NFS versucht es zunächst mit dem Usernamen nobody, wenn es den nicht gibt, so weist es dem zugreifenden root die UID und GID -2 zu. Man spricht hier von der anonymen UserID.
Manchmal ist es auch erwünscht, anderen Usern ebenfalls die anonyme UserID zuzuweisen, NFS bietet die Möglichkeit diese Zuweisung zu übernehmen.
Die Datei hat eine einfache Form, zeilenweise werden die einzelnen Verzeichnisse angegeben und mit Zugriffsbestimmungen versehen. Dabei sind Wildcards möglich um möglichst flexibel in der Unterscheidung zu sein, wer was mounten darf.
In Klammern können noch Optionen gesetzt werden, die die Zugriffsrechte betreffen (Read only ...) oder die das Squashing (siehe oben) steuern. Am Besten sehen wir uns das einmal an einem Beispiel (der Handbuchseite entnomme) an:
# Beispielhafte /etc/exports Datei / master(rw) trusty(rw,no_root_squash) /projects proj*.mydomain.de(rw) /usr *.mydomain.de(ro) /home/joey pc007(rw,all_squash,anonuid=501,anongid=100) /pub (ro,all_squash)Der erste Eintrag bestimmt zwei Rechner (master und trusty) die das ganze Wurzeldateisystem mounten dürfen. Das rw in Klammern besagt, daß sie auch schreibenden Zugriff haben. Standardmäßig ist vorgegeben, daß der root-account über Squashing auf die Anonyme UID gelegt wird. Mit der Option no_root_squash wird dieses Squashing ausgeschaltet. Der Systemverwalter von trusty hat also tatsächlich auf dem gemounteten Dateisystem Rootrechte.
Der nächste Eintrag beschreibt die Möglichkeit aller Rechner, deren Namen mit proj beginnen und auf .mydomain.de enden, das Verzeichnis /projects zu mounten. Schreibender Zugriff ist möglich.
Das Verzeichnis /usr wird in der dritten Zeile für alle Rechner der Domain mydomain.de freigegeben. Es kann aber nur Read-Only gemountet werden, Veränderungen sind also nicht möglich.
Die nächste Zeile beschreibt den Rechner pc007, der das Verzeichis /home/joey mounten darf. Es handelt sich um einen typischen Eintrag für PCs, alle User werden gesquasht, als Anonyme UID wird 501 angenommen, als GID 100.
Das letzte Beispiel zeigt einen Eintrag, der von der ganzen Welt (sofern sie Zugriff auf unser Netz hat) benutzt werden kann und das Verzeichnis /pub als Read-Only freigibt. Alle UserIDs werden auf die Anonyme UID (nobody) gesetzt.
Eine genaue Möglichkeit zu bestimmen, welche UserIDs auf die anonyme abgebildet werden sollen, gibt es auch noch. Die Optionen squash_uids und squash_gids ermöglichen eine genaue Angabe, welche UIDs und GIDs verwandelt werden sollen. Eine gültige Angabe kann so aussehen:
... (squash_uids=0-15,20,25-50)Jedesmal, wenn Einträge in der Datei /etc/exports verändert werden, muß den beiden Daemonen rpc.mountd und rpc.nfsd ein HUP-Signal geschickt werden, um sie zu zwingen, diese Datei neu einzulesen.
Statt einem HUP-Signal kann auch der Befehl exportfs -a eingegeben werden, der die Daemonen zwingt, die Datei neu einzulesen.
Damit Linux als Server für Windows-Systeme eingesetzt werden kann, ist es nötig, daß ein Serverprogramm installiert wird, das die Netzwerktechnik von Windows zur Verfügung stellt. Die Protokollfamilie, mit der Windows-Netze ihre Datei- und Druckerdienste verwalten, heißt SMB (Server Message Block) und wird von allen Windows-Systemen (von Win 3.11 bis Win 2000/XP) verwendet. Die Implementierung dieser Protokollfamilie unter Linux (und anderen Unixen) heist Samba.
Samba bietet von der einfachen Fähigkeit, Datei- und Druckerdienste in Arbeitsgruppen zur Verfügung zu stellen, über die Integration in bestehende NT-Domains bis hin zur kompletten Emulation eines NT-PDC alle Funktionen, die gebraucht werden, um Linux-Rechner in ein bestehendes oder neu zu erstellendes Windows-Netz zu integrieren. Die Windows-Arbeitsstationen merken gar nicht, daß es sich bei dem Server um einen Linux-Rechner handelt, aus ihrer Sicht arbeitet hier ein Windows Server.
Das grundlegende Prinzip ist zunächst einmal sehr einfach. Um Samba auf einem Linux-Rechner zu installieren müssen zwei Daemonen gestartet werden:
Beide dieser Daemonen erhalten ihre Konfigurationsinformationen aus einer einzigen Datei, /etc/smb.conf. Diese Datei enthält alle Einstellungen, die nötig sind, um SMB-Dienste zu aktivieren.
Samba ist üblicherweise ein Stand-alone Dienst, kann aber auch via inetd gestartet werden. Nachdem aber in den meisten Fällen ein Rechner mit Samba-Dienst hauptsächlich als solcher arbeitet, wird der stand-alone Variante meist der Vorzug gegeben. In diesem Fall erledigt das entsprechende Init-Script (z.B.: /etc/init.d/smb/) die Aufgabe, sowohl den SMB-Server smbd, als auch den NetBIOS-Nameserver nmbd jeweils mit dem Parameter -D (für Daemon) zu starten (oder zu stoppen).
Wir werden jetzt eine sehr einfache smb.conf Datei durchsprechen, die die grundlegenden Prinzipien dieser Konfigurationsdatei zeigt. Die einzelnen Bereiche werden jeweils kommentiert, erklärt und denkbare Alternativen werden aufgezeigt.
Der grundsätzliche Aufbau dieser Konfigurationsdatei entspricht dem von Windows-INI-Dateien. Das heißt, die Datei besteht aus einzelnen Abschnitten, die immer durch Überschriften in eckigen Klammern voneinander getrennt sind. Kommentare innerhalb der Konfigurationsdatei werden durch Strichpunkte eingeleitet, nicht durch Doppelkreuze (Doppelkreuze funktionieren jedoch auch).
Alle Freigaben, also sowohl Drucker, als auch Dateifreigaben werden als sogenannte shares bezeichnet. Jedes Verzeichnis und jeder Drucker, der freigegeben wird ist also ein share und hat einen eigenen Abschnitt innerhalb der Konfigurationsdatei. Ein spezieller solcher Abschnitt ist [global], der globale Einstellungen ermöglicht. Aber genug der Theorie, fangen wir an. Das folgende steht in unserer /etc/smb.conf:
[global] workgroup = ARBEITSGRUPPE netbios name = MARVIN security = SHARE guest account = nobody [public] comment = Oeffentliches Verzeichnis path = /usr/public guest ok = Yes read only = YesWir haben nur zwei einfache Abschnitte in dieser Datei, [global] und [public]. Der erste Abschnitt beschreibt die globalen Einstellungen und muß diesen Namen tragen. Der zweite beschreibt eine Freigabe, deren Namen willkürlich auf "public" gesetzt wurde. Der Name könnte auch anders heißen, es ist einfach nur ein Name.
Der zweite Eintrag (netbios name = marvin) definiert den Namen, der aus der Sicht von Windows Rechnern für den Samba Server gültig ist. Wir dieser Eintrag weggelassen, dann wird der Standard-Unixname (DNS Name) des Servers gewählt.
Der Eintrag security = share legt fest, daß die Zugangssteuerung auf Freigabeebene erfolgt, das ist die simpelste Möglichkeit, die einzige, um keine Passwörter zu brauchen. Wir werden uns später mit dieser Einstellung noch intensiv auseinandersetzen.
Der nächste (und letzte) Eintrag der Sektion [global] beschreibt, unter welcher UserID der Dateizugriff stattfinden soll, wenn ein nicht authorisierter User (also ein Gast ohne Passwort) auf einen Dienst zugreift. Die Tatsache, daß Windows selbst keine vergleichbaren Usereinstellungen kennt, zwingt uns hier, einen User anzugeben, damit Linux weiß, welche Rechte hier zur Verfügung stehen. In diesem Fall ist es also der User nobody, ein User ohne besondere Rechte.
Wenn wir jetzt also von einem Windows-Rechner aus die Netzwerkumgebung ansehen und die Workgroup Arbeitsgruppe aufrufen, werden wir folgendes Bild zu sehen bekommen:
Der Kommentar Samba 2.0.6 ist der voreingestellte Kommentar, den wir in der Sektion [global] auch ändern könnten, indem wir die Anweisung
server string = ...eingefügen. Diese Einstellung bietet noch die Möglichkeit, den Rechnernamen mit einem %h darzustellen, die Version von Samba bekommen wir mit %v. Hätten wir also in der Sektion [global] geschrieben:
server string = Samba Versuchsserver auf %h (Samba %v)dann stünde im Kommentarfeld der Netzwerkumgebung unter Windows
Die erste Anweisung (comment = Oeffentliches Verzeichnis) definieren einen Kommentar, den wir dann in der Netzwerkumgebung unter Windows wiederfinden werden. Beachten Sie, daß Unix und Windows völlig anders mit Umlauten umgehen. Hätten wir Öffentlich statt Oeffentlich geschrieben, so hätte der Windows-User statt dem Ö ein | gesehen, was sicherlich weniger informativ gewesen wäre...
Die zweite Anweisung definiert den absoluten Pfad unter Linux, auf den sich diese Freigabe bezieht. Die Angabe path = /usr/public bedeutet also, daß unter dem Freigabenamen public das Verzeichnis /usr/public zu erreichen ist.
Die Angabe guest ok = yes bedeutet, daß dieses share ohne Passwort erreichbar ist. Stattdessen hätten wir auch schreiben können:
public = YesEs ist also ein öffentlich zugängliches Verzeichnis für alle Windows-User. Kein Passwort wird verlangt. Allerdings haben alle User in diesem Verzeichnis dann auch nur das Recht des Gast-Users.
Die letzte Zeile erklärt sich von selbst, read only = Yes meint natürlich, daß die Freigabe nur ReadOnly erfolgt, daß die Windows-User also dort nur lesen dürfen. Aus der Sicht von Windows bekommen wir also jetzt folgendes Bild, wenn wir oben den Rechner marvin angeklickt hätten:
Beachten Sie, daß die Dateien, die auf dem Rechner marvin im Verzeichnis /usr/public liegen nur dann lesbar sind, wenn sie - aus der Sicht von Linux - vom User nobody lesbar sind. Wir haben ja oben angegeben, daß ein Gastzugriff unter dieser UserID verwaltet wird. Jeder passwortlose Zugriff auf dieses Verzeichnis wird jetzt unter der UserID von nobody vorgenommen.
Es ist auch möglich, für jedes angegebene share einen eigenen Gast-User festzulegen. Wenn die Anweisung guest account = ... in einem Abschnitt vorkommt, der nicht die Sektion [global] ist, so gilt diese spezielle Abmachung nur für diesen share.
Zwei weitere interessante Anweisungen für jeden share sind
Selbstverständlich können beliebig viele shares angelegt werden, um verschiedene Verzeichnisse auf unterschiedliche Arten freizugeben. Jedes share bekommt einen eigenen Abschnitt in der smb.conf, beginnend mit dem Freigabenamen in eckigen Klammern, gefolgt von den entsprechenden Angaben...
Samba bietet einen sehr einfachen Mechanismus, der einem Windows User erlaubt, sein Home-Verzeichnis auf dem Linux-Rechner zu nutzen, wenn sein Username unter Linux der selbe Name wie der unter Windows ist. Erweitern wir unsere /etc/smb.conf Datei doch einmal um diesen Mechanismus zum laufen zu bringen:
[global] workgroup = ARBEITSGRUPPE netbios name = MARVIN security = SHARE guest account = nobody [homes] comment = Heimatverzeichnis read only = No create mask = 0750 browseable = No [public] comment = Oeffentliches Verzeichnis path = /usr/public guest ok = Yes read only = YesUm diese Erweiterung auch aktiv zu machen müssen wir den Samba Server neu starten, am einfachsten mit
/etc/init.d/smb restartWenn wir uns jetzt auf unserem Windows-Rechner als - sagen wir mal - User hans anmelden - und ein User hans auf dem Linux-Rechner existiert, dann sieht die Liste der freigegebenen Shares in der Netzwerkumgebung jetzt folgendermaßen aus:
Hätten wir uns aber als otto eingeloggt (und gäbe es einen User otto unter Linux) so hätten wir statt der Angabe der Freigabe von hans jetzt eben die von otto gesehen.
Die konsequente nächste Fragestellung ist jetzt natürlich die des Passworts, das wir für diesen Zugriff benötigen. Grundsätzlich gilt:
Windows frägt im zweiten Fall dann einfach nach dem Passwort nach und gibt auch die Möglichkeit frei, das angegebene Passwort in einer Passwortliste zu speichern. Wird das Passwort gespeichert, so muß es beim nächsten Mal nicht erneut angegeben werden.
Die Lösung besteht darin, eine eigene Passwortverwaltung für den Sambadienst zu installieren. Das geschieht durch zwei einfache Schritte:
encrypt passwords = Yeswird in die [global] Sektion der /etc/smb.conf aufgenommen
Um jetzt also diese Passwort-Datei anzulegen und verschlüsselte Passwörter zu generieren benötigen wir wiederum ein kleines Programm mit Namen smbpasswd. Dieses Programm erlaubt es, sofern es der Superuser root anwendet, neue Samba-User anzulegen und ihnen Passwörter zu vergeben. Ein Normaluser kann nur sein Passwort damit ändern. Um einen neuen User anzulegen schreibt root jetzt
smbpasswd -a UsernameEr wird dann gleich nach dem Passwort des neuen Users gefragt, das Passwort wird verschlüsselt und zusammen mit der UserID des Users in der Datei /etc/smbpasswd abgelegt.
Damit also alles jetzt wirklich funktioniert muß die [global]-Sektion unserer smb.conf Datei jetzt folgendermaßen aussehen:
[global] workgroup = ARBEITSGRUPPE netbios name = MARVIN security = SHARE guest account = nobody encrypt passwords = YesUnd schon funktioniert die Freigabe der Userverzeichnisse.
Die Sektion [homes] ist also - wie die Sektion [global] eine spezielle Möglichkeit. Sie muß grundsätzlich diesen Namen tragen denn Samba übernimmt ja sehr spezielle Ersetzungsmechanismen, wenn dieser share angesprochen wird.
[global]
workgroup = ARBEITSGRUPPE
netbios name = MARVIN
security = SHARE
guest account = nobody
encrypt passwords = Yes
printing = BSD
Um jetzt Drucker selbst freizugeben haben wir zwei Möglichkeiten:
Wenn alle Drucker freigegeben werden sollen wird ein Mechanismus benutzt, der dem der Userverzeichnisse ähnelt. Wir legen ein spezielles share an, das zwingend [printers] heissen muß. Dieses share enthält folgende Anweisungen:
[printers]
comment = All Printers
path = /tmp
create mask = 0700
printable = Yes
browseable = No
guest ok = Yes
Der angegebene Pfad bezieht sich auf ein Verzeichnis, in dem alle User
Schreibrecht haben (und dem also das Sticky-Bit gesetzt sein sollte). Die
Create Mask legt fest, welche Permissions Druckaufträge haben sollen, die in
diesem Verzeichnis liegen. Die Angabe printable = Yes bedeutet, daß - selbst
wenn das Verzeichnis selbst Read only = Yes als Parameter hat, Druckaufträge
dort abgelegt werden dürfen. Die Angabe browseable = No bedeutet, daß der
share [printers] selbst nicht erscheint.
Auf diese Weise werden alle Drucker, die unter Linux in der /etc/printcap Datei auftauchen, dem Windows-Rechner angezeigt und freigegeben. Das heißt, daß auch wenn - wie bei vielen Distributionen üblich - mehrere logische Drucker angelegt werden, all diese logischen Drucker auch angezeigt werden:
Das kann einen unbedarften Windows-User natürlich verwirren. Um aber nur einen einzigen Drucker anzuzeigen, wird statt des [printers] Abschnitts ein Abschnitt für den freizugebenden Drucker angelegt, dessen Name jetzt wieder frei wählbar ist:
[PSLaser]
comment = PS_600dpi-a4-auto-mono-600
path = /tmp
create mask = 0700
guest ok = Yes
printable = Yes
printer name = lp2
Der entscheidende Unterschied zu einem share für Verzeichnisse sind
eigentlich nur die Anweisungen printable = yes und
printer name = lp2
Daran merkt Samba, daß es sich hierbei um einen Drucker-Dienst und nicht um einen Dateidienst handelt. Der Windows-User bekommt jetzt folgendes Bild zu sehen:
Die Angabe printer name = lp2 bezieht sich auf den Namen des Druckers, der unter Linux gültig ist. In diesem Fall darf natürlich auch nicht browseable = No eingetragen werden, sonst sieht der Windows-User den Drucker nicht in seiner Liste.
Die Angabe guest ok = yes ermöglicht das Drucken ohne Passworteingabe.
security = ...in der [global]-Sektion eingestellt werden. Das heißt, sie gelten immer für den gesammten Server und sind nicht für jedes einzelne share einstellbar. Denkbare Werte für security sind share, user, server und domain. Diese vier Sicherheitsebenen werden hier einzeln erläutert.
security = sharein die [global]-Sektion eingetragen. Dieser Eintrag entspricht der "Zugriffssteuerung auf Freigabeebene" unter Windows. Es ist die geringste Sicherheitsstufe, die Zugriff auf bestimmte shares nur über die Frage klärt, ob ein share öffentlich ist oder nicht. Allerdings kann auch unter dieser Einstellung mit Samba eine userbezogene Freigabe realisiert werden, indem dem share die Anweisung
guest ok = Nogesetzt wird. In diesem Fall wird Samba ein Passwort anfordern, das zu dem Usernamen passen muß, der unter Windows angegeben wurde. Auch hier gilt, daß ab Win98 die Passwörter verschlüsselt übermittelt werden, also die Zeile
encrypt passwords = Yesin der [global]-Sektion stehen muß. Zusätzlich muß der entsprechende User sowohl Linux bekannt sein, als auch ein verschlüsseltes Passwort in der Datei /etc/smbpasswd besitzen. (Siehe Userverzeichnisse)
Die Frage, wer dann nun was in dem Verzeichnis anstellen darf wird wiederum von Linux selbst beantwortet. Es gelten die normalen Unix-Dateizugriffsrechte des jeweiligen Users. Das ist auch der Grund, warum jeder Samba-User auch eine gültige Unix UserID besitzen muß.
Zusammenfassend ist also zu sagen, daß Samba mit dieser Methode noch wesentlich sicherere Zugriffe zulässt, als es Windows95/98 zulassen würde. Andererseits ist diese Methode erheblich eingeschränkt, was die Möglichkeiten der userbasierten Zugriffskontrolle angeht.
security = share wird hauptsächlich in Systemen eingesetzt, die alle Dienste frei - ohne Passwörter - anbieten wollen, oder in Systemen, deren User nicht identisch mit den Windows-Usern sind.
security = userin der [global]-Sektion ermöglicht. Das ist - seit Samba 2.0 - die voreingestellte Methode. In dieser Einstellung muß sich ein Windows-User zuerst "einloggen", bevor er irgendwelche Dienste des Samba-Servers in Anspruch nehmen darf. Das heißt, er muß einen Usernamen und ein Passwort an den Samba-Server schicken, der wiederum überprüft, ob die beiden Angaben stimmen und erst nach erfolgreicher Prüfung Zugriff gewährt. Der Zugriff ist dann wiederum abhängig von den Linux-Rechten, die dieser User auf dem Samba-Server hat. Das heißt, daß diese Methode nur dann funktioniert, wenn auf dem Windows-Rechner die selben Usernamen existieren, wie auf dem Samba-Server.
Wie schon bei früheren Passwortübermittlungen wird auch hier wieder zwischen unverschlüsselter Passwortübermittlung (bis einschließlich Win95) und verschlüsselter Passwortübergabe (ab Win98) unterschieden. Das heißt, wenn die Windows-Rechner mindestens Win98 fahren, muß die Zeile
encrypt passwords = Yesin der [global]-Sektion stehen und die User müssen mittels smbpasswd angelegt werden.
Beachten Sie, daß der Name der angeforderten Resource nicht an den Server weitergeschickt wird, bevor sich der Windows-User nicht korrekt angemeldet hat. Das ist der Grund, warum Gast-shares (guest ok) in diesem Modus nicht funktionieren, ohne daß User automatisch in einen Gastaccount umgewandelt werden. Aber auch dazu müssen sie sich zuerst korrekt anmelden, also einen Useraccount besitzen.
Damit Samba weiss, an welchen Server es die Passwortüberprüfung weiterleiten soll, muß der entsprechende Server mit der Angabe password server = ... in der [global]-Sektion angegeben werden. Der angegebene Name muß ein NetBIOS Name sein, also der Name, unter dem der Rechner auch unter Windows ansprechbar ist. Dieser angegebene Server muß selbst im security = user Modus laufen, um die entsprechende Überprüfung vorzunehmen.
Achtung: Versuchen Sie niemals hier den Samba Server selbst einzutragen! Es würde zu einer Endlosschleife kommen, die den gesammten Samba-Server blockieren würde.
Aus der Sicht des Windows-Clients ist der Server-Modus absolut identisch mit dem User-Modus. Der Unterschied bezieht sich nur auf die Frage, wie der Samba-Server die Überprüfung der Zugriffsrechte vornimmt. Im User-Modus macht er es selbst, im Server-Modus leitet er es an einen anderen Server weiter. Natürlich kann dieser andere Server auch wieder ein Samba Rechner sein, der dann aber eben im User-Modus laufen muß...
Beachten Sie, daß der Name der angeforderten Resource nicht an den Server weitergeschickt wird, bevor sich der Windows-User nicht korrekt angemeldet hat. Das ist der Grund, warum Gast-shares (guest ok) in diesem Modus nicht funktionieren, ohne daß User automatisch in einen Gastaccount umgewandelt werden. Aber auch dazu müssen sie sich zuerst korrekt anmelden, also einen Useraccount besitzen.
Trotzdem müssen User dem Linux-System bekannt sein, damit eine Bestimmung ihrer Zugriffsrechte auf einzelne Verzeichnisse möglich ist. Jeder User braucht also einerseits einen Account auf dem PDC der Windows-Domain und andererseits einen gültigen Acccount auf dem Linux-Server.
Wie schon bei dem Server-Modus, so ist dieser Modus aus der Sicht des Windows-Clients einfach der User-Modus. Der Unterschied liegt nur darin, auf welche Weise der Samba-Server die Passwörter authentifiziert.
Wie schon im Server-Modus, so muß auch hier der Rechner angegeben werden, der die Passwortüberprüfung vornimmt. Wieder benutzen wir die Angabe
password server = ...in der [global]-Sektion. Nur jetzt geben wir nicht einen Server an, sondern eine Liste, durch Kommata getrennt. Hier können wir den PDC und alle existierenden BDCs angeben, also etwa
password server = NT-PDC, NT-BDC1, NT-BDC2Wird statt einer Liste einfach nur ein Pluszeichen (+) angegeben, so versucht Samba den PDC und die BDCs selbst herauszufinden.
Beachten Sie auch, daß der Name der Domain, der wir uns anschließen, wiederum mit dem Parameter workgroup = ... angegeben wird.
Damit unser Samba-Server aber überhaupt Mitglied einer Domain werden kann, müssen wir erst dafür sorgen, daß er davon auch weiss. Dazu kommt wiederum das Programm smbpasswd zur Anwendung, das wir ja schon zum Anlegen der User und Wechseln der Passwörter benutzt hatten.
Mit dem Aufruf von
smbpasswd -j Domainwird der Samba-Server in die genannte Domain aufgenommen. Damit das funktioniert, muß der Administrator der NT-Domain mit dem Programm Server Manager for Domains den primären NetBIOS Namen des Samba-Servers in die Liste der Domain-Mitglieder aufgenommen haben.
Erst nachdem dieser Befehl ausgeführt wurde, sollte die smb.conf auf security = domain gesetzt werden. Von nun an sendet der Samba-Server alle Anfragen an den PDC zur Authentifizierung weiter.
Die primäre Aufgabe dieses Daemons ist es, die Namensauflösung im SMB-Netz zu ermöglichen. Dabei ist es unerheblich, ob die entsprechenden NetBIOS-Namen den DNS-Namen entsprechen, es gibt aber viele Fälle, wo sich Probleme vermeiden lassen, wenn zumindestens der Samba-Server hier immer den selben Namen trägt.
Die Einstellungen des NMBD werden auch in der Datei /etc/smb.conf vorgenommen, dort aber nur in der [global]-Sektion. Dieses Kapitel beschreibt die notwendigen Einstellungen für die Namensauflösung, im nächsten Kapitel betrachten wir die Verwaltung der Browsing-List (Windows-Netzwerkumgebung), die auch vom NMBD übernommen wird.
Größere Netze sollten grundsätzlich die zweite Möglichkeit (WINS) in Anspruch nehmen, denn sonst wird das Netz mit unnötig vielen Paketen belastet.
Um mit WINS arbeiten zu können muß ein Rechner im Netz diesen Dienst auch anbieten. Das kann entweder ein WindowsNT/2000 Rechner sein, oder eben wieder ein Samba Server. In der Regel wird der NT Rechner benutzt, wenn Samba in einer gemischten NT/Samba Umgebung arbeitet. Wenn nur Samba-Server zur Verfügung stehen, wird einer dieser Server den Dienst übernehmen.
Windows-Rechner müssen diesen Server dann entsprechend unter den Eigenschaften von TCP/IP eintragen:
Zu beachten ist, daß - um die Netzwerkumgebung richtig darstellen zu können - immer nur ein WINS-Server pro Netzsegment (bzw. Workgroup) aktiv sein sollte. Ansonsten sehen die verschiedenen Windows-Clients jeweils nur die Rechner, die den entsprechend gleichen WINS-Server benutzen.
[global]
...
wins server = 123.45.67.89
...
Der Befehl wins server = erfordert entweder die IP-Adresse oder
den DNS-Domainnamen des entsprechenden Servers.
Viele Dienste von Samba, die die Browsing-Liste betreffen funktionieren nur, wenn ein WINS-Server im Netz aktiv ist. Ob dieser Server jetzt ein NT-Rechner oder wiederum ein Samba-Server ist, spielt keine Rolle.
Die notwendige Einstellung in der smb.conf lautet:
[global]
...
wins support = yes
...
Beachten Sie, daß NIEMALS beide Einstellungen (Server und Client)
gleichzeitig benutzt werden dürfen. Wenn Samba als Server arbeitet ist die
Zeile wins server = ... nicht nur unnötig, sondern schlicht
verboten.