Leitfaden für die Migration von Software
Dieses Dokument ist Teil der Anfrage „Leitfaden für die Migration von Software“
3.10 Exkurs: Erfahrungsbericht der Landeshaupstadt München — Projekt LiMux 53 3.10 Exkurs: Erfahrungsbericht der Landeshaupstadt München — Projekt LiMux 3.10.1 Historie und Ziele des Projekts LiMux Die Landeshauptstadt München vollzieht bis 2013 einen umfassenden !T-Migrationsprozess®, Es gilt, alle rund 15.000 PC-Arbeitsplätze auf eine Open Source basierte, standardisierte und konsolidierte Lösung umzustellen. Der im Jahr 2003 durch den Münchner Stadtrat eingeschlagene Weg stützt sich auf drei grundsätzliche Entscheidungen: 1. ein freies und quelloffenes Betriebssystem inkl. einer Bürokommunikation, basierend auf offenen Standards für alle Arbeitsplatz-PCs, 2, die Maßgabe, künftig alle Fachverfahren plattformoffen zu beschaffen oder zu entwickeln, 3. eine standardisierte IT Plattform mit konsolidierten Anwendungen und Datenbeständen. Im Frühsommer 2004 wurde der Startschuss für die konkrete Migration mit folgenden Zielen gegeben: 1. Durchführung der Migration der weit überwiegenden Anzahl der PC-Arbeitsplätze auf den stadt- weit einheitlichen LiMux Client Bevorzugt werden dabei herstellerunabhängige und von einem bestimmten Betriebssystem und Office-Produkt unabhängige Lösungen 2. Migration der Fachverfahren auf webbasierte Lösungen bzw. auf native Linux-Lösungen, um für zukünftige Migrationen gerüstet zu sein 3. Konsolidierung und ggf. Migration der PC-Standard-Anwendungen auf ein vernünftiges Maß, d.h. eine Software für eine Funktion 4. Konsolidierung und Migration von MS-Office Makros, Vorlagen und Formularen, die im Lauf der Jahre in einer Vielzahl unkoordiniert und unkontrolliert entstanden waren 5. Einführung von Systemmanagement-Lösungen für den Basisclient, wie z.B. einer stadtweiten Soft- wareverteilung und eines einheitlichen Anmeldedienstes Als Ergebnis der Migration sollen die aus der Historie bestehenden Abhängigkeiten von proprietären Produkten zunehmend aufgelöst werden und die Software- und Architekturauswahl langfristig die ge- wünschte Flexibilität gewinnen. Die Verwendung aufeinander abgestimmter Produkte eines Herstellers bietet in der Regel zwar den Komfort, dass Funktionen gemeinsam genutzt werden oder (proprietä- re) Dateiformate durchgängig verwendet werden können. Andererseits wird damit die Ablösung dieser Produkte deutlich erschwert und weitere Produkte des selben Herstellers präjudiziert. Dadurch werden vermeidbare Kosten und Abhängigkeiten erzeugt. Letztlich führt dies zu einer deutlich eingeschränk- ten Freiheit bei der Auswahl geeigneter IT-Systeme in der eigenen Organisation. Das Projekt LiMux gilt zudem als „Blaupause“ für die Projektkultur zukünftiger IT Projekte. 3.10.2 Projektinhalt/Projektgegenstand In einer Vorstudie wurden in den Jahren 2002 und 2003 besonders die technische und organisatorische Ausgangssituation geklärt. 30 Siehe http://www.muenchen.de/Rathaus/dir/limux/index.html
54 3 Kriterien für erfolgreiche Migrationen 3.10.2.1 Heterogenität der Clients Die Münchner Stadtverwaltung zeichnete sich vor der LiMux-Migration durch eine sehr heterogene IT- Technik aus. Die mittlerweile ca. 15.000 Benutzerrinnen und Benutzer arbeiteten seit Jahren mit dem Betriebssystem Windows-NT der Firma Microsoft und dem passenden Office-Produkt in unterschiedli- chen Versionen von 97 bis 2000. Für die Erfüllung der vielfältigen Spezialaufgaben einer öffentlichen Verwaltung sorgten ca. 340 Fachverfahren, davon waren ca. 170 großrechnerbasiert. Zusätzlich wurden 300 Standardsoftwareprodukte eingesetzt. 3.10.2.2 Zwei verschiedene Fileservice-Systeme Der Fileservice basierte vor den Migrationsarbeiten auf zwei unterschiedlichen Konzepten, die von je circa der Hälfte der städtischen Referate eingesetzt wurden. Einerseits wurde Netware von Novell in un- terschiedlichen Versionen verwendet, andererseits wurden NT-Domänen-Emulationen wie zum Beispiel „PC-Netlink“ oder „Advanced Server for Unix“ eingesetzt. 3.10.2.3 Zentrale Strategie und dezentraler Berieb Organisatorisch ist in Münchens IT zwischen zwei Zuständigkeitsbereichen zu unterscheiden. Die IT- Strategie und die Beschaffung werden zentral koordiniert und entschieden, während der Betrieb und die Planung in 22 eigenständigen IT-Abteilungen der Stadt bewerkstelligt werden. Daraus ist leicht ersicht- lich, dass es unterschiedliche Betriebs-, Benutzerverwaltungs- und Supportkonzepte gibt. Parallel zum LiMux-Projekt wurde vom Münchner Stadtrat das Projekt MIT-KonkreT zur strategischen Neuausrichtung der gesamten städtischen IT aufgesetzt. 3.10.2.4 Bestandteile des linuxbasierten PC Arbeitsplatzes Der LiMux Client ist ein Betriebssystem, das gezielt an die Bedürfnisse der städtischen Benutzerinnen und Benutzer angepasst ist. Das Betriebssysstem basiert aktuell auf einer Ubuntu 10.4 Distribution und der graphischen Oberfläche KDE 3.5 (Stand Herbst 2011). Dies bedeutet für die Mitarbeiterinnen und Mitarbeiter konkret, dass im Startmenü die einschlägigen Fachverfahren direkt ansteuerbar sind, dass bekannte und zusätzliche Anwendungsprogramme wie OpenProj, Freemind, Gimp, Acrobat Reader u.a. zur Verfügung stehen und dass unter LiMux der Desktop weitgehend die gleichen Funktionen wie der gewohnte Microsoft Windows-Desktop hat. Als Browser kommt Firefox und als E-Mail Client Thunderbird zum Einsatz. Eine stadtweite Kollaboration Lösung wird derzeit in einem weiteren Projekt in Abstimmung mit LiMux realisiert. Die freie Bürosoftware OpenOffice.org (Version 3.2.1; Stand Herbst 2011) ersetzt die ver- gleichbaren Programme von Microsoft. Das Arbeiten mit Texten (writer statt word), Tabellen (calc statt excel), Präsentationen (impress statt power point) und zusätzlich Zeichnungen (Draw) ist wie gewohnt möglich. Im Sinne des Community Gedankens von „Geben und Nehmen“ hat die Landeshauptstadt ein Dokumenten- und Vorlagensystem WollMux entwickelt, unter der European Public Licence (EuPL) lizensiert und der Öffentlichkeit zur freien Nutzung zur Verfügung gestellt?!. 3.10.3 Projektsteuerung Das Projekt LiMux wird mit einem klaren Governance Modell betrieben. Dieses rollenbasierte Leitungs- modell und seine Verantwortlichkeiten wurde schrittweise errichtet und weiterentwickelt. Als oberstes Entscheidungsgremium fungiert der Lenkungskreis (LKr) mit seinem die Projektleitung be- ratenen Organ, dem sog. 3+1+2-Beirat. Der Lenkungskreis als oberstes Entscheidungsorgan setzt sich aus Bereichsleitern der Migrationsbereichen zusammen und wird von der 2. Bürgermeisterin geleitet. In der erweiterten Projektgruppe (ePG) sind alle Projektleiter aus den Migrationsbereichen vertreten. Hier wird über Form und Zeitpunkt der Migration sowie über technische Lösungen beraten. Die Projektgrup- 91 http://www.WollMux. org
3.10 Exkurs: Erfahrungsbericht der Landeshaupstadt München — Projekt LiMux 55 pe des Kernteams LiMux ist das zentrale Steuerungs- und Koordinationsorgan. Auf der Arbeitsebene sind zahlreiche Arbeitsgemeinschaften im Einsatz (AG LiMux Client, AG Office, AG Testmanagement, Kommunikationsmanager Netzwerk). Mitglied in den AGs sind die zuständigen Technikmanager aus den 22 Migrationsbereichen. Ein Change Advisory Board (CAB) regelte die Abstimmung im Change- Releasemanagement zwischen den betroffenen Bereichen solange bis zur Einführung eines systemati- schen und ticketbasierten Anforderungs- und Releasemanagements. Diese rollenbasierten Einheiten werden über eine klare Regelkommunikation gesteuert: Im zwei- monatig tagenden Lenkungskreis wird über den Projektfortschritt berichtet, Jahres- und Zwischenziele vereinbart und gravierende Probleme einer Lösung zugeführt. In den Sitzungen der erweiterten Projekt- gruppe werden alle technischen und organisatorischen Themen aus einer operativen Sicht entschieden. Alle anderen Meetings und AGs dienen dem Informationsaustausch und der konkreten Problemlösung. 3.10.4 Projektorganisation Das LiMux Projektteam besteht aus einem Kernteam und einem erweiterten Projektteam. Das Kernteam umfasst insgesamt rund 25 Personen, die an der Entwicklung und Bereitstellung des LiMux Clients, dem Support für OpenOffice inkl. Umstellung von Formularen und Makros, sowie an der Weiterent- wicklung und dem Support des WollMux arbeiten. Das Kernteam setzt sich organisatorisch aus den Fachgruppen Anforderungsmanagement, Entwicklung, Office-WollMux, erweitertes Office Supportzen- trum, Migrationsunterstützung, Testmanagement, Releasemanagement / Architektur sowie Veränderung & Kommunikation zusammen. Eine Projektleitung und das Projektbüro steuern das Kernteam. Das erweiterte Projektteam setzt sich aus vielen Kolleginnen und Kollegen aus den Migrationsbereichen zusammen, die dort die Anforderungen stellen, die Migration verantworten und die Anwender täglich unterstützen. Über die gesamte Projektlaufzeit wurde und wird das Projekt LiMux von einer Reihe von externen Part- nern unterstützt. Hierzu gehören Credativ GmbH, DBI Klarl & Schuler GmbH, Gonicus GmbH, IABG mbH, IBM Deutschland, Unilog (heute Logica Deutschland). Dadurch wurde und wird nicht nur eine gleichbleibende hohe Expertise gesichert, sondern auch der Wirtschaftsstandort München gestärkt. 3.10.5 Projektmethodik In der Projektvorbereitungsphase fiel die Entscheidung für den Einsatz eines klassischen meilensteinba- sierten Projektmanagements. Dieses wird bis heute praktiziert. Im Laufe des Projekts wurden allerdings Änderungen an Projektstruktur und -methodik vorgenommen. So wurden inhärente Projektaufgaben wie Anforderungs-, Release- und Testmanagement in eigenständige Rollen und Teams ausgelagert. Auch wurde der Fokus auf die Akzeptanz und Zufriedenheit der IT Betreuer und Endanwender durch ein eigenständiges Veränderungsmanagement gestärkt. Auch das Vorgehen in der Entwicklung wurde geändert. Heute kommt hier Agiles Programmieren (angelehnt an die SCRUM-Methodik) zum Einsatz. Eine bewährte Konstante blieb eine flexible und in sich konsistente Regelkommunikation über alle Hier- archiebenen hinweg. 3.10.6 Projektvorgehen In dem Projekt wurde und wird ein bedarfsorientierter und evolutionärer Ansatz anstelle eines sog. „Big Bang“ verfolgt. In diesem Sinne wurde der Wechsel des Betriebssystems und der Wechsel des Officeprodukts mittels des Konzepts einer Softmigration entkoppelt. Zudem wurde in allen Migrationsbe- reichen zur Pilotierung der Migration eine so genannte „Keimzelle“ mit ca. 50 Rechnern installiert. Eine serielle Migration schließlich ermöglichte es den Projektteams, eine an den Bedürfnissen der Referate ausgerichtete Umstellung zu ermöglichen. Vor allem in den großen und komplexeren Bereichen der Stadtverwaltung bot es sich an, im Rahmen einer „Softmigration“ nicht gleichzeitig auf den LiMux Client und OpenOffice.org umzustellen, sondern
56 3 Kriterien für erfolgreiche Migrationen zunächst das bisherige Officeprodukt der Firma Microsoft durch die freie Alternative OpenOffice.org zu ersetzen. Die Benutzerinnen und Benutzer konnten sich so in aller Ruhe an ihr neues Handwerkszeug gewöhnen. Mit der weichen Migration wurde die Schulungssituation entzerrt. Zudem konnte in einigen Bereichen die Zeit genutzt werden, infrastrukturelle Voraussetzungen für den Wechsel auf den LiMux Client zu schaffen. Zunächst migrierten kleine und nach technischen Gesichtspunkten bei der Umstellung unkritische Berei- che innerhalb eines Migrationsbereiches, sog. „Keimzellen“. So konnten die Referate erste Erfahrungen mit der neuen Welt machen und den Entwicklern und dem erweiterten Office Supportzentrum mögliche Stolpersteine aufzeigen. Parallel zur Installation der Keimzellen lief die Umstellung der Bürokomunikati- on von MS Office auf OpenOffice.org auf allen PC Arbeitsplätzen. In den Jahren 2007-2009 sind alle PC Arbeitsplätze mit OpenOffice.org ausgestattet worden. Mit den Releases 2.3 und 2.4 des LiMux Client erfolgte dann eine verstärkte Phase der Migration in vielen Migrationsbereichen auf das linuxbasierte Betriebssystem. Mittlerweile ist das Release 4.0 mit aktuellem Thunderbird sowie Firefox Browser und OpenOffice 3.2.1 als Bürokommunikation auf über 8.000 PC Arbeitsplätzen im Einsatz (Stand Herbst 2011). Die Landeshauptstadt München hat durch die Migration der Bürosoftware die Chance genutzt, die vor- handenen Vorlagen, Formulare und Makros zu konsolidieren, Redundanzen zu erkennen und den Woll- Mux als stadtweites Vorlagensystem einzuführen.
Kapitel 4 Migrationsgebiete Der Migrationsleitfaden beleuchtet verschiedene Software-Gattungen, die bei Migrationsvorhaben von Bundesbehörden regelmäßig berührt werden. Insbesondere soll er dort Hilfestellungen leisten, wo we- sentliche Standards und zentrale Komponenten betroffen sind. Die Software-Gattungen werden in unterschiedlicher Detailtiefe beleuchtet. Es wird stets dargestellt, wie die Migration vorzubereiten und durchzuführen ist. Bei der Mehrzahl der Gebiete ist zudem ein Produktvergleich nebst Empfehlungen enthalten. Die übrigen Gebiete werden voraussichtlich in einer späteren Version des Migrationsleitfadens um Produktvergleiche und Empfehlungen erweitert. 4.1 Übersicht In Anlehnung an das technische Modell der Rahmenarchitektur IT-Steuerung Bund' werden die The- mengebiete wie in Abbildung 4.1 dargestellt in verschiedene Bereiche unterteilt. Personal Dokumenten Web Content Web-Browser Information Office-Suiten Management Management u25 |-:Äiteha:)drienr Manager Systeme Systeme 9 Desktop und unterstützende Systeme Authentisierungs- Virtualisierung ; System- . . Client- Überwachung und ngrzemh- Groupware und Termu— Management nisdienste naldienste Infrastruktur Abbildung 4.1: Migrationsthemen Die Infrastruktur bildet den Grundstock eines IT-Systems, auf dem Dienste und Anwendungen aufbau- en. Solche Dienste und Anwendungen mit allgemeinem, ressortübergreifenden Charakter werden im ' Siehe (Rat09)
58 4 Migrationsgebiete Abschnitt Desktop und unterstützende Systeme beschrieben. Auf die speziellen Migrationsaspekte von ressortspezifischen Diensten und Anwendungen (Fachanwendungen), die die grundsätzlichen strategi- schen, wirtschaftlichen und rechtlichen Betrachtungen im Migrationsleitfaden überschreiten, kann hier nicht näher eingegangen werden?, Der Begriff Dienst ist in diesem Zusammenhang ein logisches Struk- turelement im Sinne der 0.g. Rahmenarchitektur und impliziert keine konkrete Technologie. Für jedes detailliert betrachtete Migrationsthema wird geprüft, welche Plattformen dafür genutzt werden können. Dabei wird für die Bereitstellung von Diensten auf die Plattformen Microsoft Windows und Linux eingeschränkt, für die Nutzung von Diensten wird das Apple-Betriebssystem MacOS X hinzugezogen. 4.1.1 Aufbau Die Migrationsthemen sind ähnlich strukturiert, um das Lesen und Auffinden der gesuchten Informatio- nen zu erleichtern, und gliedern sich in 1. Einleitung, N Kriterien, ©& Ist-Analyse, S Soll-Konzeption und N Produktauswahl. Nach der Einleitung werden die Kriterien umrissen, die bei der Ist-Analyse und der Soll-Konzeption des Themas zu berücksichtigen sind, ggf. ergänzt um Hinweise auf domänenspezifische Aspekte. Nun werden die betrachteten Alternativen eines Migrationsthemas vorgestellt, die grundsätzlich nach Markt- führerschaft, weitester Verbreitung im Behördenumfeld und verbreitetster Open-Source-Alternative aus- gewählt werden, jeweils bezogen auf Deutschland. Da hier Überschneidungen möglich sind, können die Anzahl an betrachteten Alternativen varlieren oder zweitplatzierte Alternativen hinzugezogen wer- den. Bei intensiv betrachteten Migrationsthemen werden zudem die alternativen Produkte anhand der aufgestellten Kriterien bewertet und daraus Empfehlungen abgeleitet. Eiwaige Empfehlungen beruhen ausschließlich auf der Bewertung der betrachteten Kriterien; kommen in einer Behörde weitere, insbesondere domänenspezifische Kriterien hinzu, können diese zu anderen Empfehlungen führen. Zu den domänenspezifischen Kriterien zählen neben funktionalen Aspekten auch strategische Rahmenbedingungen, welche speziell für die jeweilige Behörde gelten. Auch können die stets notwendige Wirtschaftlichkeitsbetrachtung, sowie die Analyse rechtlicher Aspekte eine andere als die empfohlene Alternative als insgesamt optimale Variante erscheinen lassen. 4.1.2 Bewertungs-Skalen Die Bewertungskriterien werden unterschieden nach binären und abgestuften Ergebniswerten. Binäre Ergebniswerte sind Wertpaare wie „Ja / Nein“ oder „unterstützt / nicht unterstützt“ und werden dann zur Bewertung genutzt, wenn es auf das Vorhandensein einer Eigenschaft ankommt. Die in den Bewer- tungstabellen dafür genutzte Skala ist in Tabelle 4.1 dargestellt: Tabelle 4.1: Skala für binäre Bewertungen Zeichen Bedeutung / ja / vorhanden - nein / nicht vorhanden ? Zur Plattformunabhängigkeit von Fachanwendungen siehe (Ko007).
4.1 Übersicht 59 Abgestufte Ergebniswerte erweitern eine solche Prüfung, indem sie die Eigenschaft in ihrer Ausprägung bewerten. Die Skalenbreite wird in Tabelle 4.2 dargestellt: Tabelle 4.2: Skala für abstufende Bewertungen Zeichen Bedeutung ++ sehr gut/wird vollständig unterstützt + gut/wird gut unterstützt 0 befriedigend/ wird im Wesentlichen unterstützt - schlecht/wird kaum unterstützt - sehr schlecht/wird gar nicht unterstützt 4.1.3 Bewertungsmethode Die alternativen Produkte eines Migrationsthemas werden auf die Erfüllung der jeweils aufgestellten Kriterien hin geprüft. Da die Kriterien eines Migrationsthemas regelmäßig technischer Natur sind und beispielsweise die Einhaltung offener Standards oder die Verarbeitung bestimmter Dateiformate betref- fen, wird meist die binäre Bewertungsskala verwendet. Für die Darstellung unterschiedlicher Qualitäten bei der Erfüllung eines Kriteriums kommt die abgestufte Skala zur Anwendung. Hierbei wird bei unter- schiedlicher Bewertung im Text auf die konkrete Über- oder Untererfüllung hingewiesen. Einem spezifischen Migrationsvorhaben steht es frei, über die hier enthaltenen Bewertungen hinaus wei- tere domänenspezifische Aspekte (s.u.)) hinzuzuziehen oder die Ergebnisse mit einer Nutzwertanalyse® anzureichern. 4.1.4 Domänen-Spezifika Praktisch jedes Migrationsthema hat Aspekte, die für Migrationsentscheidungen einzelner Behörden oder Abteilungen relevant sind, jedoch keine Allgemeingültigkeit aufweisen oder sich zumindest in der Relevanz deutlich unterscheiden. Solche Domänen-Spezifika sind in den Bewertungen des Migrations- leitfadens daher nicht enthalten, sollten aber bei der Bewertung einer konkreten Migration berücksichtigt werden. Sind die Domänen-Spezifika bereits in der Wirtschaftlichkeitsbetrachtung enthalten, ist kein wei- terer Handlungsbedarf geboten. Andernfalls sollte die im Migrationsleitfaden befindliche Bewertungsta- belle um die spezifischen Kriterien erweitert, deren jeweilige Bewertung eingetragen und die Gewichtung über alle Kriterien/-gruppen hinweg angepasst werden. 3 Siehe beispielsweise (Zan76)
60 4 Migrationsgebiete 4.2 Infrastruktur Analog zur Basis-IT der Rahmenarchitektur IT-Steuerung Bund beschreibt die Infrastruktur grundlegen- de Lösungen, die von anderen Teilen des Gesamtsystems genutzt werden können. Solche Lösungen reichen vom Domain Name System (DNS) bis zur Virtualisierung und vom Netzwerkdruck bis zur Sys- temüberwachung. Angesichts der schieren Vielfalt an Lösungen im Bereich der Infrastruktur beschränkt sich der Migrati- onsleitfaden auf die nähere Untersuchung der in Abbildung 4.2 dargestellten Themen und geht in der Einleitung auf einige sonstige Elemente gängiger Infrastrukturen ein. „ System- Authentisierungs- Virtualisierung Client- und Verzeich- Groupware und Termi- Überwachung Management nisdienste naldienste Infrastruktur Abbildung 4.2: Migrationsthemen In der letzten veröffentlichten Ausgabe des Migrationsleitfadens befasste sich das Modul Il mit der IT- Infrastruktur. Die dort aufgeführten Themen „Authentisierungs- und Verzeichnisdienste“ und „System- Überwachungs- und -Management-Dienste“ werden in diesem Unterkapitel eingehend beschrieben, während die Themen „Datenbank-Systeme“ und „Webserver“ aufgrund der regelmäßig starken Ver- flechtung mit Fachanwendungen im Migrationsleitfaden nicht betrachtet werden (siehe entsprechende Ausführungen unter 4.1. Die sonstigen Themen „Netzwerkdienste“, „Dateiablage“ und „Druckdienste“ des 0o.g. Moduls Il werden als Low-Level-Dienste nachfolgend kurz dargestellt. 4.2.1 Low-Level-Dienste Als Low-Level-Dienste werden in diesem Migrationsleitfaden solche Dienste verstanden, die Ressour- cen in ein Netzwerk einbinden, ohne sie — abgesehen von administrativen Funktionen — mit zusätzlicher Logik auszustatten. Low-Level-Dienste sind für das Funktionieren eines Netzwerks wesentlich und soll- ten daher in jedem IT-System vorhanden sein. Das Internet und die meisten Behörden- und Firmen-eigenen Netzwerke nutzen heute das Internet Protocol (IP), häufig in Verbindung mit dem Transmission Control Protocol (TCP). Beide Protokolle sind offene Standards und werden bei der Internet Engineering Task Force (IETF) geführt. Für die darauf basierenden Low-Level-Dienste haben sich in den letzten Jahren offene Standards durchgesetzt, die ebenfalls von der IETF verwaltet und von allen betrachteten Betriebssysteme unterstützt werden. Eine nähere Untersuchung wesentlicher Kriterien und diese unterstützender Produkte ist für diese Dienste daher entbehrlich. 4.2.1.1 Adress-Vergabe und Netzwerkkonfiguration Alle Ressourcen eines Netzwerks benötigen eine eindeutige numerische Adresse, um gezielt ange- sprochen werden zu können. Abhängig von der IP-Version ist die Adress-Vergabe bereits im Protokoll geregelt (IPv6) und bedarf keiner weiteren administrativen Tätigkeiten, oder sie muss beim Einsatz von IPv4 gesondert über das Dynamic Host Control Protocol (DHCP) bereitgestellt werden. Letzteres dient bei beiden IP-Versionen überdies der Zuweisung der Netzwerkkonfiguration an sich daran anmeldende Ressourcen, beispielsweise die Zuordnung eines Rechnernamens oder die Bekanntgabe der Adressen von Diensten zur Namensauflösung (s.u.) oder zur Zeit-Synchronisation (ntp).
4.2 Infrastruktur 61 Sämtliche Linux-Distributionen und die Server-Betriebssysteme von Windows enthalten einen Standard- konformen DHCP-Server. Die Funktionalität eines DHCP-Clients ist bei Windows, Linux und Mac OS X ein Bestandteil des Betriebssystems. Aufgrund des offenen Standards sind die DHCP-Dienste und - Clients unter Windows, Mac OS und Linux vollständig kompatibel. Bei der Umstellung des gegenwärtig noch eingesetzten IPv4 auf das künftige IPv6 gilt es zu beachten, dass die Verfolgbarkeit des einzelnen Anwenders durch die dauerhafte Vergabe eindeutiger IP-Adressen möglich wird. Dies ist aus Gründen das Datenschutzes nicht hinnehmbar. Bei der Konfiguration der End- geräte muss daher darauf geachtet werden, dass die dafür vorgesehenen Privacy Extensions for State- less Address Autoconfiguration in IPv6* ggf. aktiviert werden. Dies ist für alle untersuchten Plattformen und auch für die meisten Mobil-Plattformen möglich®. 4.2.1.2 Namensauflösung Damit Netzwerk-Ressourcen nicht über Zahlenreihen, sondern über einen Namen angesprochen wer- den können, muss der numerischen Adresse ein Name zugeordnet und die Zuordnung abgefragt werden können (Namensauflösung). Diese Aufgaben übernimmt das Domain Name System (DNS), ein weltweit verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets und ggf. des eigenen Intranets verwaltet. Die Namensauflösung innerhalb eines Behördennetzes wird über im Intranet befind- liche DNS-Server konfiguriert. Ggf. darüber hinaus gehende Anfragen reicht der interne DNS-Server an das weltweite DNS weiter. Die Adressen der internen DNS-Server werden üblicherweise per DHCP verteilt und stehen damit allen Netzwerk-Ressourcen des Intranets für die Namensauflösung zur Verfügung (s.o.). Analog zu DHCP ist die Funktionalität für DNS-Abfragen ein Bestandteil aktueller Betriebssysteme. Sämtliche Linux- Distributionen sowie die Server-Betriebssysteme von Windows enthalten einen Standard-konformen DNS-Server, der zur Intranet-Namensauflösung genutzt werden kann. 4.2.1.3 Dateiablage Für die Ablage von Dateien im Intranet und für den gemeinsamen Zugriff darauf wird ein Fileserver benötigt, mit dem über bestimmte Protokolle kommuniziert wird. Der heute verbreitetste Standard für solche Zugriffe ist das von Microsoft entwickelte und inzwischen offengelegte Common Internet File System (CIFS), das frühere Server Message Block Protokoll (SMB). Microsoft bietet diese Möglichkeit als „Windows Server File Services“ an, unter Linux kann das OSS-Projekt SAMBA® für die Bereitstellung entsprechender Dienste genutzt werden. Client-seitig verfügen alle betrachteten Betriebssysteme über Funktionalitäten zum Zugriff auf Dateiablagen über CIFS/SMB. Die reine Dateiablage bietet keine Funktionalität zur Versionierung einzelner Dateien oder zum Schutz vor gegenseitigem UÜberschreiben oder Löschen. Hierfür müssen ggf. weitere Dienste wie eine Versi- onsverwaltung oder sonstige Kollaborations-Lösungen eingesetzt werden. 4.2.1.4 Druckdienste Professionelle Drucker verfügen über eine Netzwerk-Schnittstelle, über die sie im Intranet genutzt wer- den können. Solche Drucker agieren selbst als Druck-Server und können regelmäßig über verschiedene Protokolle wie Internet Printing Protokoll (IPP), Common Unix Printing System (CUPS) und Line Prin- ter Daemon Protocol (LPDP) angesprochen werden. Moderne GClients verfügen auf allen betrachteten Plattformen über die Funktionalität, um Netzwerk-Drucker über die 0.g. Protokolle nutzen zu können. Drucker ohne eingebauten Druck-Server können über einen angeschlossenen Rechner ebenfalls im Netzwerk bereitgestellt werden; allerdings muss hierzu ein Druck-Server auf diesem Rechner installiert und der Drucker für die Verwendung im Netzwerk freigegeben werden. Microsoft bietet diese Möglichkeit 4 Siehe http://tools.ietf.org/html/rfc4941 5 Siehe http: //heise.de/-1204783 S http://www.samba.org
62 4 Migrationsgebiete als „Windows Server Print Services“ als Teil des CIFS an, unter Linux kann wie für die Dateiablage SAMBA für die Bereitstellung entsprechender Dienste genutzt werden. 4.2.1.5 Komplettlösungen und Distributionen Komplettlösungen für die Infrastruktur werden in verschiedener Form angeboten. Allen gemeinsam ist, dass sie die oben genannten Low-Level-Dienste vollständig unterstützen. Sie unterscheiden sich aller- dings in der Unterstützung der nachfolgend detaillierter beschriebenen Dienste (siehe dort) und auch bei den Lizenzmodellen. 4.2.1.5.1 Microsoft Server 2008 R2 Microsoft Server 2008 R2 wird auf der Basis traditioneller Software-Lizenzen in verschiedenen Editionen mit unterschiedlichen Merkmalen und Preisen angeboten. Eine optimale Versorgung mit den tatsächlich für den jeweiligen Behördenbetrieb benötigten Lizenzen ist aufgrund deren Vielfalt und unterschiedli- cher Abhängigkeiten nicht trivial” und sollte ggf. über entsprechend geschultes Personal oder externe Dienstleister bezogen werden. Der Quellcode der einzelnen Komponenten ist nicht offengelegt, es han- delt sich durchweg um proprietäre Software (siehe 2.7). Microsoft unterstützt die einzelnen Versionen seiner Server-Distribution regelmäßig über mehrere Jahre hinweg. Gegen zusätzliche Kosten ist auch ein erweiterter Support über das allgemeine Unterstützungsende hinaus möglich. 4.2.1.5.2 Linux-Distributionen Alternativ dazu existieren verschiedene Anbieter sogenannter Enterprise Editionen auf der Basis von Linux, beispielsweise ! Debian GNU/Linux, ! Red Hat mit dem Red Hat Enterprise Linux (RHEL), { Novell mit dem Suse Linux Enterprise Server (SLES), ! Canonical mit der Ubuntu Long Term Edition (Ubuntu LTE) und ! Univention mit dem Univention Corporate Server (UCS). Diesen Linux-Distributionen ist gemeinsam, dass die jeweilige (Server-)Version über einige Jahre hin- weg supported wird und die Software im Quellcode frei verfügbar, also Open-Source-Software ist. Ei- nige der Distributionen können über ein Abonnement-Modell mit einfach gestalteten Lizenzen bezogen werden. Über solche Abonnements erhält der Käufer die Distribution in einer unmittelbar installierba- ren Binärform, Zugriff auf technische Unterstützung und je nach Abonnement weitere Leistungen wie Rechtsschutz gegenüber Software-Patenten (Legal Assurance). 7 Siehe http://www.microsoft. com/germany/windowsserver2008/r2-1lizenzierung.mspx
