Migration Netware nach Linux

... zu neuen Ufern !

von Andreas Lindenblatt / Chris Weber

Migrationserfahrungen von Novell nach Linux aus der Praxis.
Über die theoretische Möglichkeit, ein LAN-Server, Novell oder auch Windows NT Server-System durch einen Linux-Server zu ersetzen ist in der Vergangenheit sicher schon oft geschrieben worden. Der folgende Artikel beschäftigt sich mit der praktischen Umstellung eines Novell 3.11 Servers nach Linux.

Warum Linux ? Weil das Netz es uns wert war - und ist :-) !!

Die Aufgabe

Als Anfang diesen Jahres einer unserer langjährigen Kunden mit dem Wunsch an uns herantrat, sein Netz technisch auf einen aktuelleren Stand zu bringen, wollten wir das natürlich nicht ablehnen :-).
Also setzten wir uns zusammen um festzulegen, welchen Anforderungen das "neue" Netz gerecht werden soll.
Heraus kam (nach Priorität geordnet):

schnellerer Zugriff auf die Serverdaten
gleiche oder geringere Downtime des Systems (letztes Jahr <1%)
Internetzugang für drei und Email für alle Arbeitsplätze
Faxversand vom Arbeitsplatz
automatischer Überweisungs- und Etikettendruck bei Rechnungsstellung im Lager (aka Netzwerkdrucker)
Umstellung und Ersatz dreier Arbeitsplätze auf Win95, Beibehaltung der anderen Arbeitsplätze unter Win3.11
Fernwartungszugriff für uns
vom Kunden einfach zu handhabender Wechsel der CDs im Server
Y2K konform (wenigstens im Serverbereich)
kostengünstig

Mit dem schon etwas in die Jahre gekommenen Novell NetWare3.11 ließ sich das auch mit viel Liebe und Aufwand nicht mehr realisieren. Also... etwas Neues mußte her.

Erster Ansatz

Voller Eifer wurde ein Netzwerkplan gezeichnet und das Angebot ausgearbeitet:

Der erste Ansatz war ein "klassisches" Angebot mit Windows NT als Serverbetriebssystem, einer kleinen Cisco für den Internetzugang und FaxWare als Faxlösung für die Arbeitsplätze.
Soweit - so gut. Beim Ansatz blieb es dann auch - die Kosten für den OS-Umstieg am Server und zur Befriedigung des Resourcenhungers von Windows NT lagen deutlich über dem veranschlagten Budget.

Die alternative Novell-Lösung nahm sich preislich auch nicht viel... - und dabei war die Fernwartung noch nicht einmal eingerechnet und der Server ebenfalls aus Kostengründen eher "schmalbrüstig" für die Anforderungen des geplanten Netzwerk-OS ausgelegt

Also wanderte (wie so oft :-)) der Punkt "kostengünstig" in der Prioritätenliste des Kunden stark nach oben.

Die Lösung

Im Laufe der letzten drei Jahre hatte Linux eher "klammheimlich" bei vielen unserer Kunden Einzug gehalten, meist in Form "alter", also nicht mehr dem aktuell gängigen Mainstream-Betriebssystem gewachsener Rechner, die zum Internet-Gateway umfunktioniert wurden. Sicher, so etwas gibt es mittlerweile auch als nettes kleines Kästchen "zum an die Wand nageln", aber ein Gateway auf Linux Basis bietet immer noch eine Menge Vorteile.
Es existieren in einem Linux System keine "Hintertüren", denn wo die Sourcen der Programme verfügbar sind, schauen eine Menge Leute nach versteckten Zugängen. Sicherheitsrelevante Fixes sind schnell verfügbar, innerhalb weniger Tage hat jemand sich daran gemacht und Löcher gestopft.
Mittlerweile versehen diese Rechner in den meisten Fällen noch wesentlich mehr Aufgaben, angefangen von Boot-P und DHCP-Diensten über Druck-, -File, IntraNet und Email-Diensten bis hin zu Fax-, File- und Datenbankservern. Aber meist immer noch "klammheimlich" und ohne groß aufzufallen (sie funktionieren ja schließlich :-)).
Linux hatte sich in diesem Zeitraum als extrem stabil und wartungsfreundlich erwiesen.

Wir warfen also das angesammelte Know-how zusammen, schüttelten es gut durch, feilten hier und da noch einige Ecken und Kanten ab und legten ein neues Konzept vor:

