Umstellung eines ganzen Netzwerks von Windows 2000 auf Ubuntu 6.04

Es muss 2005 gewesen sein, als wir überlegten, gut 60 Arbeitsplätze auf ein neues Betriebssystem zu heben. Im Einsatz war noch Windows 2000 inklusive Domäneninfrastruktur. Das System machte immer wieder Probleme, sei es bei Updates oder sogar beim Drucken. Hier und da nervte vieles und Windows 2000 war mit seinen fünf Jahren auch nicht mehr das Jüngste. Mittlerweile ging auch der Supportzeitraum zu Ende, zumindest der Mainstream-Support, und was keiner von uns wusste war, dass es noch den Extended Support gab. Aber abgesehen davon: Es musste was Moderneres her.

Natürlich diskutierten wir über Windows XP, was aber auch schon ein wenig in die Jahre gekommen war und mir so absolut überhaupt nicht gefiel und natürlich dachten wir bereits an den Nachfolger, Windows Vista, der aber noch auf sich warten lies. Zuerst dachten wir, dass wir zwei Möglichkeiten hätten: Wir bleiben bei dem, was wir haben, also Windows 2000 und wechseln dann auf den Nachfolger von XP, wann auch immer dieser erscheinen würde oder wir wechseln auf XP und dann später auf den Nachfolger.

Die Entscheidung

Da wir bereits, neben FreeBSD, Linux auf einigen unserer Server nutzten, fragte die Geschäftsleitung, ob das auch im Clientbereich eine Idee wäre, denn es liefe ja gut. Ich sagte, dass das durchaus eine Option sein könnte, dachte aber eher daran, dass große Probleme kommen könnten. Ich sagte, wir evaluieren das mal. Ich hatte schon einige Jahre Erfahrung mit Linux, war dem Projekt also alles andere als abgeneigt und dachte mir auch, dass die Plattform stabil genug sei, um produktiv damit zu arbeiten.

Linux ist ja nicht gleich Linux und nur ein Kernel, aber selbst wenn wir von GNU/Linux sprechen: eine Distribution musste her. Ich hatte ewig lange Gentoo genutzt, aber nur privat und war sehr überzeugt davon. Wenn ich bedenke, wie viel Zeit ich in Kompilationen vergeudet habe … aber das ist ein anderes Thema. Mir war klar: wir können Gentoo keinesfalls für unser Netzwerk einsetzen. SuSE mochte ich nicht wirklich, RedHat auch nicht, Mandrake … naja … und ich weiß gar nicht mehr, was es um 2005/2006 so alles gab. Aber eine kleine Distribution begann, groß zu werden: Ubuntu. Debian war mir von jeher ein Begriff, und da Ubuntu darauf basierte, schauten wir uns das an und ich begann, längere Zeit damit zu arbeiten. Es war ok, lief stabil und ich konnte das Meiste damit erledigen. Allerdings war ich auch kein Kaufmann, Designer oder Redakteur. Mir war direkt klar: für unsere Produktion ist es nichts, darüber müssen wir nicht weiter nachdenken. Aber Texte damit verfassen: Das ging. Und so beschäftigten wir uns tiefer mit der Materie.

Die Automatisierung

Mein Vorgänger war der absolute Turnschuhadmin. Nichts war automatisiert, er bevorzugte das sinnlose Herumlaufen. Das wollten wir mit der Umstellung ebenfalls erschlagen. Wir wollten aber auch eine Art Domäne haben, zumindest mal globale Homeverzeichnisse und zentrale Anmeldungen. Die Installation sollte von selbst gehen, oder wenigstens, halbwegs von selbst.

