Auf der Arbeit sind wir netzwerktechnisch ein Entwicklungsland: File-Server? Nada. Domäne mit Active Directory? Neumodisches Zeugs. Erst in letzter Zeit erreichen die Datenmengen aber ein kritisches Mass und der Zugriff auf selbe Daten über das Netzwerk wird immer mehr nachgefragt.
Bisher waren die wenigsten willig, einen Server anzuschaffen, weshalb man sich darauf beschränkte, Dateien zwischen Clients auszutauschen – mit allen Fallstricken und Unzulänglichkeiten (heterogene Umgebung: Mac OS X, Windows 2000, Windows XP Home, das nur die störende „einfachen Dateifreigabe“ mitbringt, Windows XP Professional). Nach einer gewissen Zeit mit dieser suboptimalen Lösung sind Entscheidungsträger bald bereit, etwas „brauchbareres“ auf die Beine zu stellen: Den eigenen File-Server.
Für mich ist klar, dass so etwas (jedenfalls auf die Software bezogen) möglichst wenig kosten sollte. Und so kommt man hier um Linux nicht herum, wenn man sich nicht mit Microsoftschen CALs oder einem Hardware-Zwangskauf bei Apple herumschlagen möchte.
Obwohl ich Debian bevorzuge, würde diese Distribution – wie viele andere auch – einiges an Handarbeit von mir verlangen. Ausserdem wäre ein GUI in diesem Falle von Vorteil, damit ich gewisse administrative Aufgaben (das Erfassen von Benutzern, das Ändern von Passwörtern) an die Gruppenverantwortlichen abgeben könnte. Ich hoffe nur, das sich mich so nicht in den Schlamassel reite …
Jedenfalls informierte ich mich überblicksartig über die momentane Marktsituation an Open-Source NAS-Software und wurde doppelt fündig:
- FreeNAS – basierend auf FreeBSD
- Openfiler – basierend auf CentOS/rPath Linux
- Nachtrag: NASLite – rudimentär; die benötigten Features (User-Management, Quota etc.) fehlen in der kostenlosen Version
Entschieden habe ich mich der Lektüre einiger Blog-Beiträge für Openfiler, da es dort als „reifer“ als FreeNAS charakterisiert wurde. Ausserdem wäre es von Vorteil, wenn der TSM-Client installiert werden könnte. Von diesem habe ich nur Linux-RPMs.
Tücken bei der Installation
Zuerst einmal erstaunte mich, dass das Booten ab der Installationsdisk keinerlei Probleme bereitete (Kernel 2.6.x erkannte den Intel SATA-Controller ohne Mühe).
Leider schweigt sich der Installer aber bei der Partitionierung über das richtige vorgehen aus. Wer – wie ich bei diesem Kleinprojekt – nur eine fette Festplatte im Rechner sitzen hat, kommt um eine manuelle Partitionierung nicht herum. Führt man die automatische Einteilung der Festplattenbereiche aus, gibt es später keinen Platz zum Erstellen der Volumengruppe(n) (/ belegt dann neben der /boot und SWAP-Partition einfach den übrigbleibenden Platz). Deshalb hier mein Rat:
- /boot – 100MB
- / (Root) – 4096MB
- SWAP – 1024MB
conary updateall
Wer denkt, dass die Installations-Disk bereits alle nötigen Programme und Einstellungen enthält, täuscht sich. Will man mit Openfiler so richtig loslegen, muss das System nun zuerst noch über das Internet „aktualisiert“ werden. Hierzu ruft man den Befehl
conary updateall
auf.
Proxy?
Wer wie ich hinter einem Proxy sitzt, beisst sich die Zähne aus, wenn er das Einmaleins der Proxy-Konfiguration unter Linux nicht oder nur ungenügend kennt. Wichtig ist vor dem Ausführen obigen Befehls, eine Umgebungsvariable zu setzen:
export http_proxy="http://proxy.domain.tld:80/"
Wobei ich zuerst vergass, den export auszuführen. Das setzen der Variable alleine bringt noch nichts, sie muss auch noch exportiert werden (was auch immer das bedeutet/bewerkstelligt).
Lokaler LDAP
conary updateall bewirkt, dass unter Services nun plötzlich noch einige neue Einträge dazukommen, unter anderem auch LDAP. Dies benötigt man, um eine selbständige (= lokale) Benutzerverwaltung aufzusetzen.
Folgende Einstellungen müssen unter Services > LDAP Settings gemacht sein, bevor man den Service unter Services mit Enable aktivieren kann:
Base DN: dc=openfiler,dc=nas Root bind DN: cn=Manager,dc=openfiler,dc=nas Root Password: ***
Wer will, dass die Benutzer über dieselbe, aber etwas abgespeckte Web-Oberfläche ihr Passwort ändern können, aktiviert zudem Allow users to set password.
Danach wechselt man auf Account > Authentication und gibt folgende Angaben ein:
[X] Use LDAP
[ ] Use TLS
Server: 127.0.01
Base DN: dc=openfiler,dc=nas
Root bind DN: cn=Manager,dc=openfiler,dc=nas
Root bind password: ***
[X] Login SMB server to root DN
[ ] Use Windows Domain controller and authentication
...
Domain / Workgroup: WORKGROUP
...
(Das Häkchen bei Login SMB server to root DN ist nach einem Reload nicht mehr gesetzt, LDAP scheint aber trotzdem zu funktionieren).
Wie hiess mein Share noch gleich?
Beim Erstellen von Shares sollte man darauf achten, bei Override SMB share name den gewünschten Namen einzutragen (bei mir steht in diesem Formular drei Mal dasselbe). Ansonsten werden die Namen der Shares aus dem Volumennamen zusammengesetzt (bspw. \\192.168.0.1\main.staff.Test).
GUI und Usability
Die Oberfläche kommt auf den ersten Blick aufgeräumt daher. Die Einteilung der Rubriken erscheint (grösstenteils) logisch, die Bedienung ist simpel. Manchmal ist die Aufteilung dennoch verwirrend:
Die Einstellung für die Samba-WORKGROUP suche ich vergebens unter Services > SMB Settings. Dort kann man vieles einstellen, das aber nicht. Ich versuche dann, per SSH auf File-Ebene die Vorlagen-Datei zu suchen und die Workgroup dort manuell einzutragen. Das schlägt leider fehl, anscheinend wird die gefundene Datei nicht zur Generierung der smb.conf herangezogen.
Erst am zweiten Tag entdecke ich in einem Forumsbeitrag den wesentlichen Tipp: Diese Einstellung ist unter Authentication zu machen, so unlogisch es klingt. Zwar habe ich dort LDAP aktiviert, die Einstellungen unter Active Directory werden aber dennoch berücksichtigt; jedenfalls, wenn man dort eine Workgroup setzt.
Auch ist die starke vertikale Aufteilung störend. Eine horizontale Leiste mit Buttons würde die Bedienung (teilweise!) optimieren. Komisch finde ich zuweilen, dass mal Buttons, mal normale HTML-Links als Befehle daherkommen. Eine gewisse Konsistenz wäre hier von Vorteil.
Ein kurzer Blick auf den (PHP-)Code
Naja … Umwerfend finde ich ihn nicht gerade, den PHP-Code (ich habe mir zwei Files angeschaut). Ob das durchgehend so ist, entzieht sich aber meiner Kenntnisse. Aber es scheint jedenfalls zu funktionieren.
Kleine Community
Verglichen mit Debian oder PHP verfügt Openfiler über keine grosse, aktive Nutzergemeinde, die sich gegenseitig unterstützt. Es gibt ein (schlecht besuchtes) Forum sowie eine Mailingliste, auf der sich das Geschehen moderat in Grenzen hält.
Bugs
- Home-Directories für die Benutzer werden nicht erstellt, obwohl diese Option unter Services > SMB Settings aktiviert wurde. Leider konnte mir bei diesem Problem noch niemand helfen. Nachtrag: Der Fehler wurde mittlerweile gefunden. Wer es wagt, legt Hand an das entsprechende PHP-Script an und hardcodet die Variable in die entsprechende Zeile.
- Zugriffsprobleme mit Windows 2000 (vgl. Screenshot). Mit Windows XP und Mac OS X klappte alles vorzüglich. Was war das Problem? Windows 2000 scheint mit einem fehlenden Workgroup-Namen mächtig ins Straucheln zu geraten. Sobald die Workgroup eingetragen war, liessen sich die Shares (\\192.168.0.1\Share) resp. der Überblick über die Shares (\\192.168.0.1) ohne Komplikationen anzeigen. Mysteriös!
