IT-Academy Logo
Sign Up Login Help
Home - Betriebssysteme - Linux - Server/Internet/Netzwerk - Linux als Samba-Server



Linux als Samba-Server

Im diesem Artikel wird beschrieben, wie man Samba als Fileserver einsetzt und eine Domäne aufbaut, an der sich Windows-Clients anmelden können.


Autor: Mario Spänhoff (spaenhoff)
Datum: 23-01-2002, 19:08:10
Referenzen: http://de.samba.org/samba/samba.html
http://www.oreilly.com/catalog/samba/noframes.html
Schwierigkeit: Fortgeschrittene
Ansichten: 17289x
Rating: 4.17 (6x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Möglichkeiten und Einschränkungen

Samba bietet seit der Version 2.0 viele Features, die es erlauben es nicht nur als File- und Printserver, sondern auch als Anmeldeserver einzusetzen. Dabei kann man sogar so weit gehen, Samba als PDC zu nutzen, an dem sich ein Windows-Client anmelden und ein benutzerspezifisches Profil herunterladen kann. Wegen der prinzipiellen Unvereinbarkeit (s.u.) von Windows und Unix gibt es allerdings noch eine Menge Funktionen, die in Samba noch nicht oder nur teilweise implementiert sind. Das Samba Team arbeitet jedoch daran, so dass es hoffentlich bald möglich sein wird, Samba als echten Ersatz zum NT-Server zu Nutzen.

Bei Fragen und Problemen zur NT-Domänen Funktionalität findet sich neben der NT-Domänen FAQ für Samba noch eine Fülle von Informationen in den Mailinglisten auf dem Samba Server. Auch in der Samba Dokumentation sind einige Textdokumente über diesen Punkt zu finden, z.B. DOMAIN.txt.

So gibt es z.B. bei den folgenden Punkten noch Schwierigkeiten bzw. Einschränkungen:

  • Die Verwaltung von Samba über die NT-Werkzeuge: Da etliche Remote Procedure Calls (RPCs) noch nicht implementiert sind, lässt sich der Sambaserver weder mit dem Benutzermanager für Domänen (Benutzerverwaltung), noch mit dem Server Manager(Computerkonten), noch mit dem Explorer (Berechtigungen für Dateien und Freigaben) verwalten.

  • Replikation für BDCs: Man kann keine Server (NT oder Samba) als BDCs einrichten, da die Replikationsmechanismen hierfür fehlen.

  • Benutzerlisten für bestimmte Freigaben: In Samba gibt es noch keine Möglichkeit, sich Benutzerlisten für bestimmte Resourcen anzeigen zu lassen und diese gezielt zu manipulieren. Dies lässt sich nur indirekt über die smb.conf realisieren.

Desweiteren gilt es beim Einsatz von Samba als PDC zu beachten, dass man viele Verwaltungsprogramme für NT-Domänen, die für den NT-Server existieren, nicht nutzen kann, wie z.B. den Systems Management Server (SMS).

Meiner Meinung nach ist Samba eine sinnvolle Alternative, wenn es entweder um kleine Netze geht, die eine zentrale Benutzerverwaltung und Roaming Profiles haben sollen oder um Unixnetze, in denen auch Windows Clients mit eben diesen Möglichkeiten genutzt werden sollen. Ansonsten macht Samba lediglich als reiner File- und Printserver Sinn, erhält man doch mit Linux ein günstiges, Hardwaresparendes und gut skalierbares System erhält, dass sich in Punkto Leistung in jedem Fall mit dem NT-Server messen kann und in Punkto Stabilität und Administrationsmöglichkeiten diesen sogar übertreffen kann. Für ganz große Windows-Domänen ist Samba meiner Meinung nach (noch) nicht die ideale Lösung.

Soll Samba als Fileserver dienen, so stellen sich für den Rechner auf dem es läuft keine besonders hohen Hardwareanforderungen (jedenfalls solange er nur als Fileserver dient), es ist jedoch sinnnvoll den Rechner aufgrund der guten Erweiterbarkeit und Performance (Beschleunigung durch Parallelzugriffe und im allgemeinen geringfügig schnellere Platten) als SCSI System aufzubauen. Im Gegensatz zur CPU-Leistung braucht ein solcher Fileserver nur ein paar Extrabyte RAM, da eine neue Instanz des smbd für jeden Benuzter gestartet wird und zwischen 300 und 600 kbyte Speicher verbraucht. Bei einem kleinen Netz von ca. 30 Rechnern reicht also ein Pentium 100-Rechner mit 32 Megabyte eigentlich aus (0.5 MB*30 + 16 MB Basis), jedenfalls solange keine grafische Oberfläche läuft.

Grundlegende Unterschiede zwischen Unix und Windows(NT)

Bei der Entwicklung von Samba gilt es, mehrere grundlegende Unterschiede zwischen Windows, insbesondere NT, und Unix zu bedenken, die eigentlich für eine Unvereinbarkeit der beiden Betriebssystemwelten sprechen.

Einer der wichtigsten Unterschiede sind die Zugriffsrechte auf Dateiebene. Während unter Unix hierfür die Dateiattribute, die für die Benutzer bzw. die Gruppen gelten, zuständig sind, existieren unter NT sogenannte Access Control Lists (ACL) die seperat gemanaget werden (z.B. über den Explorer bzw. den Benutzermanager).

Neben den Dateiattributen sind auch die Dateinamen und der Zeitstempel in DOS/ Windows und Unix unterschiedlich, weshalb man Samba dementsprechend konfigurieren muss. Windows und DOS wurden nicht für lange Dateinamen konzipiert, weshalb Microsoft hier ziemlich viel basteln musste, um die Fähigkeit Namen mit bis zu 255 Zeichen zu verwenden bereitzustellen. Obwohl Windows ab Version 95 dies beherrscht, verwaltet es zu jeder Datei 2 Namen, einen kurzen und einen langen, unterscheidet dabei aber nicht zwischen Groß- und Kleinschreibung, während NT dies wiederum beim Speichern tut. Unix kann von Haus aus Dateien mit langen Namen und gemischter Groß- und Kleinschreibung verwalten, daher muss eine Konvertierung stattfinden. Samba ist von Haus aus so eingestellt, dass es mit den Eigenheiten der Systeme umgehen kann und z.B. nicht zwischen Groß- und Kleinschreibung unterscheidet. Deshalb muss Samba dann immer eine Suche nach passenden Namen durchführen, falls ein Windows Client z.B. eine Datei namens 'hallo' anfordert, die aber in Wirklichkeit 'Hallo' heißt. Die Optionen hierzu lauten 'mangle case', 'case sensitive', 'default case', 'preserve case' und 'short preserve case', die standardmäßig so eingestellt sind, wie ein NT-Server.

Aus mir völlig unverständlichen Gründen speichern DOS/Windows Dateizeitstempel nur auf zwei Sekunden genau, während Unix das sinnvollerweise genau erledigt. Da es Programme gibt, die mit dieser Genauigkeit Probleme haben, kann man Samba anweisen, die 'dos filetime resolution' und 'dos filetime' zu verwenden. Mit dem Parameter 'time server = yes' können sich Microsoft Clients die Systemzeit vom Server holen (net time /set /yes an der Eingabeaufforderung).

Ein weiterer Unterschied besteht in der Art Passwörter zu verschlüsseln. Windows und Unix arbeiten zwar beide nach dem Prinzip der 'Einweg-Verschlüsselung'1, dennoch ist der Verschlüsselungsalgorithmus unterschiedlich, und das bedeutet, dass Samba ein NT-Passwort nicht mit einem Unix-Passwort abgleichen kann. Will man die verschlüsselte Passwortübertragung verwenden (was in Windows ab Version 95b standardmäßig vorgesehen ist, sich aber durch Änderungen an der Registry umgehen läßt, siehe WinNT.txt in, macht dies eine eigene Datenbank für Samba Accounts erforderlich.

Anlegen einer Benutzerdatenbank

Will ein Windows Benutzer einen eigenen Zugang haben, muss er zunächst auch als Linuxbenutzer einen Eintrag in der Datei /etc/passwd haben. Soll sich der Benutzer nur per SMB-Client am Samba Rechner anmelden können und nicht unter Linux, genügt es, seine Shell auf '/bin/false' zu setzen, zusätzlich kann man ihm die Eingabe eines gültigen Passworts durch Setzen dieses auf z.B. '-1' unmöglich machen.

Die Benutzerzuordnung findet entweder über den Benutzernamen statt oder über eine Zuordnungsdatei, welche einen oder mehrere Windowsbenutzer auf einen Unix Account mappt. Kann man auf eigene Profile bzw. Passwörter für einzelne Benutzer verzichten, so trägt man in einer Datei, deren Name und Pfad in der smb.conf durch den Parameter 'username map' festgelegt wird, z.B. Folgendes ein:

root = administrator
pitti = "Peter Schmidt";
schueler= alexander, carsten, sabrina, mario

Nun kann man ihm mit dem Programm smbpasswd einen Samba Account erzeugen bzw. dessen Passwort ändern: smbpasswd -a -e username fügt einen neuen Account hinzu (-a) und aktiviert ihn (-e).

Berechtigungen für Freigaben

Wie bei NT kann man für den Zugriff auf Freigaben bestimmte Benutzer mit unterschiedlichen Rechten ausstatten. Allerdings müssen hierfür sowohl die Unix- als auch die Sambaberechtigungen aus der smb.conf stimmen.

Unter Samba sind hierfür folgende Parameter zuständig:

writeable = yes/write ok = yes/read only = no:

Hier hat man die Wahl zwischen 3 Parametern, die alle die gleiche (bei read only invertierte) Bedeutung haben. Der Parameter bestimmt, ob ein Verzeichnis generell zum Schreiben (Erzeugen und Ändern von Dateien/Verzeichnissen) freigegeben ist oder nicht. Wird das share auf schreibgeschützt gesetzt, kann es mit der write list für bestimmte Benutzer wieder zum Schreiben freigegeben werden. Die Voreinstellung lautet 'writeable = no'.

valid users/invalid users:

Hiermit kann man eine Liste der Benutzer angeben, die überhaupt Zugriff auf das share haben, bzw. keinen Zugriff haben. Gruppen lassen sich mit einem vorangestellten '@' kennzeichnen ('valid users = @schueler'). Der Standardwert ist jeweils eine leere Liste, was zur Folge hat, dass jeder zugreifen kann.

read list:

Mit der read list lässt sich angeben, wer Dateien/Verzeichnisse eines shares lesen kann. Gruppen können ebenfalls angegeben werden. Der Standardwert ist eine leere Liste, jeder kann lesen.

write list:

Hiermit kann ein share nur für bestimmte Benutzer schreibbar gemacht werden. Ist ein Benutzer auch in der read list, erhält er hierdurch trotzdem Schreibrechte. Gruppen lassen sich ebenfalls angeben. Der Standardwert ist auch hier eine leere Liste, also jeder kann schreiben.

Durch Kombination dieser Parameter lassen sich relativ genau bestimmte Benutzer/Gruppen festlegen bzw. gezielt ausschließen.

Beim Erstellen von Dateien und Verzeichnissen muss festgelegt sein, was für Berechtigungen diese haben. Dazu dienen die Parameter 'create mask' und 'force create mode' für Dateien und 'directory mask' und 'force directory mode' für Verzeichnisse. Ebenso lassen sich die Besitzverhältnisse der Dateien mit den Parametern 'force group' und 'force user' festlegen. Der Parameter 'force group' legt auch fest, welcher Gruppe eine Datei gehört, deren Besitzer in mehreren Gruppen ist, kann aber auch ein Sicherheitsloch bergen. Man kann damit, vorbei an den Unixrechten, einem User der einer Gruppe gar nicht angehört das Recht einräumen, auf Dateien dieser Gruppe zuzugreifen, er gibt sich also gegenüber Unix als Mitglied dieser Gruppe aus. Informationen zu diesen Parametern kann man in der man-page zu smb.conf nachlesen.

Auf einem Fileserver wird man in der Regel drei Arten von shares haben: Homeverzeichnisse, Gruppenverzeichnisse und öffentliche Verzeichnisse. Für alle Freigaben gilt, dass die Unixrechte der Freigaben (und der darüber liegenden Verzeichnisse) den Einträgen in der smb.conf entsprechen müssen, was normalerweise bedeutet, dass die Rechte mit denen Werten von 'create mask' und 'directory mask' übereinstimmen müssen und alle Verzeichnisse darüber das Ausführbit (wechseln) für alle gesetzt haben.

Homeverzeichnisse haben in der Regel die Unixrechte 700 und gehören dem Benutzer und seiner primären Gruppe. Die Sicherheit lässt sich erhöhen, wenn man 'valid users = %s' setzt, wobei %s durch den Namen des jeweiligen Benutzers ersetzt wird. Ein Gruppenverzeichnis hat normalerweise die Rechte 770, wobei der Besitzer unixseitig keine Rolle spielt, nur die Gruppe. Ein öffentliches Verzeichnis soll für alle zugänglich sein, auf Wunsch auch ohne Passwortsicherung ('guest ok = true'). Die Unixrechte sollten 775 oder 755 sein.

Domänenintegration

Will man eine windowskompatible Domäne aufbauen, kommt man wegen des Sicherheitskonzeptes (SID, Security Identifier, eine eindeutige Benutzerkennung, die sowohl der Server als auch jeder Client besitzt) nicht umhin, ein Computerkonto für jeden PC anzulegen. Dieses entspricht, bis auf kleine Abweichungen, einem normalen Benutzerkonto.

Zunächst ist es nötig, in der Datei /etc/passwd einen Benutzer mit dem Namen der Workstation und einem angehängeten $ Zeichen zu erstellen. Dies ist nur nötig, um eine UID zu erhalten, deshalb sollten diese auch nicht mehrfach verwendet werden. Die Shell und das Homeverzeichnis können disabled werden:

BART$:801:800:NT Workstation:/dev/null:/bin/false
MAGGIE$:802:800:NT Workstation:/dev/null:/bin/false

Nun werden die Sambakonten angelegt: smbpasswd -a -m bart. Standardmäßig hat der Computer ein Passwort, das seinem NetBIOS-Namen in Kleinschreibung entspricht. Dieses ändert er, wenn er der Domäne beitritt, indem er auf Basis des alten Keys und eines Zufallswertes ein neues Passwort erstellt. Deshalb muss man, will man den PC neu in die Domäne aufnehmen, das Passwort der Maschine am Server reseten, z.B. durch Löschen und Neuaufnehmen des Accounts in die smbpasswd.

Falls noch nicht geschehen, muss man nun in der smb.conf die Option 'domain logons = yes' setzen, und als 'workgroup' den Namen der Domäne eintragen. Beim nächsten Starten des smbd wird dann eine Datei namens MACHINE.SID erzeugt, die gut aufbewahrt werden sollte, wenn man abgeneigt ist alle Computer neu in die Domäne aufzunehmen.

Nun muss man an der NT Maschine in den Netzwerkeigenschaften als Domäne den Namen der Domäne eintragen und wird dann hoffentlich in dieser willkommen geheissen. Die Möglichkeit, ein Computerkonto direkt aus diesem Dialog heraus anzulegen, wird allerdings zur Zeit noch nicht unterstützt.

Nach einem Neustart kann man sich dann an der Domäne anmelden, natürlich nur mit einem gültigen Domänenmitgliedsaccount (Samba Benutzer). Durch die Aufnahme in die Domäne sind auf dem lokalen PC zwei weitere Benutzergrupen hinzugefügt wurden, die 'Domänenadmins' und die 'Domänenbenutzer'. Welche Unix Benutzer/Gruppen diesen Gruppen angehören, regeln die Parameter 'domain admin group' bzw. 'domain admin user' und 'domain group'.

Natürlich kann ein Samba Server auch einer bereits existierenden Domäne beitreten, er braucht dann lediglich ein Konto auf dem PDC (Samba oder NT) und kann dann auf Wunsch auch die Passwortvalidierung an NT-Server weiterreichen. Das Kommando hierzu lautet smbpasswd -j Domänenname und bedingt folgende Einstellungen in der smb.conf:

security = domain
workgroup = "GCL-Schule"
NTBDC2

(Wandernde) Benutzerprofile für Windows NT-Clients

Benutzerprofile sind sowohl Einstellungen eines Benutzers (z.B. Hintergrundbild) als auch seine persönlichen Ordner (z.B. das Startmenü) und Dateien (Eigene Dateien, Desktopsysmbole). Bei der Verwendung von wandernden Profilen erhält jeder User an jedem PC, an dem er sich anmeldet, das gleiche Profil, das beim Abmelden auf den Server zurückgespeichert wird.

Die Profile liegen auf einem share namens 'profiles', das wiederum im netlogon Pfad liegt. Mit dem Parameter 'logon path' gibt man den Pfad zum profiles share an, das man ebenfalls in der smb.conf definiert hat. Wegen eines Problems mit Windows ist es nicht sehr ratsam das Profil im Homeverzeichnis eines Benutzers abzulegen. Es empfielt sich deshalb, ein seperates share `profiles' anzulegen. Dieses share muss sowohl browseable als auch writeable für alle Benutzer sein, solange neue Benutzerprofile dazukommen sollen.

Wenn sich der Benutzer zum ersten mal anmeldet, wird sein Profilverzeichnis erzeugt, das durch den 'logon path' angegeben wurde. Dieses ist dann nach den Regeln für das share 'profiles' ('create mask 700', 'directory mask 700') nur für ihn lesbar, schreibbar und ausführbar, dasselbe gilt für alle darin beim Abmelden erzeugten Einträge des Profils.   Für NT-Clients ist der Parameter 'logon drive' sinnvoll, besonders in Verbindung mit dem Parameter 'logon home'. Folgende Einstellungen bewirken, dass der Benutzer beim Anmelden sein Unix-Homeverzeichnis als Laufwerk p: gemountet bekommt:

logon drive = p:
logon home = \\%L\%U

Bestehende Profile lassen sich von NT aus über die Systemeigenschaften (Reiter Benutzerprofile) auch nachträglich in servergespeicherte Benutzerprofile umwandeln, was z.B. die Umstellung von Arbeitsgruppen auf Domänen unter Beibehalt der Profile möglich macht.

Benennt man die Datei NTuser.DAT im Profilverzeichnis in NTuser.MAN um, erhält man ein sogenanntes verbindliches Profil, das der Benutzer zwar ändern kann, aber ohne das diese Änderungen gespeichert werden, d.h. sie sind beim nächsten Start wieder verschwunden.

Will man neben Profilen auch Anmeldeskripten und/oder Policies verwenden, muss ein share namens 'netlogon' erzeugt werden, das für alle User lesbar aber nicht beschreibbar ist. Für Anmeldeskripten muss der Parameter 'logon script' im global-Teil auf eine Batch-Datei auf diesem share verweisen. Diese kann für alle User gelten oder für jeden User/jeden PC individuell (z.B. 'logon script scripts%U.bat', das %U wird durch den Namen des aktuellen Benutzers ersetzt, weitere Ersetzungsmakros sind in der man-page zu smb.conf beschrieben). Beim Erstellen der Skriptdateien ist darauf zu achten, diese im DOS Format (cr/lf) zu speichern, am besten mit einem DOS Editor. Während des Anmeldens wird das share netlogon als Laufwerk z: gemountet, man kann hier also auch Programme ablegen, die beim Anmelden ausgeführt werden sollen.

Windows 95 spezifisches

Will man Profile für Windows 95 (bzw. Windows 98) verwenden, muss man zusätzlich folgendes beachten: Die Datei, in der die Benutzereinstellungen gespeichert werden heisst hier user.DAT und kann für verbindliche Profile in user.MAN umbenannt werden. Die Einstellung am Client erfolgt dann unter Netzwerkeigenschaften Eigenschaften des Client für 'Microsoft Netzwerke', wo man die Domäne angeben kann, an der man sich anmelden will. Zusätzlich kann man in der Systemsteuerung unter Kennwörter auch festlegen, welche Einstellungen in das Profil miteinbezogen werden und ob überhaupt Profile gelten sollen.

Die Profile werden dann jedes mal, wenn sich der Benutzer anmeldet, von dem Server geholt, der für die definierte 'Primäre Netzwerkanmeldung' zuständig ist und abgeglichen; jeweils die neusten Dateiversionen überleben.

Beim nächsten Anmelden ist neben den Feldern Benutzerkennung und Passwort auch ein Feld Domäne verfügbar, in dem dann die angegebene Domäne eingetragen sein sollte.

Passwortsynchronisation zwischen Windows und Linux

Zwei Datenbanken für die Unix- und die Windowsbenutzer verwalten zu müssen, ist schon schlimm genug, da kann man auf das Durcheinander, was durch zwei unterschiedliche Passwörter verursacht wird, gern verzichten. Dazu ist es nötig, dass beim Ändern des Passworts in einem der Systeme auch das des anderen mitgeändert wird.

Eine einfache Möglichkeit hierzu bietet der Parameter 'unix password sync'. Folgende Einstellungen in der Datei smb.conf bewirken, dass wenn ein User sein SMB-Passwort ändert (entweder über den NT-Dialog oder über das Programm smbpasswd), sein Unix-Passwort auch gleich mitgeändert wird. Das Passwortprogramm wird allerdings mit Rootrechten aufgerufen, weshalb man hier aufpassen muss.

unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *password* %n\n *password* %n\n *changed*

Die Parameter für die beiden unteren Zeilen müssen evtl. anders gewählt werden. Weitere Informationen zu den Optionen finden sich in der smb.conf man-page.

Man kann sogar auf den Einsatz einer Unix-Passwortdatenbank ganz verzichten, wenn man das PAM-Modul pam_smb benutzt. Dann wird auch jeder Unixbenutzer am SMB-Server authentifiziert.

Weitere Sicherheitsmaßnahmen

Neben dem Einsatz einer Firewall gegen Angriffe aus anderen Netzen kann man den Zugriff auf shares im Rahmen der Sambakonfiguration nochmals einschränken, indem man es nur bestimmten IP-Adressen erlaubt zuzugreifen. Der Parameter 'hosts allow' legt fest, dass nur bestimmte Rechner zugreifen, entweder mit einem ganzen Subnetz als Angabe oder einzelnen IP-Adressen. Die Angabe 'hosts allow 192.168.1.0/255.255.255.0' legt beispielsweise fest, dass nur Rechner aus diesem lokalen Netz zugreifen können. Zusätzlich kann man mit 'hosts deny' gezielt Rechner und IP-Bereiche ausschliessen. Es lassen sich natürlich jeweils auch Rechnernamen angeben, sofern eine Namensauflösung der IP-Adressen eingerichtet ist. Diese Regeln kann man sowohl global als auch für einzelne Shares festlegen, was eine sehr detaillierte Freigabe von Ressourcen möglich macht.

WINS Server

Wie in bereits beschrieben, kann sich in großen Netzen ein WINS-Server lohnen und ist in gerouteten Netzen unabdingbar. Steht kein NT-Server zu Verfügung (den man dann lieber dem Samba Server vorziehen sollte), kann Samba die Rolle des WINS-Server und des LMBs übernehmen. Die Einstellungen

wins support = yes
wins proxy = yes
local master = yes
preferred master = yes
os level = 6

machen Samba zum Herrscher über die Namensauflösung und Browselisten,

wins support = no
wins server = 192.168.1.1

überlassen das einem anderen Server. Wichtig ist, dass es nur einen primären WINS-Server im Netz geben darf, auch Rechner in Subnetzen müssen dann auf diesen eingestellt werden.

Performance Tuning

Hat man etliche Tage mit der Konfiguration von Samba verbracht (heute schon gesichert?), kann man daran gehen die Geschwindigkeit zu optimieren. Mit der Option 'oplocks yes' kann man Samba anweisen, Schreibzugriffe auf eine Datei erst dann auszuführen, wenn andere Clients auch auf die Datei zugreifen wollen, also eine Art Schreibcache.

Durch Setzen von 'write raw yes' und 'read raw yes' lässt sich die Geschwindigkeit weiter steigern (lieber nur bei guten Netzwerkkarten).

Die Einstellung 'socket options TCP_NODELAY' bewirkt, dass die Unixpufferung der TCP/IP Pakete umgangen wird, da SMBs häufig kleine Pakete sind.

Mit dem Parameter 'getwd cache yes' kann man einen Cache für Verzeichnis Lookups aktivieren, was diese beschleunigt, aber zu Lasten des Speicherverbrauchs geht. Da somit aber der Speicherverbrauch pro angemeldetem Benutzer steigt, ist es eine gute Idee, die Zahl der Benutzer durch Trennen der nicht aktiv verbundenen zu verkleinern, was durch die Einstellung 'deadtime' möglich ist, die man z.B. auf einen Wert von 10 (Minuten) setzen kann. Die Clients können sich dann jederzeit durch einen Reconnect wieder mit dem Server verbinden, was der Benutzer dann nicht einmal mitbekommt.

Weitere Informationen zum Tunen von Samba lassen sich in der Samba-Dokumentation unter Speed.txt und Speed2.txt finden.

Beispielkonfiguration

Hier ein Beispiel für eine smb.conf die viele der oben angestellten Überlegungen berücksichtigt:

[global]
Domänenname
workgroup = "GCL-Schule"
security = user
encrypt passwords = yes
domain logons = yes
Verwaltungsgründen nicht so sinnvoll, hier nur als
server string = Linux Samba Server 2.0.6 Testumgebung
aktuelle
Loginscript jedes Users wird im Unterverzeichnis scripts
script = scripts\%U.bat
Zugriffe aus unserem Netz
hosts allow = 192.76.150.0/255.255.255.0

Server im Netz hängt, soll dieser
= 192.75.150.4 Anmeldeskript den entsprechenden net Befehl einbauen
abgleichen
timeserver = yes

yes
read raw = yes
socket options = TCP_NODELAY
getwd cache = yes
deadtime = 10

[homes]
comment = Home Verzeichnisse
browseable = no
writeable = no und seine primäre Unix Gruppe
write list = %U
0750

[netlogon]
comment = Netlogon Share (readonly)
path = /home/netlogon

[profiles]
yes
writeable = yes
create mask = 0700
directory mask = 0700

[pub]
/home/pub
sollen Zugriff haben
public = no 0777
create directory = 0777

[lehrer]
comment = nur für Lehrer lesbar und schreibbar
path = /home/lehrer
writeable = no
valid users = @lehrer
write list = @lehrer
create mask = 0750
create directory = 0750

[schule]
comment = halb Öffentlich /home/schule
writeable = no
write list = @lehrer, @verwaltung
valid users = @lehrer, @schueler, @verwaltung, @referendare
create mask = 0755
create directory = 0755




[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06246
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1154
Comments: 0