Für die Installation entschieden wir uns, da ja Debian-basiert, für Kickstart und ein selbstentwickeltes Script. Mit Kickstart war es problemfrei möglich, eine generische Betriebssysteminstallation durchzuführen. Wir hatten zu dem Zeitpunkt die IP-Adressen noch manuell vergeben und keinen DHCP-Server mit MAC-Matching genutzt, so dass wir am Bootprompt die IP-Adresse für den jeweiligen Rechner mit angeben mussten. Anhand der IP-Adresse wurde entschieden, welche Software und Konfigurationen der Rechner bekam. Alles haben wir selbst gescriptet und entwickelt. Es lief recht reibungslos. Ich erinnere mich noch an den Tag der Umstellung. Wir liefen mit mehreren Personen durch die Abteilungen und starteten die Installationen an. CD rein, davon booten, IP eingeben, der Rest passierte letztlich automatisch. So ganz wahr ist das nicht. Der Installationsprozess war in zwei Bereiche aufgesplittet: den mit Kickstart zur Betriebssysteminstallation und dann der eigentliche Konfigurationsvorgang, der nach der Installation einmal händisch gestartet werden musste. Ich weiß nicht mehr, warum wir das nicht auch automatisierten, aber es hatte irgendeinen Grund. Ein Problem, das wir allerdings bis zum Schluss nicht wegbekamen, waren ein oder zwei Dialoge, die man tatsächlich selbst mit OK bestätigen musste. Sie ließen sich nicht wegoptimieren. Damit war eine unbeaufsichtigte Installation zwar nicht möglich, aber zu der Zeit konnten wir ein komplett installiertes und konfiguriertes System in gut dreißig Minuten mit wenig Aufwand bereitstellen. Das Optimum war damit noch nicht erreicht, aber der Komfort im Gegenzug zu früher war für uns weltbewegend.

Globalitäten

Zusätzlich wollten wir noch zwei weitere Dinge: eine zentrale Anmeldung und globale Home-Verzeichnisse.

Bei der zentralen Anmeldung entschieden wir uns gegen LDAP und Kerberos, da es einfach für uns in dem Zeitraum zu komplex war und wir ja auch noch das Tagesgeschäft zu betreuen hatten. Es gab eine sehr viel einfachere Lösung, die natürlich auch wesentlich limitierter war und letztlich kaum Sicherheit bot: NIS. Doch wir fuhren damit gut. Neben den Linux-Clients hatten wir daran auch die Macs und die FreeBSD-Maschinen angebunden und es lief. Wir arbeiteten später noch an LDAP, aber erstmal war das so in Ordnung.

Die Konstellation lief fast zehn Jahre und es gab unglaublich wenige Probleme. Aus Kompatibilitätsgründen (Kombination Word und InDesign) haben wir uns dann aber entschlossen, die Redaktion aus Linux herauszunehmen und Macs zu geben, damit der Austausch mit der Produktion besser lief.

Würde ich es wieder tun?

Technisch war das Projekt, meiner Meinung nach, ein voller Erfolg. Die Administration machte, zumeist, Spaß und lief, bis auf wenige Probleme, super. Aber würde ich es wieder tun? Nein. Denn was Computer vereinfachen, verkomplizieren die Menschen. Einige waren begeistert, aber viele eben nicht und es gab hier und da guten Gegenwind. Ich empfand es als sehr anstrengend. Was ich bei der Administration sparte, musste ich in sinnlosen Diskussionen ausbaden.

Das Interessante aber war, dass eine solche Umstellung möglich war. Es waren dann zwar keine sechzig Computer, aber immerhin um die fünfundreißig, die mit Linux liefen und das sehr gut. Aber die Leute müssen sich darauf einlassen.

Neues YouTube-Video – Qt-Tutorial 005: Installation auf Linux

Natürlich kannst du Qt auf Linux oftmals über deinen Paketmanager installieren. In diesem neuen Video zeige ich dir aber, wie du das Qt-Framework aus den offiziellen Quellen installieren kannst.

Qt-Tutorial 005: Installation auf Linux
Ich benutze hier als Linux-Distribution Ubuntu Linux 21.10. Mit ein paar einfachen Schritten ist die Installation schnell erledigt.

Zumindest auf Ubuntu 21.10 benötigt man für die Qt-Entwicklug noch das Paket libgl1-mesa-dev (sudo apt install libgl1-mesa-dev). Dann lädt man sich von https://qt.io das Installationspaket herunter, gibt ihm Rechte zum Ausführen und installiert „Qt for desktop development“. Danach kann man direkt loslegen.