Alle genannten Anforderungen wurden in einen Linux-Server integriert. Verwendet wurde dazu ein herkömmlicher SCSI PC, eine passive ISDN Karte, RedHat 5.0. , HylaFAX und BRU als Backup-Lösung.
Damit war das System an sich komplett.

Vorbereitungen

Der erste Schritt war natürlich eine komplette Sicherung des Programm bzw. Datenbestandes. Da ein Systemwechsel anstand, konnte diese Sicherung nicht direkt über ein Bandlaufwerk erfolgen. Also bauten wir den Server beim Kunden ab und in unserer Firma wieder auf. Das Backup erfolgte dann über unser internes Hausnetz, was sich auch in Hinblick auf die Restauration der Daten auf den neuen Server als vorteilhaft erweisen sollte.
Blieb noch die Wahl der verwendeten Linux-Distribution. Auf jeden Fall sollte man sich darüber im klaren sein, daß sehr sinnvoll ist, eine Distribution mit Packet-Managment zu verwenden. Sollten Updates nötig sein, vereinfacht dies die Handhabung sehr - außerdem bleibt das System auf lange Sicht konsistent

Diese leidvolle Erfahrung mußten wir mit unseren hauseigenen Servern unter (ehemals) Slackware sammeln.
Ein aktuelles System mit der Möglichkeit einer relativ einfachen Administration bietet sich an, schließlich möchte der Kunde auch eine Eingriffsmöglichkeit auf seinen Server haben ohne gleich einen UNIX-Kurs besuchen zu müssen.
Wie bereits beschrieben, setzen wir zu diesem Zweck sehr gerne RedHat ein. Sicher gibt es Distributionen die weit einfacher zu installieren sind und deren Einstellungsmöglichkeiten fast komplett über Menues erfolgen. Störend ist da nur, das solche Menues oft die Unart haben, einem die fein ausgetüftelte Konfiguration zu zerlegen. Nach unserer Meinung ist für ein Serversystem eher ein bißchen Minimalismus angesagt.

Der Server an sich

Nach der Basisinstallation ließen sich die Anforderungen "Internetzugang und Fernwartung" mit isdn4linux und unseren Erfahrungen im Aufsetzen von Internetgateways recht schnell und einfach realisieren.
Die Anbindung ans Internet erfolgte über dialup ISDN-PPP. Aus Sicherheitsgründen nehmen wir eine Umsetzung der Netzwerkadresse in den Bereich der privat verfügbaren Netzwerkadressen vor, also in unserem Fall 192.168.0.0 - 192.168.0.255 (IP Masquerading, NAT). Diese Technik verhindert unter anderem, daß Rechner aus dem lokalen Netz von außen (Internet) sichtbar sind - zusammen mit der dynamischen Zuweisung der Verbindungs-IP schon eine große Hürde für mögliche Angriffe von außen.

Die Verwendung des Squid Proxy Caches sorgt für eine ausreichende Performance des Internetzugriffs und bietet zudem die Möglichkeit den Zugriff auf das Internet auf bestimmte Benutzer/Rechner zu begrenzen.

Um uns (und den Clients) das Leben ein wenig einfacher zu gestalten setzten wir DHCP auf und versorgten damit alle Clients vom Server aus mit einer gültigen Netzwerkadresse und mehr. Jede neue Station/Austausch wurde minimalkonfiguriert ins LAN gebracht und vervollständigte ihre Konfiguration dynamisch.
Zur Realisierung der Faxdienste bot sich in unserem speziellen Fall die Installation von HylaFAX an. Dies allein wäre genug Stoff für einen weiteren Artikel, wir wollen daher an dieser Stelle nicht weiter darauf eingehen - nur soviel sei gesagt - es faxt.

Die Clients kommen

Eigentlich hätten wir ja jetzt fertig sein können - wenn da nicht noch diese Arbeitsstationen gewesen wären :-).
Also blieb zu guter Letzt noch die eigentliche Serverseite für die Windows-Clients. Da wir mit den verfügbaren NFS Paketen für Windows nicht allzu gute Erfahrungen gemacht hatten (auch in preislicher Hinsicht), wurde als Serverpart Samba verwendet. Die Novellemulation mars_nwe ist leider noch nicht weit genug, um sie für unsere Zwecke einsetzen zu können. Zum Zeitpunkt der Umstellung war Caldera's Novellemulation leider auch noch nicht verfügbar.
Aber bei Linux gibt es ja bekanntlich kein Problem ohne Lösung. Eher existieren eine Unmenge von Lösungen. Es ist fast wie bei der Vorstellung des Lasers, damals spöttelte die Fachwelt auch: "Eine Lösung auf der Suche nach einem Problem". Dieser Punkt ist eine weitere Stärke von Linux, sollte sich etwas nicht auf einem Weg erledigen lassen, gibt es sicher einige Alternativen.
Durch den Packetmanager ist es ein leichtes die jeweils letzte verfügbare Version von z.B. Samba einzuspielen. Auf jeden Fall sollte eine Version ab 1.9.18 Verwendung finden. Grund dafür ist ein korrektes Handling von Oplocks, andernfalls besteht die Gefahr, daß bei unvorsichtiger Konfiguration des Dienstes Daten verloren gehen. Oplocks sind für den Fall notwendig, daß mehrere Benutzer die gleiche Datei mit Schreibrechten öffnen wollen.

