Ich habe Besprechungen wie diese hassen gelernt. Ich gehe die Folienpräsentation noch einmal in meinem Kopf durch. Wenn ich nur eine Netzwerkverbindung unter meinem Tisch hätte, dann könnte ich wenigstens etwas Nützliches tun, wie z.B. meine E-Mail abrufen oder so etwas.
Ich merke, dass meine Chefin sich bereit macht, mich bald vorzustellen. »...und hier ist jetzt unser firmeninterner Experte in der Netzwerkadministration mit der Kostenanalyse für den Ersatz des Servers.« Meine Chefin liebt es, in ihren Sätzen das Wort Experte unterzubringen. Ich trinke noch einen Schluck Kaffee, mache mich auf den Weg in die Mitte des Raumes und stelle mich neben den Projektor. Ich drücke die Leertaste, um meinen Notebook aus dem Schlafmodus zu holen, und beginne zu reden. »Wir wollen uns heute einige Zahlen ansehen, die die Kosten der Dienste vergleichen, die wir unseren Benutzern im Netzwerk bieten«, beginne ich. Ich kann hören, wie die Festplatte meines Notebooks zu arbeiten beginnt, und die erste Folie erscheint wie gerufen ...
... das Fazit ist folgendes: Wenn wir eine Kombination aus Linux und Samba auf gewöhnlicher PC-Hardware benutzen, können wir den existierenden Datei-Server durch einen neueren Rechner ersetzen, der zweimal so schnell ist und etwa halb so viel kostet. Zweitens wird es keine mit dem Server verbundenen Client-Lizenzierungsgebühren pro Arbeitsplatz oder pro Verbindung geben. Und schließlich wird die Änderung für den Benutzer transparent sein.« Ich stoße einen stillen Erleichterungsseufzer aus, als ich mich wieder hinsetze, nur um festzustellen, dass mein Kaffee mittlerweile kalt geworden ist.
»Wenn diese Lösung so gut ist, wie sie sich anhört, warum haben wir das nicht gleich so gemacht?«, fragt einer der Abteilungsleiter.
Ich zucke meine Schultern ein wenig und erinnere mich an die Person, die den letzten Stoß Windows-NT-Server für das Unternehmen installiert hat. »Die Zeiten ändern sich», erkläre ich. »Egal was hinter der Planung stand, die uns an diesen Punkt gebracht hat, ist die Lösung, die ich präsentiert habe, heute für uns die beste, und ich glaube, dass sie uns auch in Zukunft gut bekommen wird.«
»Gut gemacht«, sagt meine Chefin, als wir nach der Besprechung zurück zum Büro gehen. »Ich lasse Mike die Bestellungen für die neue Hardware bis heute abend erledigen.«
»Sie ist immer so überoptimistisch, was diese Bestellungen angeht«, denke ich bei mir und muss lächeln. »Hört sich gut an«, antworte ich, als ich um die Ecke zum Labor biege und mich auf meinen Weg mache. Ich fange an, in meinem Kopf die Dinge durchzugehen, die ich erledigen muss, um den Windows-NT-Datei-Server durch einen Linux-Rechner zu ersetzen. »Wo habe ich bloß die Kaffeetasse hingetan?«, murmle ich.
Bis hierher habe ich die Möglichkeiten von Samba und die Einrichtung der Datei smb.conf dargestellt. Jetzt ist an der Zeit, das bisher Gelernte praktisch umzusetzen. In diesem Kapitel führe ich Sie Schritt für Schritt durch den Prozess, einen Windows-NT-4.0-Server durch einen Linux-Rechner mit Samba zu ersetzen. Der Windows-NT-Rechner bietet Festplatten- und Druckerfreigaben. Der Samba-Server übernimmt einfach die Aufgabe, die Freigaben zur Verfügung zu stellen. Wenn alles gut geht, wird der Endanwender niemals bemerken, dass der NT-Server ersetzt wurde.
Zunächst muss ich festlegen, welchen Anforderungen mein Samba-Server entsprechen muss. Ich stelle eine Liste auf:
Die ersten zwei Punkte lassen sich ohne Komplikationen realisieren, aber mit der letzten Anforderung werde ich einige Arbeit haben.
Hier sind die Netzwerkressourcen, die der aktuelle Windows-NT-Server bietet. Ich habe diese Liste etwas vereinfacht, damit ich einige Zeit damit verbringen kann, jeden Dienst einzeln anzusehen.
Abbildung 12.1 stellt den derzeitigen Aufbau dar. Ich werde in einem einzelnen Domänenmodell mit einem Primary Domain Controller (PDC) arbeiten, der alle Benutzerauthentifizierungen handhabt. Die Anzahl der Client-Rechner ist für meine Zwecke hier unwichtig. Um den neuen Server zu testen, brauche ich den PDC für die Durchführung der Authentifizierung, den neuen Server und einen Windows-NT-Client-Rechner.
Als Hintergrundinformation und um sicherzustellen, dass wir alle auf dem gleichen Stand sind, möchte ich klarstellen, dass ich einen Server benutzen werde, der mit der Slackware-Linux-3.5-Distribution aufgebaut wurde, die auf dem Linux-Kernel 2.0.34 basiert. Hier ist die Ausgabe von uname -a:
Linux picante 2.0.34 #2 Thu Jun 4 22:36:07 PDT 1998 i586 unknownDer Rechner selbst ist ein Dell Pentium 233 mit einer 8-Gbyte-IDE-Festplatte und 128 Mbyte RAM.
Die Samba-Installation ist Version 2.0, die ich als Source-Code heruntergeladen und über die folgenden drei Befehle kompiliert und installiert habe:
./configureIch werde fünf Schritte durchlaufen, um den Windows-NT-Server durch den neueren Linux-Rechner zu ersetzen:
Als ich zum ersten Mal über die Dienste sprach, die mein Samba-Server bieten muss, habe ich entschieden, dass sich alle existierenden Domänenbenutzer in der Lage sein sollten, sich mit dem neuen Server zu verbinden, ohne explizit von einem zweiten Account zu wissen. Es ist keine akzeptable Option, einen separaten Account zu erstellen und zu verwalten, auch nicht einen, dessen Passwort zum Domänen-Account synchron ist. Die Tatsache, dass Benutzer keine gültige Shell auf dem Linux-Rechner haben werden, macht diese Entscheidung möglich. Wenn Samba den Windows-NT-PDC für die Benutzerauthentifizierung benutzen kann, gibt es noch eine Sache weniger, über die ich mir den Kopf zerbrechen muss.
NTs relative IDs und Unix-UIDs und -GIDs
Bevor ich zu den speziellen Punkten komme, die für Benutzer-Accounts relevant sind, möchte ich einige Hintergrundinformationen für diejenigen bieten, die damit vertraut sind, wie Windows NT einen Account intern darstellt. Ich denke, das dies helfen wird, einige der Entscheidungen zu rechtfertigen, die ich später treffen muss.
Windows NT benutzt wie Unix eine numerische Zahl, um Accounts intern darzustellen. Unix macht dabei jedoch einen Unterschied zwischen einem Domänen-Account und einem lokalen Account. Wenn Sie mit Suns Network Information Service (NIS) vertraut sind, ist es hilfreich, sich den PDC als den NIS-Master vorzustellen, und Domänen-Accounts sind jene, die in der NIS-passwd-Map aufgelistet sind. Wenn ein Account mit dem Benutzernamen jdoe sowohl in der lokalen Datei /etc/passwd als auch in der NIS-passwd-Map vorhanden ist, wird nur einer der Accounts gesehen, je nach Suchreihenfolge, die in /etc/nsswitch.conf definiert ist: Dateien oder NIS. Deshalb habe ich vorher erwähnt, dass Unix die Unterscheidung zwischen lokalen und globalen Accounts nicht ermöglicht.
Ein anderer Unterschied zwischen den beiden Betriebssystemen besteht darin, dass Windows-NT-Gruppen- und -Benutzer-Accounts im gleichen Zahlenbereich existieren. Es ist sehr gut möglich, wenn nicht sogar üblich, einen Unix-Rechner mit einer Gruppe zu sehen, die eine ID von 0 (wheel) hat, und einem Benutzer-Account, der ebenfalls eine ID von 0 (root) hat. Es kommt in diesem Fall zu keinen Problemen, da Unix-GIDs und -UIDs völlig separat voneinander existieren. Windows-NT-Gruppen- und -Benutzer-Accounts existieren nebeneinander. Daher ist es unmöglich, eine Gruppe und einen Benutzer-Account mit einer ID von 1002 zu haben. Windows-NT-Gruppen und -Benutzer werden in einer monoton sich erhöhenden Reihenfolge erzeugt, die mit 1000 beginnt. Diese ID-Nummer wird relative ID oder RID genannt. Einer RID wird entweder die ID des lokalen Rechners oder die ID der Domain angehängt, um den Account vollständig zu qualifizieren und so die Unterscheidung zwischen lokalen und Domänen-Accounts sicherzustellen. Diese Rechner-IDs werden Security Identifiers oder SIDs genannt.
Vielleicht fragen Sie sich, ob Gruppen und Benutzer im gleichen Zahlenbereich existieren. Wie können Sie dann bestimmen, ob es sich bei der ID 1002 um eine Gruppe oder einen Benutzer handelt? Windows NT weist ein Flag für den Account-Typen zu, das mit jedem Objekt gespeichert wird. Die RID allein ist für die Identifizierung des Account-Typs nicht ausreichend.
Jetzt, da ich verstehe, wie Windows NT und Unix Benutzer und Gruppen darstellen, wie komme ich dann vom einen zum anderen und wieder zurück? Die einfachste Methode, wenn der Samba-Server Mitglied einer NT-kontrollierten Domäne ist, besteht darin, einfach dem Benutzernamen für den NT-Account einen Benutzernamen auf dem Unix-Rechner zuzuweisen.
Moment mal! Hatte ich nicht gesagt, dass ich nicht wollte, dass sich Benutzer mit einem zweiten Account auf dem Samba-Server abgeben müssten? Hier ist die Lösung. Ich erstelle Accounts für die Benutzer auf meinem Linux-Rechner, überlasse aber dem PDC jegliche Authentifizierung. So kann ich alle Passwortfelder in /etc/passwd deaktivieren, und die Benutzer haben nur einen Account zu verwalten.
Warum braucht man also überhaupt einen Unix-Account? Eine Sache, die derzeit nicht in Samba implementiert ist, ist die Unterstützung für Windows-NT-Zugriffskontrolllisten auf Freigaben, die Samba zur Verfügung stellt. Daher benutze ich die Standard-Unix-Dateiberechtigungen, was bedeutet, dass jeder Benutzer für seine Arbeit eine Unix-UID und -GID benötigt. Ergibt das einen Sinn?
Da Sie nun verstehen, warum ich Accounts für die Domänenbenutzer auf dem Linux-Rechner einrichten muss, kann ich aus zwei Optionen wählen. Erstens kann Samba sie, wenn notwendig, automatisch einrichten, wenn ein Benutzer sich verbindet. Die zweite Lösung besteht darin, die Benutzer und Gruppen manuell einzurichten. Mit manuell meine ich nicht, dass Automatisierung über Skripte nicht möglich ist, sondern dass die Accounts ohne Intervention von Samba erstellt werden.
Ich wähle aus folgendem Grund die zweite Option: Der existierende NT-Server hat bereits Dateien, die von Domänenbenutzern erstellt wurden und deren Eigentum sie sind. Dies ist wahrscheinlich in den meisten Fällen so. Ich kann Linux-Benutzer-Accounts aus dem Nichts einrichten, aber es kann schwierig sein, existierende Gruppenmitgliedschaften korrekt zu übertragen. Ich denke, dies wird noch klarer werden, je weiter ich komme.
Zunächst brauche ich eine Auflistung der Benutzer-Accounts vom PDC. Die Windows-NT-Version des Befehls net.exe hat eine weitere Option, die ich bisher noch nicht erwähnt habe. Über die Option user kann ich Informationen über lokale und Domänen-Accounts erhalten. Wenn ich den folgenden Befehl ausgebe, erhalte ich eine Auflistung aller Domänenbenutzer. Mein Windows-NT-4.0-PDC ist der Rechner SALSA.
E:\users>net user /domainWenn ich Informationen über einen speziellen Benutzer-Account brauche, kann ich der Option user ein weiteres Argument hinzufügen, um anzugeben, welcher Benutzer gesucht werden soll. Um z.B. weitere Informationen über einen Benutzer namens scooby zu erhalten, gebe ich den Befehl net user scooby /domain aus. Die Ausgabe dieses Befehls sehen Sie in Listing 12.1.
Listing 12.1: Account-Informationen über Domänenbenutzer ausgegeben vom Befehl net user
E:\users>net user scooby /domainNun brauche ich einige Informationen über die Domänengruppen. Es gibt einen analogen Parameter zur Option user für den Befehl net.exe, der die Liste der lokalen oder Domänengruppen und damit verbundene Informationen anzeigt:
E:\users>net group /domainDie Option group akzeptiert einen Gruppennamen, wenn ich Informationen über die aktuellen Mitglieder brauche:
E:\users>net group "Dept Heads" /domainDa ich jetzt Zugriff auf alle notwendigen Informationen habe, möchte ich die Accounts einrichten. Auf der CD-ROM zu diesem Buch finden Sie ein einfaches Perl-Skript namens nt2passwd, das die Ausgabe des Befehls net user /domain akzeptiert und gültige /etc/passwd-Einträge produziert. Das Skript richtet außerdem für jeden Benutzer ein Home-Verzeichnis ein. Falls ich mich entscheide, dies nicht zu tun, wird das entsprechende Feld im passwd-Eintrag auf /dev/null gesetzt. Hier ist die Ausgabe, nachdem ich die Liste der Domänenbenutzer durch das Skript laufen ließ. Zuerst habe ich die Ausgabe von net user /domain abgefangen und habe sie mit einer Datei verkettet:
E:\users>net user /domain > users.txtDann habe ich die Datei users.txt auf meinen Linux-Rechner übertragen und das nt2passwd-Skript laufen lassen:
# ./nt2passwd users.txtSie haben wahrscheinlich bereits bemerkt, dass Linux keine Benutzernamen mit mehr als acht Zeichen unterstützt. Wenn das nt2passwd-Skript einen nicht zugelassenen Namen entdeckt, fordert es Sie auf, einen gültigen Benutzernamen einzugeben. Existiert der neue Benutzername bereits, fragt das Skript, ob der Benutzer einen anderen Namen probieren möchte. Der Benutzer kann den Account komplett überspringen, indem er mit einem n antwortet. Eine Datei mit Einträgen in der Form von
UnixBenutzername=NTBenutzernamewird erstellt und erhält den Namen Benutzername.map, um die Entsprechungen aufzuzeichnen. Ich kann diese Datei mit dem smb.conf-Parameter username map benutzen, damit Windows-NT-Benutzernamen korrekt mit einem gültigen Unix-Account verbunden werden. Folgende Map-Datei wird bei meinem Beispiel erzeugt:
ntadmin=administratornt2passwd erstellt eine Datei namens passwd.new, die alle neu eingerichteten Accounts enthält. All dies ist notwendig, um die Datei an meine existierende Datei /etc/passwd anzuhängen. nt2passwd überprüft, ob es UID-Konflikte gibt, wenn die Accounts eingerichtet werden, also ist dies kein Problem:
# cat passwd.new >> /etc/passwdDanach muss ich Einträge für die NT-Domänengruppen in der /etc/group einfügen. Auch hierfür benutze ich wieder die Ausgabe des Befehls net.exe, um die Einträge zu erstellen. Zunächst leite ich die Ausgabe von net group /domain in eine Datei weiter:
net group /domain > groups.txtDanach gebe ich die Ausgabe des Befehls net group an das Perl-Skript namens nt2group weiter. Dieses Skript nimmt einen zusätzlichen Parameter an, nämlich den Namen einer Datei, die den entsprechenden Linux-Gruppennamen für die Windows-NT-Domänen-Gruppennamen enthält. Pro Zeile wird eine Zuordnung eingegeben, die beiden Namen werden dabei durch einen Doppelpunkt (:) getrennt. Hier ist die Beispielzuordnungsdatei, die ich benutze. Die NT-Gruppennamen sind links und die Linux-Gruppennamen rechts dargestellt:
accounting:acctNach Starten des nt2group-Skripts
# nt2group groups.txt group.mapwerden die folgenden Einträge in einer Datei namens group.new erstellt. Es gibt keinen Eintrag für die Gruppe users, weil diese Gruppe auf meinem Linux-Rechner bereits existiert.
acct:*:200:Ich hänge diese Einträge an die auf dem System vorhandene Datei /etc/group an, um die Gruppen zu erstellen:
cat group.new >> /etc/groupJetzt sind die Benutzer und die Gruppen eingerichtet. Der letzte Schritt besteht darin, die Gruppen mit den entsprechenden Benutzernamen zu füllen. Dafür verwende ich wieder das nützliche Utility net.exe. Denken Sie daran, dass Sie die Mitglieder einer Gruppe bestimmen können, indem Sie den Befehl net group Gruppenname /domain ausführen. Auf der CD-ROM finden Sie ein weiteres Perl-Skript namens add2group, das diese Ausgabe benutzt und die aktualisierte Version der Datei /etc/group an Standard Output weiterleitet.
Schauen Sie sich dazu ein Beispiel an. Hier ist die Ausgabe von net group Accounting /domain für die Domäne CHIPSNDIPS:
Gruppenname AccountingHier ist die Beispielausführung für die Linux-Gruppe namens acct über die gleiche Gruppenzuordnung, die ich vorher mit dem Tool nt2group durchgeführt habe. Der erste Parameter ist die Ausgabe des Befehls net group Accounting, das zweite Argument ist die Gruppen-Zuordnungsdatei, die ich mit dem nt2group-Skript verwendet habe, und der letzte Befehlszeilenparameter ist die Datei, die die Zuordnungen der Benutzernamen enthält und vom nt2passwd-Skript erstellt wurde.
Das Skript zeigt tatsächlich auch die nicht modifizierten Einträge an, aber ich habe die Ausgabe hier aus Platzgründen gekürzt:
# add2group accounting.txt group.map username.mapIch wiederhole den gleichen Schritt für jede Domänengruppe. Hier sind die Ergebnisse für die vier Gruppeneinträge:
users:100:gamesBeachten Sie, dass für die Gruppe users keine Namen aufgelistet sind. Das liegt daran, dass ich den Benutzer dem Eintrag in /etc/group nicht hinzufügen muss, wenn dies die primäre Gruppen-ID des Benutzers ist, wie sie in /etc/passwd definiert ist. Das Skript lässt alle Benutzernamen aus, die nicht in /etc/passwd gefunden werden. Wenn ich z.B. entscheide, keinen Account für Administrator einzurichten, wäre er einfach übergangen worden, wenn er Mitglied der Gruppe Accounting gewesen wäre.
Nun habe ich endlich die Benutzer-Accounts eingerichtet, die Gruppen erstellt und den notwendigen sekundären Gruppen Benutzer hinzugefügt. Wow! Das war viel Arbeit! Glücklicherweise ist dies der härteste Teil des Prozesses für den Ersatz des Windows-NT-Servers.
Ich habe vorher erwähnt, dass Samba, wenn notwendig, Benutzer-Accounts automatisch für Sie einrichten kann, wenn sich ein bestimmter Benutzer verbindet. Dies können Sie erreichen, indem Sie ein Skript für den smbd definieren, das gestartet wird, wenn ein Benutzer hinzugefügt oder entfernt werden soll. Diese zwei globalen Parameter, add user script und delete user script, sind neu in Version 2.0. Sie sind Teil einer Entwicklung, das zur Verfügung zu stellen, was »Gerätemodus« genannt wird. Diese Funktion ermöglicht die Anwendung eines Samba-Gerätes in einem Windows-NT-Netzwerk, das hauptsächlich aus Adressparametern besteht. Alle Benutzer und Gruppen können aus dem Nichts nach Bedarf erstellt werden. Halten Sie sich auf dem Laufenden, da Samba ständig weiterentwickelt wird, um diese Art von Funktion zu unterstützen.
Wenn Sie vorhandene Dateien übertragen, die verbundene Zugriffskontrolllisten haben, ist es besser, die Dinge außerhalb von Samba zu konfigurieren, so wie ich es getan habe.
Das Verschieben von Dateien von einem Windows-NT-Server auf meinen Linux-Rechner könnte ein absoluter Alptraum sein! Es gibt jedoch einige gute System-Management-Techniken, die dabei helfen können, die Dinge etwas einfacher zu machen. Ich kann den notwendigen Aufwand vermindern, indem ich den Verzeichnisbaum organisiere und Dateien mit gemeinsamen Eigentümern und gemeinsamen ACLs gruppiere.
Ich fange damit an, einen genaueren Blick auf die [users]-Freigabe zu werfen, die der NT-Datei-Server bietet. Der Aufbau der Freigabe entspricht dem Exportieren des Verzeichnisses /home/ zu anderen Unix-Rechnern über NFS und dem Platzieren der Home-Verzeichnisse der Benutzer eine Ebene tiefer. Anders gesagt, \\PICANTE\users enthält ein Verzeichnis für jeden Domänenbenutzer. Das Home-Verzeichnis eines Benutzers ist tatsächlich \\PICANTE\users\Benutzername.
Die Verzeichnisberechtigungen für Ordner, die in der [users]-Freigabe enthalten sind, sind sehr direkt. Jeder Benutzer hat vollständige Kontrolle über sein entsprechendes Verzeichnis. Nur ein Administrator (z.B. PICANTE\Administrator) kann Verzeichnisse auf oberster Ebene in der Freigabe erstellen. Dies bedeutet die Unix-Berechtigungen.
drwx------ Benutzername Gruppenname Benutzername/Um Dateien in Home-Verzeichnisse zu übertragen, brauche ich nur die Dateien des Benutzers an den in /etc/passwd definierten Standort zu kopieren. Dann kann ich über den Befehl chown die Berechtigungen einrichten:
chown -R Benutzername Home-VerzeichnisIch ersetze Benutzername durch den entsprechenden Namen und Home-Verzeichnis durch den absoluten Pfad zum Home-Verzeichnis des Benutzers. Gruppenname ist die primäre Gruppen-ID des Benutzers aus /etc/passwd.
Nun definiere ich die [users]-Freigabe in smb.conf, um den gleichen Dienst wie vorher zu bieten:
[users][docs]
Die Freigabe [docs] ist aufgrund der Unterschiede in den Datei- und Verzeichnis-ACLs etwas schwieriger zu übertragen. Ich muss mich mit zwei Möglichkeiten befassen. Die eine besteht darin, dass ein einzelner Benutzer oder eine einzelne Gruppe in der Zugriffskontrollliste benutzt wird. Dann kann das Verzeichnis in ein entsprechendes Unix-Berechtigungsbit-Modell umgewandelt werden, aber bei der anderen Möglichkeit ist eine Entsprechung nicht so leicht zu realisieren. Es kommt zu einem Problem, wenn mehrere Benutzer oder Gruppen in der Zugriffskontrollliste eingefügt sind.
Schauen wir uns zunächst die Möglichkeit des Zugriffs von einem einzelnen Benutzer oder einer einzelnen Gruppe an und wie Sie damit umgehen können.
Abb. 12.2: Ein Diagramm der Verzeichnis-Zugriffskontrolllisten in der Freigabe [docs]
Abbildung 12.2 zeigt die verschiedenen ACLs auf Verzeichnissen innerhalb des [docs]-Verzeichnisbaums. Obwohl die verschiedenen Verzeichnisse unterschiedliche Besitzer haben, nehme ich an, dass der Zugriff weitestgehend begrenzt ist. So besitzt z.B. die Gruppe acct (Accounting) das Verzeichnis \\PICANTE\docs\finances und alles, was darunter liegt, und die Gruppe webdev (Web Development) kontrolliert den Verzeichnisbaum \\PICANTE\docs\src. Diese Art von Zugriffskontrolle kann über die Unix-Eigentümer- und -Gruppenberechtigungsbits dargestellt werden. Ich werde außerdem das Gruppen-ID-Bit einrichten, damit sich die Gruppeneigentumsverhältnisse im entsprechenden Verzeichnis nach unten fortsetzen:
drwxrws--- root acct finances/Unter Unix können Verzeichnisse nicht in Besitz mehrerer Benutzer oder Gruppen gleichzeitig sein. Unter Windows NT übrigens auch nicht, aber das Unix-Berechtigungsmodell basiert ausschließlich auf den Eigentumsverhältnissen. Es gibt keine Methode, Mitglieder auch nur zweier Gruppen auf Dateien zugreifen zu lassen. Es ist entweder Zugriff für eine Gruppe oder allgemeiner Zugriff. Windows NT trennt Besitztum von Zugriffsrecht durch die Anwendung von Zugriffskontrolllisten, die mehreren Benutzern und Gruppen Einträge ermöglichen, wobei jeder eine eindeutige Einstellung für die Berechtigung hat. Die einzige Methode, dies ohne richtige NT-ACL-Unterstützung zu umgehen, besteht in der Verwendung einer Kombination der smb.conf-Parameter valid users, write list, read list und force user. Im Wesentlichen werden die ersten drei Parameter die Datei- oder Verzeichnis-ACL. Der Parameter force user kann nützlich sein, aber alle »Ersteller-Besitzer«-Informationen gehen verloren.
Mein Beispiel setzt einen einzelnen Benutzer oder eine einzelne Gruppe in der ACL voraus. Ich glaube nicht, dass diese Voraussetzung die Nützlichkeit von Samba in dieser bestimmten Umgebung verschlechtert, sondern es lässt einfach den Bedarf für eine besser organisierte Verzeichnisstruktur aufkommen. Obwohl NT-ACLs derzeit in Version 2.0 noch nicht unterstützt werden, sind Entwicklungen im Gange, um die notwendigen Mechanismen zu implementieren.
Bevor Sie die Dateien verschieben, sollten Sie sich Notizen über die aktuellen Verzeichniseigentumsverhältnisse und die relevanten ACL-Informationen machen. Dann kann ich die entsprechenden Berechtigungen manuell auf dem Linux-Server einrichten. Wenn z.B. \\PICANTE\docs\Projects in Besitz der Gruppe Dept Heads wäre und zumindest »Change«-Berechtigungen für das Verzeichnis eingerichtet wären (d.h. rwxd, falls Sie nicht mit Windows-NT-ACLs vertraut sind), würde ich die entsprechenden Berechtigungen auf dem Linux-Rechner einrichten, indem ich eine Reihe von chown-, chgrp- und chmod-Befehlen ausführe:
# chown -R root /export/docsUm dies zu aktivieren, konfiguriere ich die [docs]-Freigabe in smb.conf dahingehend, dass für Dateien immer die Gruppen-Lese-Schreib-Bits eingerichtet sind und für Verzeichnisse Lesen-Schreiben-Ausführen:
[docs][canon]
Ich werde das Drucken von einem Windows-Client zu einem Samba-Server nicht im Detail darstellen. Aber es gibt zwei Dinge, die Sie beachten sollten.
Ein Windows-NT-Rechner benutzt spezielle Mechanismen, um an einen anderen Windows-NT-Rechner zu drucken. Diese unterscheiden sich von dem Aufruf, den er macht, um an einen Windows-9x-Server oder einen Samba-Server zu drucken. Das bedeutet, dass es derzeit noch nicht möglich ist, einen Samba-Server gegen einen Windows-NT-Drucker-Server auszutauschen, ohne einiges an Vorarbeiten zu leisten. Diese beinhalten normalerweise eine geringfügige Neukonfiguration der Netzwerkdruckerverbindung des Clients. Das Problem mit der Implementierung echten NT-Druckens liegt darin, dass, wenn Sie einen Teil der Funktionalität unterstützen, Windows NT erwartet jedoch, dass Sie alles unterstützen. Unterstützung für dies sollte bald in Samba verfügbar sein. Teile des Codes wurden bereits geschrieben und der Rest befindet sich in der Entwicklung.
Der zweite Punkt, der tatsächlich mit dem ersten Problem verwandt ist, ist, dass Samba das Herunterladen von Druckertreiberdateien nicht unterstützt, wenn ein Client sich erstmals mit einem Drucker verbindet. Werfen Sie einen Blick in Kapitel 8, »Drucker«, wenn Sie diesen Punkt noch einmal durchgehen möchten. Auch hier können Sie die Funktionalität bald erwarten.
Wenn Sie eine Drucker-Spool-Datei von einem NT-Server an einen Samba-Server übertragen, sollte Ihnen klar sein, dass Samba administrative Domänengruppen, wie z.B. die »Druckoperatoren«, nicht im wahrsten Sinne des Wortes unterstützt. Wenn nötig, können Sie eine Art von Unterstützung implementieren, indem Sie den Freigabeparameter valid users benutzen. Abgesehen von diesen Dingen, auf die Sie achten sollten, läuft die Konfiguration Ihres Druckers genau so, wie sie in Kapitel 8 dargestellt wurde. Hier ist die Druckerfreigabe, die ich benutzen werde:
[canon]Natürlich muss ich den Drucker auch korrekt in der lokalen /etc/printcap-Datei konfigurieren.
Ich habe es fast geschafft. Als Nächstes muss ich den Abschnitt [global] der Datei smb.conf konfigurieren. Zunächst nehme ich mir die Parameter vor, mit denen ich bereits sehr vertraut bin: netbios name und workgroup:
[global]Damit erfülle ich die zweite Anforderung, die ich am Anfang dieses Kapitels dargestellt habe: Der Rechner sollte als der gleiche wie der NT-Server auftauchen, wenn er über einen Netzwerk-Browsing-Mechanismus wie die Netzwerkumgebung angesehen wird.
Danach muss ich den Sicherheitsmodus konfigurieren. Aus Platz- und Zeitgründen werde ich nicht detailliert darstellen, wie Domänensicherheit im Netzwerk implementiert wird. Statt dessen sollten Sie mir einfach glauben, dass Samba mit diesem Sicherheitsmodus als vollständiges Domänenmitglied agieren und an Vertrauensbeziehungen teilnehmen kann:
security = domainDamit Samba im Domain-Modus arbeiten kann, muss ich einen Server definieren, der Authentifizierungsanfragen validieren kann, ganz ähnlich wie im Server-Modus. Der Parameter password server funktioniert hier ganz genau so wie mit der Einstellung security = server. Der Passwort-Server sollte der PDC für meine Domäne sein. Habe ich mehrere BDCs (Backup Domain Controllers), könnte ich diese ebenfalls in die Liste einfügen:
password server = QUESOAbschließend muss ich angeben, dass ich verschlüsselte Passwörter verwenden werde, obwohl die Verwaltung einer zusätzlichen smbpasswd-Datei nicht notwendig ist. Dieser Parameter schaltet das Flag in der Antwort zur Protokollverhandlung ein, das anzeigt, ob ich Passwortverschlüsselung unterstütze:
encrypt passwords = yes
Es ist besser, dem Abschnitt [global] Ihrer smb.conf auch die folgenden Parameter hinzuzufügen, es sei denn, Sie wissen ganz genau, was Sie tun:
os level = 0Der Grund dafür liegt darin, dass ein Windows-NT-PDC der Domain-Master-Browser sein muss. Dies wird in Kapitel 19, »Browsing des lokalen Subnetzes«, klarer werden.
Das Einfügen eines Samba-Servers in eine NT-Domäne ist ein Prozess, der in zwei Schritten ausgeführt wird. Derzeit unterstützt Samba nicht die Option, einen Rechner-Account in der Domäne beim Eintritt einzurichten; daher muss ich über den Server-Manager für Domänen einen Account auf dem PDC einrichten. Abbildung 12.3 zeigt den Prozess für das Einfügen eines neuen Servers in die Domäne. Falls Sie sich fragen, warum ich nicht einfach den existierenden Rechner-Account für PICANTE benutzen kann, so liegt das daran, dass der Samba-Rechner keine Ahnung hat, wie das Passwort für den Account lautet. Zwar ist es möglich, diese Information herauszufinden, aber es ist die einfachste Lösung, den Server der Domäne neu hinzuzufügen.
Abb. 12.3: Über den Server-Manager für Domänen einen Rechner-Account in der Domäne CHIPSNDIPS einrichten
Ist der Account eingerichtet, kann ich über das Tool smbpasswd der Domäne beitreten. Es ist sehr wichtig, dass weder smbd noch nmbd laufen, während ich versuche, der Domäne beizutreten. Ich sollte außerdem sicherstellen, dass das Verzeichnis /usr/local/samba/private existiert, da smbpasswd hier das aktuelle Rechnerpasswort für den Samba-Server speichern wird. Um der Domäne tatsächlich beizutreten, geben Sie den folgenden Befehl aus:
# /usr/local/samba/bin/smbpasswd -j CHIPSNDIPS 1999/01/21 22:43:38 : change_trust_account_password: Changed password for domain CHIPSNDIPS.Natürlich sollten Sie CHIPSNDIPS mit dem Namen Ihrer Domäne ersetzen. Jetzt ist es an der Zeit, smbd und nmbd zu starten und die Dinge auszuprobieren.
Die beste Methode sicherzustellen, dass alles korrekt funktioniert, besteht darin, sich in einen existierenden NT-Client einzuloggen und zu sehen, ob alles gleich aussieht. Nachdem ich mich in eine Windows-NT-Workstation eingeloggt habe, überprüfe ich zunächst, dass ich auf mein Home-Verzeichnis zugreifen kann. Abbildung 12.4 zeigt, dass die Netzwerkfreigabe \\PICANTE\users auf Laufwerk H: gemountet ist. Abbildung 12.5 zeigt, dass sogar mein Befehlsprompt im korrekten Verzeichnis startet!
Abb. 12.4: Mein Arbeitsplatz zeigt die aktuellen Netzwerk-Laufwerksverbindungen
Danach überprüfe ich das Netzwerk-Browsing. Der Server PICANTE erscheint in der Browse-Liste in Abbildung 12.6 wie vorgesehen. Nachdem ich sichergestellt habe, dass der Server die korrekte Freigabeliste (siehe Abbildung 12.7) anzeigt, warte ich einfach, ob jemand die Auswechslung der Server bemerkt.
Abb. 12.6: Die Netzwerkumgebung zeigt den aktuellen Rechner für CHIPSNDIPS
Obwohl Samba nicht alle NT-Funktionen unterstützt, kann es einen Windows-NT-Datei- und Drucker-Server in einem existierenden Netzwerk effektiv ersetzen. Samba entspricht den drei Anforderungen, die ich gestellt habe:
Die smb.conf-Parameter netbios name und workgroup ermöglichen es uns, die Identität des alten Servers anzunehmen.
Durch zugelassene Einträge in der /etc/passwd und /etc/group kann ich die Standard-Unix-Berechtigungsbits für die Zugriffskontrolle benutzen.
Es gibt zwei Gründe, warum security = domain besser ist. Erstens kann Samba mit dieser Methode an den Vertrauensverhältnissen der Domäne teilnehmen. Dies ist im Server-Modus nicht möglich. Zweitens muss im Server-Modus jeder smbd-Prozess eine offene Verbindung mit dem Authentifizierungsserver beibehalten. Dies kann einen Windows-PDC schnell überfordern. Im Domain-Modus ist diese Verbindung so lange notwendig, bis die Authentifizierung durchgeführt ist, und so werden wertvolle Ressourcen gespart.
SID - Der Securtiy Identifier, der aus einem Zahlenstring besteht und benutzt wird, um zwischen NT-Rechnern und -Accounts zu unterscheiden.
RID - Eine 32-Bit-Nummer, die Windows NT verwendet, um eine Benutzer-ID mit einem relativen Identifier zu bezeichnen. Die RID wird an die Rechner- oder Domänen-SID angehängt, um den Account vollständig zu qualifizieren.
BDC - Ein Backup Domain Controller ist ein Rechner, der Account-Informationen zur Domäne vom Primary Domain Controller repliziert, um die Last der Authentifizierungsverbindungen zu verteilen.
ACL - Eine Zugriffskontrollliste (Access Control List) ist ein Attribut, das mit Dateien, Verzeichnissen und Druckern verbunden ist und die Möglichkeit zur Manipulation eines bestimmten Objekts einschränkt oder gewährt.