wxWidgets-Entwicklung mit dem QtCreator (zumindest auf macOS, Linux und FreeBSD)

Es ist kaum zu glauben, aber bis vor einer kurzen Zeit benutzte ich keine IDE. Oftmals entwickle ich immer noch gerne ohne IDE, doch für Qt nehme ich QtCreator und ich finde die IDE ganz „nett“. Ich kenne etliche Systeme, und keins gefällt mir tatsächlich so gut wie QtCreator, außer NetBeans für Java vielleicht. Damit bin ich aber vermutlich allein (:

Ich wollte einmal wissen, wie hoch der Aufwand ist, wxWidgets in QtCreator einzubinden. Es ist sehr einfach. Wie es geht, zeigt dieser Artikel.

wxWidgets nutzt auf unixoiden System „wx-config“ als Kommandozeilenkonfigurationswerkzeug. Das bedeutet, dass man einfach in seinen Compileraufruf „wx-config“ einbaut. Ein einfaches Beispiel könnte:

# c++ *.cpp -o test `wx-config --libs --cppflags`

sein.

Also einfach mal den QtCreator starten und ein neues Konsolenprojekt erstellen. In der Projektdatei (*.pro) dann folgende Zeilen hinzufügen:

INCLUDEPATH += /usr/local/wxWidgets/include/wx-3.0
wxCXXFLAGS = $$system(/usr/local/wxWidgets/bin/wx-config --cxxflags --unicode=yes --debug=no)
wxLinkOptions = $$system(/usr/local/wxWidgets/bin/wx-config --debug=no --libs --unicode=yes)
LIBS += $$wxLinkOptions
QMAKE_CXXFLAGS_RELEASE += $$wxCXXFLAGS
QMAKE_CXXFLAGS_DEBUG += $$wxCXXFLAGS

Es ist natürlich darauf zu achten, dass der Pfad für wx-config sowie der Includepfad stimmen und angepasst werden.

Jetzt ist es möglich, einfach sein wxWidgets-Programm zu schreiben und mit Klick auf den Play-Button zu kompilieren und zu starten.

Hier noch ein kleines wxWidgets-C++-Beispiel:

#include <wx/wx.h>

class MyApp : public wxApp {

	public:
		bool OnInit();

};

IMPLEMENT_APP(MyApp)

class MyFrame : public wxFrame {

	public:
		MyFrame();
	
	private:
		enum {
			HELLO_WORLD_BUTTON
		};
	
		wxPanel *mainPanel;
		wxBoxSizer *mainBoxSizer;
		wxButton *helloWorldButton;
		wxTextCtrl *helloWorldTextCtrl;
	
	protected:
		DECLARE_EVENT_TABLE()
		
		void HelloWorldEvent(wxCommandEvent &WXUNUSED(event));

};

bool MyApp::OnInit() {
	MyFrame *f = new MyFrame;
	f->Show();
	SetTopWindow(f);
	return true;
}

wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
	EVT_BUTTON(HELLO_WORLD_BUTTON, MyFrame::HelloWorldEvent)
wxEND_EVENT_TABLE()

MyFrame::MyFrame() : wxFrame(NULL, -1, _("Hello World")) {
	mainPanel = new wxPanel(this, -1);
	mainBoxSizer = new wxBoxSizer(wxHORIZONTAL);
	
	helloWorldButton = new wxButton(mainPanel, HELLO_WORLD_BUTTON, _("Say Hello World"));
	mainBoxSizer->Add(helloWorldButton);
	
	mainBoxSizer->AddSpacer(5);
	
	helloWorldTextCtrl = new wxTextCtrl(mainPanel, -1);
	mainBoxSizer->Add(helloWorldTextCtrl);
	
	mainPanel->SetSizer(mainBoxSizer);
	mainBoxSizer->SetSizeHints(this);
}

void MyFrame::HelloWorldEvent(wxCommandEvent &WXUNUSED(event)) {
	helloWorldTextCtrl->SetValue(_("Hello World"));
}