die User auch :-)

Spätestens jetzt mußten wir uns Gedanken über die Benutzereinrichtung machen. Da wir von Novell nach Linux umstellten und auch sonst keine Server im Netz aktiv waren, legten wir alle Benutzer auf dem normalen Weg als Unixbenutzer an. Damit ergab sich für Samba die Einstellung "security = user" bzw. "security = share" um Benutzername und Paßwort beim System in Erfahrung zu bringen. Zusätzlich sollte generell auch eine Gruppe "samba" angelegt werden, der alle Benutzer mit Zugriff auf die smb Dienste hinzugefügt werden. Diese Maßnahme ist ganz praktisch, um auf einfachem Wege sicher zu stellen, daß eine Datei die von Benutzer A geschrieben wurde, auch von Benutzer B geöffnet werden kann. Im einfachsten Fall wird in der smb.conf ein share mit z.B. Namen "Daten" angelegt. Ein "force group = samba" sorgt dafür, das alle Zugriffe auf den Share mit der Benutzergruppe samba erfolgen. Damit neu angelegte Dateien und Verzeichnisse von der Gruppe lesbar / beschreibar sind, ist allerdings noch das entsprechende Setzen der "create mask" und "direktory mask" für den share notwendig (d.h. Lese und Schreibrechte für die Gruppe vergeben). Ein Setup dieser Art ist natürlich die gradlinigste und einfachste Art für alle Benutzer Zugriff zu gewähren. Der Vorteil eines solchen Setup ist dann aber auch gleich sein Nachteil - Es kann jeder Benutzer jede Datei eines anderen Benutzers lesen und schreiben. Sollte das nicht gewünscht werden, kann man z.B. für speziell geschützte Bereiche weitere Shares mit eigenen Benutzergruppen anlegen oder aber man verzichtet auf das Forcieren einer Gruppe und arbeitet mit den Benutzerrechten für Verzeichnisse (set group id on execution). Klar, wer mag, kann auch eine Kombination beider Methoden verwenden. Bitte aber auf jeden Fall protokollieren, sonst kann es bei größeren Installationen schnell haarig werden :)
Welcher Weg am besten zu gehen ist, hängt stark von den vorherigen Nutzungsgewohnheiten der Benutzer ab. Auch die Struktur der Daten/Programme spielt eine Rolle. Zielsetzung bei der Umstellung ist in den meisten Fällen die ursprüngliche Netzumgebung nachzubilden. Wenn keine gravierenden Gründe bestehen, sollte man auch keine gravierenden Änderungen am "optischen" Layout des Netzes durchführen. Andernfalls setzt man sich der Gefahr aus, unnötige Probleme heraufzubeschwören ("...aber ich hatte doch meine Dateien auf Laufwerk F: und finde sie jetzt nicht mehr"). In unserem Fall genügte auf Grund der Übersichtlichkeit des Netzes die einfachste Variante der Zugriffsregelung.
Es wurde zu den normalen Benutzern noch ein Admin Benutzer angelegt, über den dann die Rücksicherung der vom Novell übernommenen Daten erfolgte. Die Rücksicherung über das Netz brachte den Vorteil, daß alle wiedereingespielten Dateien sofort mit den korrekten Zugriffsrechten versehen wurden. Benutzerspezifische (private) Dateien wurden in die Home-Verzeichnisse umgelegt und der "[homes]" share von samba aktiviert. Damit existieren für jeden Benutzer Bereiche in denen sie/er Dateien ablegen können ohne das man sich mit Verzeichnissperrungen beschäftigen müßte. Zudem läßt sich über Quotas bequem verhindern das Benutzer den freien Speicherplatz soweit ausnutzen, daß es zu Engpässen im System kommt.
Eine weitere Herausforderung ergab sich aus der Tatsache, das sich trotz Upgrade auf W 95 auch weiterhin noch einige Win3.11 Clients mit Novellrequester im Netzwerk befanden. Es gibt zwar die Möglichkeit, einen TCP/IP Stack in Win3.11 nachzuinstallieren und somit einen reibungslosen Betrieb von NetBIOS über TCP/IP zu ermöglichen, allerdings benötigt man dazu einige Dateien vom Microsoft FTP Server. Welche genau dies sind und was man beachten sollte findet sich unter anderem in der Dokumentation zu Samba. Ach ja, man sollte sich unbedingt die Zeit nehmen und diese Dokumentation(en) durchackern, es bewahrt einem einfach vor einer Menge von Fehlern. Nicht jeder heißt Tridgell :-).

