SuSE Linux Standard Server 8 - Erfahrungsbericht

Seit Mitte September bietet die SuSE Linux AG den SuSE Linux Standard Server (SLSS) 8 an, der eine Vielzahl von Funktionen bieten soll. Neben der Nutzung als Gateway-, Mail- oder DNS-Server soll die Softwarelösung zum Betrieb eines Samba PDCs eingesetzt werden können. Mit dem neuen »Wollmilchsau«-Server will SuSE in erster Linie das »Small Business«-Marktsegment erobern. Der Kaufpreis von stolzen 520,00 EUR (inkl. MwSt.) enthält ein Jahr Maintenance Support von SuSE. Mit Erwerb des Paketes erhält der Käufer eine Box mit insgesamt vier CDs, zwei Handbüchern und dem Maintenance-Coupon. Drei der CDs enthalten die aktuelle Version von United Linux, die vierte den eigentlichen Standard Server.

Die Installation erfolgt von der Standard Server CD. Die Installationsroutine erinnert wie auch bei United Linux an SuSE 8.1. Somit stehen für die Grundkonfiguration die von Yast2 gewohnten Menüpunkte zur Verfügung. Die dort angebotenen Partitionierungsvorschläge sind sinnvoll und entsprechen den Anforderungen an den zu installierenden Server. Also habe ich zunächst versucht, die Paketauswahl festzulegen. Diese enthält neben den eigentlichen Konfigurationsprogrammen das X-Window System und KDE. Leider können letztere Pakete über Yast2 nicht abgewählt werden. Warum SuSE diese Möglichkeit nicht bietet, ist fraglich, da der Server komplett über ein Web-Frontend wartbar ist. Außerdem möchte ich nicht, daß auf meinem Server eine grafische Benutzeroberfläche wie KDE läuft, da diese weitere Angriffsmöglichkeiten von außen eröffnet.

Als Bootmanager wird allein GRUB angeboten. LILO-Liebhabern bleibt nur die nachträgliche Installation (jaja, ich weiß - Grub kann viel mehr).

Die Uhrzeit habe ich auf Systemzeit umgestellt und daraufhin die Paketinstallation angestoßen.

Nach dem ersten Neustart können essentielle Angaben wie das Root-Paßwort vergeben und Hardwarekomponenten wie Netzwerkkarten konfiguriert werden. Zusätzliche Benutzer können während der Installation nicht angelegt werden, da Benutzerdaten nur noch über das Web-Frontend in die LDAP-Datenbank eingepflegt werden sollen.

Darauf folgen SLSS-spezifische Konfigurationsdialoge, in denen abgefragt wird, ob der Server als Gateway fungiert, ob DNS aktiviert werden soll oder Samba mit PDC-Funktionalität genutzt werden soll. Der Anwender sollte genau wissen, welche dieser Dienste er später anbieten möchte, da die Einstellungen nachträglich nicht ohne Linux-Kenntnisse geändert werden können (SuSE wirbt damit, daß man nur über die Kenntnis der IP-Adresse verfügen muß, um den Server installieren zu können). Falls der Server als Gateway dienen soll, wird nach der Zugangsart und den Providerdaten gefragt. Diese können allerdings später über Yast2 geändert werden.

Nach erfolgreicher Konfiguration startet der SLSS in KDE, an dem man sich als Benutzer Root anmelden muß.

Auf dem Desktop findet sich dort ein übergroßes Icon, das auf die Standard Server Konfiguration hinweist (scheinbar hält SuSE seine Anwender für sehbehindert oder für Nutzer von 21-Zoll-Monitoren). Mit einem Mausklick öffnet sich Mozilla mit der Möglichkeit zum HTTPS-verschlüsselten Login.

Da ich wie gesagt kein Freund von KDE auf Linux-Servern bin, habe ich nur schnell einen Benutzer angelegt und daraufhin die Runlevelkonfiguration auf 3 gestellt, so daß X nicht mehr gestartet wird.

Die weitere Konfiguration habe ich dann via HTTPS über einen entfernen Rechner im Netzwerk vorgenommen.

Dazu habe ich das Konfigurationshandbuch zur Hand genommen, in dem mich schon die ersten Seiten erschreckten. Dort steht als Hinweis so etwas wie: Wählen Sie bitte als Domainname für den Server eine offizielle TLD anstatt einer .local Domain. Um sicherzugehen, daß die Domain noch nicht registriert ist, kann der Denic-Dienst genutzt werden.

Ich finde es erschreckend, daß so etwas von Linux-Distributoren empfohlen wird, wo man es doch gerade geschafft hat, den Windows-Admins einzubläuen, ihre lokale Domäne nicht »meineFirma.de« zu nennen.

Ich habe während der Grundkonfiguration natürlich eine .local Adresse gewählt und mich entschieden, trotz des guten Rates dabei zu bleiben.

Im weiteren gehe ich nur noch kurz auf die Punkte ein, die mir aufgefallen sind. Im Benutzer-Konfigurationsdialog hat man die Möglichkeit, IMAP-Ordner-»Stile« auszuwählen. Damit ist die Benennung der Ordner gemeint. Der Default-Wert legt englischsprachige Ordner wie z.B. inbox, sent ... an. Leider wird in der gesamten Konfiguration keine Möglichkeit geboten, den Default-Wert selbst zu setzen. Zu diesem Zwecke hilft ein manuelles Editieren der Konfigurationsdateien in /etc/imap VOR dem Anlegen des entsprechenden Benutzers. Eine nachträgliche Änderung ist laut SuSE nicht möglich. So bleibt einem bei einem Benutzer, der mit der Ordnerstruktur nicht zufrieden ist, nur das Löschen und Neuanlegen des gesamten Benutzeraccounts.

Desweiteren ist mir aufgefallen, daß bei einem laufenden DNS-Server die Zonendatei immer den Eintrag server.netzname.domainname enthält, obwohl das Gerät während der Konfiguration einen anderen Namen erhalten hat. Der Rechnername »server« ist in meinem Netz bereits vergeben. In den Zonendateien ist ein Hinweis enthalten, daß manuelle Änderungen netterweise überschrieben werden. Leider kann man aber eben genau diesen Eintrag nicht über das Webfrontend ändern.

Zur Abholung von Email wird das mir unbekannte Perl-Skript fetchd genutzt, was für mich nicht zur Übersichtlichkeit in der Konsole beiträgt (fetchmail läßt grüßen). Bei mehr als fünf Mailboxen, die abgerufen werden sollen, muß unter HilfmittelGlobale Konfiguration der Punkt Max Threads erhöht werden. Hier geht SuSE von Kunden mit Last Resort Postfächern oder maximal fünf Email-Adressen aus.

Der eingebaute Spamfilter muß für jeden Nutzer separat konfiguriert werden. Dazu muß sich der jeweilige Benutzer am Webfrontend anmelden, um dann entscheiden zu können ob Spams gelöscht oder in einen IMAP-Ordner geschrieben werden sollen.

In der von mir durchgeführten Installation war es mir außerdem nicht möglich, auf Samba-Shares erweiterte Benutzerrechte zu vergeben. Die Option acl ist in der Datei /etc/fstab allerdings für den entsprechenden Mountpoint aktiv. Der Zugriffsrechte-Dialog des Samba Konfigurationsfrontend gibt zwar an, daß die Rechte erfolgreich vergeben wurden, diese erscheinen aber weder unter dem Punkt »Bereits vergebene Rechte« noch werden die entsprechenden ACLs gesetzt.

In der zweiwöchigen Testzeit habe ich nicht kontrolliert, ob z.B. manuelle Änderungen an Postfix angenommen werden.