Quickhack für Nachzügler

Ist es nicht möglich, die alten Clients rechtzeitig umzustellen, so kann man für die Übergangszeit auf den Novellemulator mars_nwe zurückgreifen. Mars_nwe wird dann so konfiguriert, daß sich das angebotene Netzlaufwerk mit dem benötigten Samba Share deckt. Die älteren Arbeitsstationen melden sich dann für die Übergangszeit weiterhin an "Novell" an. Bis zur Umstellung ist es dann den betroffenen Arbeitsstationen weiterhin möglich, als vollwertiges Mitglied im Netz zu agieren :-). Wegen der verfügbaren Mars-Revision sollte dieser QuickFix aber wirklich nur eine Übergangslösung darstellen.

's druckt...

In unserem Fall stand noch der Anschluß eines Nadeldruckers direkt am Server an. Diese Klippe hat sich recht einfach mit den Bordmitteln der Linux-Distribution umschiffen lassen. Der printcap Eintrag wurde von RedHat's printertool korrekt erzeugt. Samba stellte den Drucker dann auch kommentarlos im Netz zur Verfügung. Da der Drucker nur für den Ausdruck von Adressetiketten genutzt wird, ist auch keine Wandlung der Formate (Grafik etc.) notwendig, aber natürlich möglich. Wer's mag, kann somit auch Firmenlogos und dergleichen auf die Etiketten drucken. Alle weiteren vorhandenen Drucker stehen wie bisher nur dem jeweiligen lokalen Benutzer zur Verfügung.

...und CDRomt :-)

Ein weiterer Pluspunkt eines Linux-Servers ist nach unserem Ermessen die Handhabung von Server-CD's. Unter Novell läßt sich eine im Server eingelegte CD nicht ohne Konsolenzugriff und einigen Kommandozeilen wechseln. Unter NT dagegen kann man die CD entnehmen auch wenn gerade Zugriffe darauf stattfinden. Beide Verfahrensweisen sind gut dazu geeignet gelegentlich für Überraschungen zu sorgen.
Als Mittelweg verwendeten wir beim Linux-Server die automount-Funktion. Damit war es möglich ohne große Vorkehrungen eine netzweit verwendete CD zu tauschen, aber nur wenn keine Zugriffe darauf stattfinden.

Wie sieht's aus?

Damit sind wir fertig. Ah, fast... Das Auge "ißt" ja schließlich auch mit :-).
Ein KDE-Desktop auf der Serverkonsole wirkt Wunder in der Akzeptanz des neuen Server-OS, durch die graphische Oberfläche sieht das System nach außen hin "fast" wie ein Windows95/NT Rechner aus und wirkt nicht mehr allzu fremdartig. Und nebenbei kann der Kunde auch noch schnell einen Blick auf Statusdaten und Laufwerke werfen - die Resonanz war ausgesprochen positiv.

Finale

Ich habe gerade auf den Server geschaut - zum jetzigen Zeitpunkt meldet das System eine Uptime von 131 Tagen (von 134 möglichen).
Woher die "fehlenden" drei Tage kommen?
Naja, nach drei Tagen fiel eins der CD-Rom-Laufwerke aus - das kann Linux (noch) nicht selber austauschen :-)...

Die Autoren

Andreas Lindenblatt ist Gründer der Firma Solution - The Computer People und installiert und administriert seit NetWare2.11 Netzwerke in allen Formen und Farben.
Chris Weber ist technischer Leiter der Solution und setzte 1994 - natürlich mit Linux - den ersten kommerziellen WebServer in Mannheim auf. Seitdem forciert er den Einsatz von Linux zur Lösung aller möglichen und unmöglichen Probleme.
Zu erreichen sind die beiden unter azrael@solution.de und chris@solution.de.