Dokumentation der betrieblichen Projektarbeit

Transkript

1 Dokumentation der betrieblichen Projektarbeit Abschlußprüfung Sommer 2009 Fachinformatiker Systemintegration Einrichten einer indizierten Datenbank für das Wissensmanagement in Form einer webbasierten Softwarelösung in der Choren Unternehmensgruppe mit Gruppen- und Benutzerverwaltung unter Anbindung an eine bestehende Active-Directory-Struktur Projektausführender Jörg Gerlach Azubi-Identnummer Projektbetreuer Praktikumsunternehmen Ausbildungsunternehmen Kooperationsverbund der IT- Dienstleister Südwestsachsen e.v. (KITD)

2 Inhaltsverzeichnis Erklärung... 1 Hinweis Analyse Soll-Zustand Ist-Zustand Auswahl und Bewertung der zu verwendenden Softwarelösung Auswahl des Betriebssystems Realisierung Ablauf Einrichtung der virtuellen Maschine Installation des Betriebssystems Installation der Wissensdatenbank Installation auf der Linux-Shell Installation über die Weboberfläche Abschließende Arbeiten auf der Linux-Shell Einrichtung der Wissensdatenbank Rollen Einrichtung der Active-Directory-Anbindung Benutzergruppen Einrichtung der einzelnen Wikibereiche Verschiedene Einstellungen Testphase Probleme Page Notification Anmeldung mit Domänenanmeldedaten Nicht durchgeführte Teilaspekte Anpassung Layout/Design Einrichtung Single Sign-On...13

3 3 Übergabe und Inbetriebnahme Übergabe an die Mitarbeiter der IT-Abteilung Übergabe an die Geschäftsführung und Inbetriebnahme Fazit Glossar Anlagen Zeitplanung...18 Abbildungen...19 Tabellen...22 Befehlsübersicht...25 Quellen...29 Angebot...31 Testprotokoll...32 Dokumentinformationen...33

4 Erklärung Hiermit erkläre ich, der Unterzeichner, dass ich die vorliegende Projektarbeit selbstständig und in der vorgegebenen Zeit durchgeführt habe. Sämtliche von mir verwendeten Quellen sind im Anhang dieser Dokumentation aufgeführt. Mit der Durchführung des Projektes wurde am begonnen. Die Durchführung des Projektes wurde am abgeschlossen. Ort, Jörg Gerlach Seite 1

5 Hinweis Auf Grund der vom Prüfling im Unternehmen unterzeichneten Geheimhaltungsverpflichtung sind einige, für die Dokumentation nicht relevante Informationen (besonders IP-Adressen) anonymisiert worden. Dies ist erkennbar an der Verwendung des Wortes anonymisiert. Begriffe, welche im Glossar erklärt werden, sind mit einem hochgestellten Zahlenindex ( 1 ) versehen. Befehle, welche für die Ausführung der beschriebenen Vorgänge erforderlich waren, sind in der Befehlsübersicht detailliert ausgeführt. Im Text findet sich dazu der hochgestellte B-Index ( B1 ). Befehle und Pfade wurden zudem in der Schriftart Courier New formatiert. 1 Analyse 1.1 Soll-Zustand Die Unternehmensgruppe CHOREN möchte in absehbarer Zukunft ein Intranet aufbauen. CHOREN benötigt im ersten Schritt für die gesammelte Ablage ihres Unternehmenswissens eine flexible und webbasierte 1 Sammelstelle, die allen Mitarbeitern unkompliziert zur Verfügung steht. Im Folgenden wird diese Sammelstelle als Wissensdatenbank bezeichnet. Wissen soll von allen Mitarbeitern abgelegt und/oder abgerufen werden können. Nach Gesprächen mit dem verantwortlichen Geschäftsführer stellte sich heraus, dass eine webbasierte Lösung im internen Netzwerk die beste Möglichkeit ist, um unkomplizierten Zugang für die Mitarbeiter zu gewährleisten. Wissen soll sowohl in Form von indizierten 2 Texten als auch in Form von Dateien (Dokumente, Bilder) bereit stehen. Über die Indizierung der abgelegten Informationen soll eine schnelle Suche nach Stichworten und Inhalten möglich sein. Inhalt soll dabei in Kategorien eingeordnet werden, zu denen der Zugang nach Unternehmenszugehörigkeit der Mitarbeiter eingeschränkt werden kann. Es ist eine Lösung zu wählen, die folgende Bedingungen erfüllt: Die Lösung und das verwendete Betriebssystem müssen für das Unternehmen kostenfrei sein. Die Lösung muss eine Benutzer- und Gruppenverwaltung über das bestehende Active Directory 3 ermöglichen. Die Lösung muss über eine flexible und detailliert einstellbare Rechteverwaltung verfügen. Die Wissensdatenbank muss sich in Kategorien einteilen lassen, zu denen abhängig von Unternehmenszugehörigkeit und Position im Unternehmen Zugang gewährt wird. Die dabei gewährten Rechte umfassen neben dem Lese- und Schreibrecht auch die Möglichkeit, Rechte an andere Benutzer zu vergeben. Diese Möglichkeit soll vor allem Fachbereichsleitern und Geschäftsführern offen stehen, um flexibel und ohne Einschalten der IT-Abteilung Wissen nach Vorgaben der Verantwortlichen im Unternehmen zu verbreiten. Lese- und Schreibrechte sollen sich unabhängig voneinander erteilen lassen. Die Lösung muss die Möglichkeit bieten, alle bereits vorhandenen Daten (MS-Office- und PDF-Dateien) einzubinden. Es soll keine neue Hardware angeschafft werden. Die Wahl des verwendeten Betriebssystems bleibt dem Prüfling überlassen. Es ist jedoch darauf zu achten, die Wahl auf Systeme zu beschränken, die von anderen IT-Mitarbeitern in Abwesenheit des Prüflings administrierbar sind. Ziel dieses Projektes ist die Fertigstellung des ersten Schritts auf dem Weg zum Unternehmensintranet, die Einrichtung der Wissensdatenbank. Seite 2

6 1.2 Ist-Zustand Die Unternehmensgruppe CHOREN besteht aus mehreren Einzelunternehmen. Namentlich sind das, CHOREN Biomass GmbH, CHOREN Technologies GmbH, CHOREN Components GmbH, CHOREN Fuel GmbH und CHOREN USA LLC. Diese Unternehmen sind über mehrere weltweite Standorte (Freiberg, Sachsen/Deutschland, Hamburg/Deutschland, Houston, Texas/USA, Peking/China) verteilt. Alle Einzelunternehmen werden in einer Windows-Domäne 4 verwaltet. Diese Domäne wird von mehreren Windows Domänencontrollern betreut, die auf mehreren weltweit verteilten Windows 2003 Servern installiert wurden. Die Benutzer-, Computer- und Ressourcenverwaltung erfolgt in der Regel auf dem im Hauptgebäude in Freiberg befindlichen Domänencontroller 5 und wird durch die Mitarbeiter der IT-Abteilung vorgenommen. Auf den Arbeitsstationen der Mitarbeiter wird bis auf wenige Ausnahmen Microsoft Windows XP Professional eingesetzt. Es existieren neben diversen physischen Servern für Domänencontroller-, Terminal- und Dateiserverdienste auch einige virtuelle Server, die auf einem HP-Server 6 mit VMware ESX Server aus der Produktlinie VMware Infrastructure 3 7 betrieben werden. Die momentane Situation in der Verwaltung des Unternehmenswissens ist dergestalt, dass alle Informationen wie Arbeitsanweisungen, Projektdaten, technische Dokumentation und ähnliches in MS-Officedateien und/oder PDF-Dateien gespeichert werden und diese wiederum auf mehreren Fileservern abgelegt werden. Auf den Dateiservern existiert eine Verzeichnis- und Freigabestruktur, die von der IT-Abteilung streng überwacht wird und auf die bis auf wenige Ausnahmen wie für die Geschäftsführung für alle Mitarbeiter maximal Lesezugriff besteht. Dies wird über die NTFS- Sicherheitseinstellungen realisiert. Der Nachteil dieser Lösung liegt auf der Hand: einerseits erfordert die Gewährung eines Schreibzugriffes für den Fall von Änderungen an den Informationen einen Eingriff der IT-Abteilung, was Zeit kostet, andererseits benötigen die Mitarbeiter durch den hohen Anteil von PDF-Dokumenten eine Anwendung, mit der sie diese Dokumente bearbeiten können. Da es sich im Unternehmen leider eingebürgert hat, dass PDF-Dokumente archiviert werden, deren Ursprungsdokumente (in der Regel Officedateien) jedoch nicht, benötigen viele Mitarbeiter Zugang zu der Anwendung Adobe Acrobat. Diese Lizenzen sind kostenintensiv und vor allem in dieser Menge unnötig. 1.3 Auswahl und Bewertung der zu verwendenden Softwarelösung Schon im ersten Gespräch mit dem verantwortlichen Geschäftsführer stellte sich heraus, dass ein Wiki den Wünschen des Auftraggebers am ehesten entsprechen würde. Ein Wiki zeichnet sich durch seine baumartige Struktur und seine einfache Bedienbarkeit aus. Selbst bei der Verwendung eines einfachen browserbasierten Editors ist es dem Benutzer in kürzester Zeit möglich, Texte für die Seiten in ein Wiki einzustellen, zu bearbeiten und zu formatieren. Gute Wiki-Systeme bieten außerdem einen benutzerfreundlichen WYSIWYG-Editor 8, in welchem ähnlich einer Textverarbeitung geschrieben werden kann, ohne Kenntnisse über die zugrundeliegende Formatierungsstruktur zu besitzen. Weiterhin sollen Benutzer die Möglichkeit haben, mittels eines einfachen Formulars Dateien an Artikel anzuhängen. Ein Benutzer soll sich dabei nicht um Speicherplatz oder Zugriffsrechte kümmern müssen, sondern vom Wiki die passende Funktion zum passenden Zeitpunkt angeboten bekommen. Sowohl Artikel als auch Dateien werden in einem Wiki versioniert 9. Dies ist der größte Unterschied zu einem Content Management System 10. Eine Bedingung, die von der Geschäftsführung von Anfang an gestellt wurde, war die Durchsetzung einer Rechteverwaltung, die nach Möglichkeit für die Benutzer und Benutzergruppen, die bereits im Active Directory existieren, wirken sollte. Die Rechtevergabe sollte so fein wie möglich einstellbar sein, um diverse Rechte und Rechtekombinationen vergeben zu können. Die zu findende Lösung Seite 3

7 bietet also im Idealfall ACLs 11 oder eine rollenbasierte Rechteverwaltung 12 an, die sich sowohl auf Benutzer als auch auf Benutzergruppen anwenden lässt. Einen wesentlichen Vorteil der neu einzuführenden Lösung gegenüber der bestehenden Verzeichnisstruktur gilt es noch zu erwähnen: die Durchsuchbarkeit. Alle Texte, die dem Wiki zugeführt werden, sind von einer integrierten Suchfunktion auffindbar. Zusätzlich sollte die Softwarelösung die Möglichkeit bieten, Dokumente zu durchsuchen, die den einzelnen Seiten angehangen werden. Spätestens an dieser Aufgabe scheitert die in Microsoft Windows XP integrierte Suchfunktion regelmäßig. Die gewählte Lösung soll also in der Lage sein, eingebundene Dokumente (sofern sie aus Text und nicht nur eingescannten Grafiken besteht) zu indizieren und den Inhalt dem Suchindex hinzuzufügen oder Dokumente zumindest in Echtzeit zu durchsuchen. Praktisch durchgeführt wurde aufgrund dieser Rahmenbedingungen ein Vergleich zwischen MediaWiki von der Wikimedia Foundation, Twiki von Peter Thoeny sowie Deki Open- Source-Edition (OSE) von MindTouch Inc. inklusive des Updates auf Version Der Vollständigkeit halber wurde auch ein Content Management System mit in den engeren Kreis der Auswahl einbezogen. Diese Auswahl dient allerdings eher dem Nachweis, dass ein CMS für diese Aufgabe nicht die richtige Wahl wäre. Als CMS wurde Joomla von OpenSourceMatters Inc. ausgewählt. Die Auswahl erfolgte anhand der Kriterien, welche in Tabelle 1 hinterlegt sind. Alle Softwarelösungen wurden auf einem mit VMware ESX eingerichteten virtuellen Linux-Server installiert und vom Prüfling getestet. Nachfolgend einige Worte zur Bewertung. Beim Mediawiki fehlte ein konsequentes Rechtemanagement. Es ließen sich zwar ohne weiteres einzelne Bereiche des Wikis für bestimmte Benutzer oder Gruppen sperren, jedoch konnte jeder Mitarbeiter durch einfachste, ihm unauffällige Fehler neue Bereiche anlegen, die dann keiner Zugriffskontrolle mehr unterlagen und so möglicherweise sensible Informationen an alle Mitarbeiter verteilten. Dies ist der Konzeption von MediaWiki geschuldet. Wikimedia versteht unter einem Wiki eine für alle offene Plattform zum Sammeln und Austausch von Wissen. Dies geht allerdings nicht immer konform mit den Ansprüchen eines Unternehmens an ein Enterprise 13 -Wiki. Beim Twiki sind theoretisch zwar fast alle gewünschten Funktionen vorhanden, jedoch ist die Bedienung des Wikis einem ungeübten Mitarbeiter, der dieses Wiki als Unterstützung seiner Tätigkeit sucht, nicht zuzumuten. Die Nutzung des Wikis in allen für die Mitarbeiter sinnvollen Bereichen wie Texterstellung, Dateiupload oder Versionsverwaltung erfordert eine längere Einarbeitungszeit, als sie dem durchschnittlichen Mitarbeiter dafür zur Verfügung steht. Das System soll dem Unternehmen ohne große Lernphase sofort und eingänglich zur Verfügung stehen, Einarbeitungszeiten sind bei den meisten Mitarbeitern aufgrund des täglichen Arbeitspensums nicht praktikabel. Ein Beispiel: es ist nicht ohne Weiteres möglich, mittels eines einfachen Buttons oder ähnlichem eine Seite zur Beobachtungsliste hinzuzufügen und sich bei Änderungen an dieser Seite per benachrichtigen zu lassen. Diese einfache Funktion erfordert vom Mitarbeiter, dass er eine Spezialseite im Wiki findet und dort mit einer bestimmten Syntax seinen Benutzernamen einträgt. Selbst bei solch einfachen Funktionen sind Fehler unvermeidlich. Wie jedes andere System wurde auch Twiki an anderen Mitarbeitern der IT-Abteilung getestet, um zu überprüfen, ob diese das System auch in Abwesenheit des Prüflings administrieren können. Möglich war das bei allen Systemen außer Twiki. Auch hier hätte jeder IT-Mitarbeiter eine Einweisung benötigt, die über den zur Verfügung stehenden Zeitrahmen hinaus ging. Beim MindTouch Deki stößt man auf ein durchdachtes Bedienkonzept, welches auf der Startseite beginnt und sich bis in die Systemsteuerung 14 fortsetzt. Die Bedienung der Oberfläche ist einfach, die Erstellung von Inhalten und das Anfügen von Dateien mit wenigen Handgriffen zu erledigen und die Konfiguration über eine vom Inhalt des Wikis getrennte Systemsteuerung einzustellen. Für den Prüfling von großem Vorteil waren außerdem die hilfreiche und große Community, die den fehlenden Seite 4

8 Herstellersupport für die Open-Source-Edition mehr als wettmacht. Den Communitysupport leisten darüber hinaus auch einige Mitarbeiter des Herstellers. Bedenken bezüglich Deki gab es trotzdem. Die zum Testzeitpunkt aktuelle Version unterstützte bei zugriffsbeschränkten Bereichen keine rollenbasierte Berechtigungssteuerung. Das führte dazu, das eingerichtete Rollen nur dann Wirkung zeigten, wenn Bereiche öffentlich waren. Bei Bereichen mit Zugriffssteuerung war nur eine vordefinierte Rolle möglich, was den Anforderungen nicht entsprach. Dieses starre Prinzip wurde mit der aktuellen Version 9.02 aufgehoben, welche während des Testzeitraumes erschien. Für jeden Bereich lassen sich damit nicht nur benutzer- und gruppenbasierte Zugriffe vergeben, auch die Rechte der jeweiligen Benutzer und Gruppen sind nun auf Basis der erstellten Rollen einstellbar. Weitere Bedenken gab die Verwendung von Mono auf. Mono ist eine Open-Source-Umsetzung des.net-frameworks 15 von Microsoft, welche es sich zum Ziel gesetzt hat, eine quelloffene Umgebung für.net-basierte Anwendungen für die Betriebssysteme MS Windows, Apple MacOS und Linux anzubieten. Damit lassen sich beispielsweise.net-anwendungen für Windows auch für Linux kompilieren und dort ausführen. Der Nachteil dieser Lösung ist die indirekte Abhängigkeit von Microsoft in Bezug auf Funktionen, die das originale.net-framework zwar bietet, Mono jedoch noch nicht. Daraus kann eine gewisse Inkompatibilität resultieren. Mono in Version 2 ist momentan featurekompatibel mit.net-framework 2.0 von Microsoft. Nach Gesprächen mit Mitarbeitern der IT- Abteilung und regem kontakt mit einem der Mindtouch-Entwickler stand dann allerdings fest, dass das daraus resultierende Risiko zu vernachlässigen ist, da sich MindTouch Deki auf absehbare Zeit an Mono statt am.net-framework orientieren wird. Der letzte Testkandidat Joomla in Version stand beispielhaft für die Vertreter der Content Management Systeme. In der Standardausführung ohne diverse Erweiterungen und Änderungen am Code bietet das CMS weder eine Versionsverwaltung noch eine Indexierung der angehangenen Dokumente. Zwar ließe sich mit viel Aufwand auch eine annähernde Funktionsweise wie bei einem Wiki herstellen, allerdings bliebe dann die Frage offen, warum nicht gleich ein Wiki eingesetzt wird. Darüber hinausgehende Vorteile bot das CMS für den gewünschten Einsatzzweck nicht. Stattdessen bietet das getestete Joomla nur eine starre vorgegebene Gruppenverwaltung und Zugriffssteuerung, die sich nicht ohne weiteres an die Vorgaben der Geschäftsführung anpassen ließ. Die Wahl fiel daher eindeutig auf MindTouch Deki Open Source Edition in Version Auswahl des Betriebssystems Aufgrund der Vorgabe der Geschäftsführung, dass die bereitzustellende Lösung für das Unternehmen kostenfrei sein sollte, gab es 2 Möglichkeiten. Zum einen konnte man auf einem bestehenden Microsoft Windows 2003 Server die dort vorhandenen Internet Information Services (IIS) nutzen. Dieser Serverdienst stellt den von Microsoft angebotenen Webserver dar. Er ist bereits im Betriebssystem integriert, kostet keine weiteren Lizenzgebühren und lässt sich sowohl mit einer Datenbank als auch mit diversen Skriptsprachen wie Perl 16 oder PHP 17 verbinden. Die andere Möglichkeit wäre ein virtueller Server auf Linuxbasis. Eine Virtualisierungslösung ist im Unternehmen bereits vorhanden, die notwendige Hardware steht ebenfalls zur Verfügung und ein kostenfreies Betriebssystem auf Linuxbasis ist ebenfalls problemlos erhältlich. Aufgrund der Tatsache, dass der Server mit Microsoft Windows 2003 Server bereits mit Dateidiensten und der Benutzerverwaltung über Active Directory belastet wird, schied diese Variante aus. Weiterhin sollen auf dem einzurichtenden Webserver später noch weitere Systeme wie zum Beispiel ein Ticketsystem sowie andere Intranetanwendungen ausgeführt werden, so dass ein dedizierter 18 Webserver die bessere Wahl erschien. Ebenfalls wurde beachtet, dass aufgrund langjähriger Erfahrung eines Kollegen der IT- Abteilung der Apache-Webserver als der stabilere der beiden angesehen wird. Der Prüfling verfügt ebenfalls über Erfahrungen mit dem Apache-Webserver. Die Wahl fiel deshalb auf einen neu einzurichtenden virtuellen Server. Als Betriebssystem bot sich aufgrund der während der Ausbildung Seite 5

9 gesammelten Erfahrungen ein debianbasiertes Linux an. Da die Wahl zwischen Ubuntu Server und Debian schwankte, gab die jahrelange Erfahrung eines Kollegen der IT-Abteilung den Ausschlag in Richtung Debian Etch Auf Debian Lenny 5 wurde verzichtet, da diese Version erst kurz vor der Projektdurchführung veröffentlicht wurde. Bevor nicht erste Erfahrungen mit der neuen Version gesammelt werden, ist der Griff zu einer erprobten Version die bessere Wahl. 2 Realisierung 2.1 Ablauf Das Projekt wurde wie folgt abgearbeitet: Gespräch mit Praktikumsbetreuer und Geschäftsführer Hamburg Auswahl Betriebssystem Einrichtung virtuelle Maschine Installation Debian Linux und Serverdienste Installation und Test der 4 möglichen Lösungen 1. MediaWiki 2. Twiki 3. Deki 4. Joomla Deinstallation/Entfernung der Testinstallationen aller Lösungen Installation und Einrichtung von MindTouch Deki Arbeiten am Active Directory Testphase Erstellung Dokumentation Übergabe an IT-Abteilung und Geschäftsführung 2.2 Einrichtung der virtuellen Maschine Da der Server als virtuelle Maschine unter VMware ESX eingerichtet werden sollte, wurde mit Hilfe des VMware Infrastructure Clients eine neue Maschine angelegt. Dieser Maschine wurden 95GB Festplattenspeicher und 2GB Arbeitsspeicher zugewiesen. Der Festplattenspeicher verteilt sich dabei auf 2 Festplatten. Näheres dazu weiter unten im Text. Das Netzwerkinterface wurde als Hostinterface (bridged) eingerichtet. Damit umgeht man den Aufwand, NAT-Regeln 19 oder Proxy- ARP 20 einzurichten. Anschließend wurde das CD-ROM-Laufwerk des lokalen PCs des Prüflings in die virtuelle Maschine eingebunden, eine Debian Etch - CD-ROM eingelegt und die Maschine gestartet. 2.3 Installation des Betriebssystems Von der eingebundenen CD wurde das Betriebssystem Debian Etch installiert. Debian wurde ohne grafische Oberfläche installiert, auch auf sämtliche Serverdienste wurde vorerst verzichtet. Als Name für den Server wurde choren-vm07 (durchgehende Nummerierung aller virtuellen Server im Unternehmen) gewählt, als Domäne wurde die unternehmensinterne Domäne choren.local angegeben. Bei der Partitionierung des Festplattenspeichers wurde eine primäre root-partition mit 13GB, eine primäre var-partition mit 79GB und eine primäre Swap-Partition mit 3GB eingerichtet. Sowohl die root- als auch die swap-partition liegen dabei auf einer logischen Festplatte, die var- Partition mit allen Anwendungsdaten liegt auf einer zweiten logischen Festplatte. Auf dieser zweiten Festplatte liegen die Partitionen mit Anwendungsdaten anderer virtueller Server. Durch diese Aufteilung des Speicherplatzes ist es leichter möglich, bei späterem Platzmangel die Festplatte durch Seite 6

10 eine größere auszutauschen. Dazu müssten lediglich alle Daten auf eine größere Festplatte übertragen werden und die neue Festplatte gemounted werden. Bei der Installation wurde der im Unternehmen verwendete Proxy 21 angegeben. Dieser Proxy B1 wird außerdem als globale Variable für die Nutzung von wget B2 benötigt. wget wird von einigen zu installierenden Paketen genutzt. In der Datei /etc/network/interfaces B3 wurde die Netzwerkverbindung konfiguriert. Auf dem Domänencontroller, der auch den DNS-Server beherbergt, wurde anschließend ein neuer A- Record 22 (Host) angelegt. Die eben vergebene IP-Adresse wurde dem Namen chorenvm07.choren.local zugewiesen. Anschließend wurde ein Alias (CNAME) namens wiki.choren.local für den Eintrag choren-vm07.choren.local angelegt. Dies ist der DNS-Name, unter dem das zu installierende Wiki später im Browser erreichbar sein wird. Nach der Installation des Betriebssystems wurden alle benötigten Serverdienste installiert und eingerichtet. Die Installation der Dienste wurde mit der Paketverwaltung APT in der Konsole realisiert B4. Benötigt für den Betrieb des Wikis werden der Webserver Apache, das Datenbankmanagementsystem MySQL, die Skriptsprache PHP, das Bildmanipulationsprogramm ImageMagick, der Mailserver postfix und die MySQL-Weboberfläche phpmyadmin. phpmyadmin ist für den Betrieb des Wikis nicht notwendig, erleichtert jedoch aufgrund der grafischen Benutzeroberfläche den Umgang mit den MySQL-Datenbanken enorm. Installiert wurden folgende Paketversionen: Apache MySQL PHP ImageMagick phpmyadmin postfix Apache, PHP, ImageMagick und phpmyadmin lassen sich ohne weitere Eingaben direkt mittels apt installieren. Nach der Installation von MySQL ist wurde für den MySQL-Nutzer root auf der MySQL-Shell ein Passwort angelegt B5. Bei der Installation von Postfix werden die grundlegenden Konfigurationsdaten abgefragt. Installiert wurde Postfix als Satellitensystem 23. Diese Funktionalität ist ausreichend, da von diesem Server nur s für die Benachrichtigungsfunktion des Wikis versendet werden. Als Hostname des Postfix- Servers dient dabei der Hostname des Servers (choren-vm07.choren.local) und als Relayhost der Microsoft Exchange-Server (choren-exch.choren.local) B6. An der PHP-Konfiguration wurde nun noch die maximal erlaubte Dateiuploadgröße auf 64MB verändert B7. Da noch nicht abzuschätzen ist, welche Datenmengen in Zukunft ins Wiki eingestellt werden, wurde dieser große Wert gewählt. Eine weitere Begrenzung der maximalen Dateigröße kann später auch im Wiki selbst vorgenommen werden. Am Apache-Webserver wurden keine weiteren Einstellungen getätigt. Die nötigen Konfigurationsoptionen werden bei der Installation des MindTouch Deki durch eine entsprechend vorbereitete Konfigurationsdatei für den virtuellen Host wiki.choren.local eingespielt. Im Anschluss an die Installation ließ sich die Funktion des Webservers mit dem Aufruf der Default Site testen. Im Browser führte die URL zur bekannten Apache- Meldung It works!. Die URL führte erwartungsgemäß zum installierten phpmyadmin, bei dem das Login mit dem Benutzer root und dem vorher erstellten Passwort reibungslos funktionierte. Seite 7

11 2.4 Installation der Wissensdatenbank Installation auf der Linux-Shell MindTouch stellt das Deki in der Open Source Edition sowohl als Quelltext, als Tar-Files und als Installationspakete für diverse Linuxdistributionen zur Verfügung. Für debian-basierte Distributionen finden sich im MindTouch-Repository deb-pakete, die sich beispielsweise mittels apt installieren lassen. Damit apt das Repository findet, muss dieses in der Datei /etc/apt/sources.list als Paketquelle eingetragen werden B8. Nach Änderungen an der Quellendatei aktualisiert die Datenbank, in welcher die installierten und verfügbaren Pakete aller eingetragenen Repositories verzeichnet sind. Um im Deki die vollständige Funktionalität nutzen zu können, wurden zuvor noch einige Pakete installiert. Dazu zählen msttcorefonts (Schriftarten), cabextract (zum Entpacken von CAB-Archiven), html2text (HTML-zu-Text-Konverter) und poppler-utils (diverse PDF-Indizierungs- und Bearbeitungstools) B9. Die von Deki empfohlene Installation von Prince XML wurde nicht vorgenommen. Mit Prince XML lassen sich im Wiki ohne externe Software PDF-Dateien aus Artikeln erzeugen. Da Prince XML jedoch kostenpflichtig ist (pro Serverlizenz knapp 2500 US$) und auf allen PCs im Unternehmen ein PDF-Drucker installiert ist, können sich die Mitarbeiter bei Bedarf über die im Wiki integrierte Druckfunktion ein PDF erstellen. Nachdem dem Abschluss aller Vorbereitungen wurde das Wiki installiert. Mit dem Befehl apt-get install dekiwiki installiert apt das Deki-Paket aus den MindTouch-Repositories und lädt die Zertifikate von vertrauenswürdigen Stammzertifizierungsstellen von der Mozilla LXR-Webseite herunter. Außerdem wird ein Nutzer dekiwiki eingerichtet. Dieser Benutzer gehört zur Gruppe wwwdata (Benutzergruppe des Apache-Webservers) und verfügt über keine root-rechte. Die Zertifikate wurden anschließend als Benutzer dekiwiki mit vorübergehenden root-rechten installiert B10. Die Installation des MindTouch Deki richtet für den Apache-Webserver einen neuen virtuellen Host ein. Dessen Konfigurationsdatei mit dem Namen dekiwiki liegt im Verzeichnis /etc/apache2/sites-available/. In dieser Datei ist der Servername (wiki.choren.local) anzupassen. Um auf Webserverebene sicherzugehen, dass der Zugang zum Wiki nur aus dem internen Netzwerk erfolgen kann, wurde mittels einer Direktive der Zugriff auf die IP-Adressbereiche des Unternehmensnetzwerks begrenzt B11. Anschließend wurde der virtuelle Host aktiviert und der Webserver angewiesen, seine Konfigurationsdateien neu zu laden B Installation über die Weboberfläche Um das Wiki auf dem Server einzurichten und mit allen nötigen Konfigurationsoptionen wie Datenbankanbindung u. ä. zu versorgen, muss das Wiki über den Link aufgerufen werden. In der Eingabemaske werden alle relevanten Informationen eingetragen (Abbildungen 1 und 2). Seite 8

12 2.4.3 Abschließende Arbeiten auf der Linux-Shell Nach dem Eintragen und Bestätigen der Daten verbindet das Wiki zum Datenbankmanagementsystem, erstellt die Datenbank inklusive aller Tabellen, richtet den Administrator ein, erstellt eine Ordnerstruktur für Dateianhänge und die Konfigurationsdateien. Der Besitzer aller erstellten Dateien und Ordner ist der Benutzer des Apache-Webservers (www-data). Die Dateirechte sind standardmäßig restriktiv eingestellt. Die Datei LocalSettings.php beispielsweise hat die Dateirechte Damit kann der Nutzer www-data in der Datei lesen und schreiben, die Gruppe www-data kann in der Datei lesen. Andere Benutzer oder Gruppen (vom Benutzer root abgesehen) haben keine Zugriffsmöglichkeit auf die Datei. Um die Installation abzuschließen, wurden die Konfigurationsdateien in die passenden Ordner verschoben B13 und das Wiki mittels /etc/init.d/dekiwiki start gestartet. Zur Überprüfung, ob die Installation und der Start der zum Betrieb des Wikis nötigen Dienste erfolgreich waren, empfiehlt sich ein Blick in die Prozessanzeige. Mit dem Befehl ps -ax grep Suchausdruck lassen sich alle gesuchten Prozesse anzeigen. Wichtig für die Ausführung des Wikis sind die Prozesse apache2, mysqld sowie mono mit einem Parameter, der auf die MindTouch-API verweist. Die Ausgabe ergab die Ausführung der gesuchten Dienste und Anwendungen B14. Damit ist das Wiki installiert und per Browser erreichbar. 2.5 Einrichtung der Wissensdatenbank Nach Abschluss der Installation erfolgte die Einrichtung des Wikis. Dazu gehören die Einrichtung der Active-Directory-Anbindung, der einzelnen Unternehmensbereiche im Wiki, der Rollen und der Benutzergruppen. Für einen Großteil dieser Aufgaben benutzt man die Systemsteuerung des Wiki (Control Panel) Rollen MindTouch Deki bietet nach Installation 5 vorgefertigte Rollen, deren Rechte in Tabelle 2 aufgeführt sind. Um für diejenigen Benutzer, die später Zugriffsrechte verteilen dürfen, die Rollenverwaltung möglichst leicht durchschaubar zu gestalten, wurden 3 neue Rollen eingerichtet, die sich allerdings teilweise mit den Standardrollen decken. Tabelle 3 gibt Aufschluss über die zusätzlich erstellten Rollen. Diese Rollen werden später auf die im Abschnitt Benutzergruppen beschriebenen Gruppen verteilt. Ein Punkt bei der Rollenverteilung muss noch näher beleuchtet werden. Die Zuweisung der Rollen zu den Benutzern soll nur über die zugehörigen Benutzergruppen erfolgen. Der Grund für diese Vorgehensweise liegt darin begründet, dass sich theoretisch jeder im Active Directory eingerichtete Benutzer am Wiki anmelden kann, auch wenn er noch keiner Benutzergruppe zugewiesen wurde. Um dabei auszuschließen, dass dieser Benutzer Zugriff auf Bereiche erhält, für die dies nicht gewünscht ist, wird jedem Benutzer bei der erstmaligen Anmeldung am Wiki die Rolle Guest zugewiesen. Dies geschieht durch den Parameter security/new-account-role mit ihrem Wert Guest in der Systemsteuerung des Wikis. Weitergehende Rechte erhält der Benutzer nun nur noch durch seine Gruppenzugehörigkeit. Wird ein Benutzer also keiner Gruppe zugeteilt, kann er sich zwar am Wiki anmelden, jedoch keine Inhalte des Wikis lesen geschweige denn erstellen oder verändern. Um nicht angemeldeten Besuchern den Zugang zum Wiki zu verweigern, wurde dem Standardbenutzer Anonymous die Rolle None zugewiesen. Diese Besucher sehen dann lediglich den Anmeldedialog. Seite 9

13 2.5.2 Einrichtung der Active-Directory-Anbindung Das MindTouch Deki bietet von Haus aus eine LDAP-Schnittstelle zu Active Directory, welche Authentifizierungsdienst genannt wird. Damit erübrigt sich das Anlegen von lokalen Wiki-Benutzern und -Gruppen. Außerdem ist die Pflege der Benutzer und ihrer Gruppenzugehörigkeit einfacher an zentraler Stelle zu handhaben, wofür sich das im Unternehmen verwendete Active Directory mit mehreren hundert Benutzern anbot. Für die LDAP-Schnittstelle wurden die Parameter aus Tabelle 4 festgelegt. Der in Tabelle 5 dargestellte Parameter displayname-pattern wurde aus folgendem Grund festgelegt: Eine Zusammensetzung von {givenname} {sn} und die Zuweisung dieser Kombination dem Wiki- Parameter displayname-pattern übergibt dem Objekt eines Benutzers, der sich mit seinen Domänenzugangsdaten am Wiki anmeldet, den vollständigen Namen des Benutzers. Im Wiki lassen sich dann mittels der wiki-internen Skriptsprache Dekiscript persönliche Ansprachen formulieren oder der Autor von Seiten mit seinem vollständigen Namen statt seines Benutzernamens anzeigen. Dieser Schritt war notwendig, da die Benutzernamen für die Anmeldung an der Domäne aus den Initialen der Benutzer bestehen. Die Werte wurden mittels des ADExplorers aus den Microsoft Sysinternals ermittelt. Am Beispiel der Parameter givenname und sn wurden zwei Attribute eines Benutzerobjektes gesucht, die den Vorund Zunamen des Benutzers enthalten. Im ADExplorer ist zu sehen, dass dem Attribut givenname der Vorname und dem Attribut sn der Nachname (surname) zugewiesen ist Benutzergruppen Nach Einrichtung des Authentifizierungsdienstes wurden die Benutzergruppen im Wiki angelegt. Jede Benutzergruppe ist vom Typ external (extern) und verwendet den eingerichteten Authentifizierungsdienst. Beim Anlegen der Benutzergruppen ist es notwendig, die Anmeldedaten eines autorisierten Benutzer aus dem Active Directory anzugeben, damit beim Anmelden eines Benutzers dessen Gruppenzugehörigkeit mit den hier angelegten Benutzergruppen abgeglichen werden kann. Der autorisierte Benutzer muss im Active Directory mindestens Mitglied der Gruppe Account Operators (Konten-Operatoren) sein. Dazu wurde im Active Directory ein neuer Benutzer angelegt und dieser Gruppe hinzugefügt. Ein bestehendes Administratorkonto wurde nicht benutzt, um eine klare Trennung zwischen bisherigen Benutzern und für das Wiki angelegten Benutzern zu schaffen. Das Benennungsschema für die erstellten Gruppen folgt der Logik wiki_unternehmenskürzel_rolle. Die erstellten Gruppen sind der Tabelle 6 zu entnehmen. Nach Einrichtung der Benutzergruppen im Wiki müssen die Gruppen auch im Active Directory angelegt werden. Dafür wurde zuerst eine neue Organisationseinheit namens KB (KnowledgeBase) unterhalb der Organisationseinheit choren_groups angelegt. Innerhalb dieser OU wurden dann alle Gruppen als lokale (auf die Domänenstruktur beschränkte) Verteilergruppen angelegt. Der Grund dafür: Verteilergruppen sind zwar nicht so flexibel, könnten aber bei Bedarf jederzeit in Sicherheitsgruppen umgewandelt werden. Dieser Bedarf besteht momentan nicht (und wird auch in absehbarer Zeit nicht bestehen), weshalb die Vorteile von Verteilergruppen (keine Verzögerung des Anmeldevorgangs und sicherer, da nicht mit Berechtigungen belegbar) überwiegen. Nach der Einrichtung der Gruppen wurden einige Benutzerobjekte im Active Directory diesen Gruppen zugeteilt. Sämtliche Mitarbeiter der IT-Abteilung wurden Mitglied der Gruppe wiki_admins, alle Mitarbeiter der CHOREN Biomass wurden Mitglied ihrer entsprechenden wiki_cb-gruppen und ein Testbenutzer, der für diesen Zweck angelegt wurde, wurde für den Zeitraum der Erprobungsphase nacheinander Mitglied der verschiedenen Gruppen. Der Testbenutzer wurde nach Abschluss aller Überprüfungen wieder gelöscht. Da die Mitarbeiter der CHOREN Biomass den Testbetrieb der Wissensdatenbank übernahmen, wurden zu diesem Zeitpunkt nur ihre Benutzerkonten Mitglied der wiki-gruppen. Seite 10

14 Zu beachten war bei Einrichtung der Gruppen noch, dass die LDAP-Schnittstelle nicht mit verschachtelten Gruppen (nested groups) umgehen kann. Jeder Benutzer muss im Active Directory deshalb manuell der entsprechenden Benutzergruppe aus dem Wiki zugewiesen werden. Das Zuweisen von bestehenden Benutzergruppen zu Benutzergruppen aus dem Wiki ist leider nicht möglich Einrichtung der einzelnen Wikibereiche Aufgrund der Baumstruktur, mit der ein Wiki in der Regel aufgebaut ist, ist es einfach, verschiedene Bereiche mit unterschiedlichen Zugriffsrechten einzurichten. Für die gestellte Aufgabe war es notwendig, für jedes Unternehmen einen gesonderten Bereich zu erstellen. Die Bereiche sind dabei nichts anderes als eigene Seiten, die als Titel den Namen des jeweiligen Unternehmens tragen, Zugriff nur für Mitglieder der jeweiligen Gruppen gestatten und um beliebig viele Unterseiten ergänzt werden können. Notwendig wurden außerdem eine Hilfeseite für alle Mitarbeiter, eine Hilfeseite speziell für die IT-Abteilung und ein Bereich namens Sandbox, in dem jeder Mitarbeiter die Funktionen des Wikis testen kann, ohne den inhaltlichen Bereich damit zu belasten. Die Abbildungen 3 und 4 geben Aufschluss über die Baumstruktur des Wikis und die zugewiesenen Berechtigungen. In jedem Bereich, in welchem es nicht gesondert angegeben ist, besteht für die Fachbereichsleiter und Geschäftsführer Zugriff nach der Rolle Verwalter, für alle anderen Mitarbeiter besteht Zugriff nach der Rolle Nutzer. Die einzelnen Verwalter können in Ihren Bereichen Lese- und Schreibzugriffe nach Bedarf selbst verteilen. Mitglieder der Gruppe wiki_admins und damit Inhaber der Rolle Admin haben überall Vollzugriff Verschiedene Einstellungen Verteilt über alle Bereiche des Wikis galt es noch einige weitere kleine Einstellungen vorzunehmen. In der Systemsteuerung wurde der Parameter für die maximale Dateigröße auf 32MB eingestellt. Für den Fall, dass diese Größe nicht ausreichend sein sollte, lässt sie sich hier ohne Zugriff auf die Kommandoshell 24 verändern. Der Parameter für die maximale Dateigröße von Bildern, die von ImageMagick verarbeitet werden, um beispielsweise die Vorschaubilder zu generieren, wurde auf 8MB gesetzt. Bilder über dieser Größe werden ohne Vorschaubild eingebunden. Um die benachrichtigung für abonnierte Seiten zu aktivieren, musste die Datei /etc/dekiwiki/mindtouch.deki.startup.xml um die Einträge für den lokalen SMTP- Server und die Absenderadresse ergänzt werden B15. Um zu verhindern, dass sich Benutzer ein neues Konto am Wiki erstellen und nicht ihr Domänenkonto verwenden, wurde in der Systemsteuerung die Möglichkeit zur Erstellung eines Benutzerkontos deaktiviert. Ebenfalls deaktiviert wurde die Möglichkeit zur lokalen Anmeldung am Wiki B16. Damit wird dem Benutzer zur Anmeldung nur noch die Anmeldemaske für die Domänenzugangsdaten angeboten. Diese Einstellung ist über eine Konfigurationsdatei definierbar und bietet daher für den Fall, dass die Active Directory-Anbindung ausfällt, weiterhin die Möglichkeit, dass sich der lokal eingerichtete Administrator am Wiki anmelden kann. Dem global sichtbaren Help-Link wurde eine URL aus dem Wiki zugewiesen. Standardmäßig verweist der Help-Link auf hier wurde er verändert zu Damit erreicht man die vom Prüfling erstellten Hilfeseiten. Aus dem Logo der CHOREN-Gruppe wurde mittels der Website ein Favicon generiert und in das Verzeichnis /var/www/dekiwiki kopiert. Ein Favicon ist ein kleines 16x16 Pixel großes Bild, welches im Browser in der Adressleiste vor der URL angezeigt wird. Seite 11

15 2.6 Testphase Um die korrekte Funktion des Wikis zu gewährleisten, wurden diverse Tests durchgeführt. Im Active Directory wurde ein Testbenutzer angelegt und nacheinander allen Gruppen zugewiesen, um die korrekte Funktion aller Gruppen und Rollen zu überprüfen. Desweiteren wurden die Funktion der E- mailbenachrichtigung, des Dateiuploads sowie der Indizierung von textbasierten Dateianhängen und der damit verbundenen Suchfunktion inspiziert. Es wurden diverse Seiten inklusive Dateianhängen angelegt, gelöscht, wiederhergestellt und permanent gelöscht. Den Mitarbeitern der CHOREN Biomass wurde mitgeteilt, dass sie das Wiki in Betrieb nehmen können. Ein Großteil aller Tests lief ohne Fehler ab, die aufgetretenen Probleme werden im nächsten Abschnitt näher dargestellt. Die Ergebnisse der Erprobungsphase wurden durch den Prüfling und die am Test beteiligten Mitarbeiter in Testprotokollen festgehalten und die darauf vermerkten Probleme vom Prüfling behoben. 2.7 Probleme Während der Testphase der Wissensdatenbank traten 2 Probleme auf. Das erste Problem betraf die Funktion Page Notification, mit der Benutzer Seiten abonnieren können und dadurch bei Änderungen an dieser Seite benachrichtigungen erhalten. Das zweite Problem betraf die Anmeldung mit den Domänenanmeldedaten, die bei einem Benutzer zu einer Fehlermeldung führte Page Notification Trotz der Einrichtung der Funktion Page Notification laut Anleitung aus dem Wiki der Entwickler erhielt der Prüfling während der Testphase keine benachrichtigung über Änderungen an abonnierten Seiten. Nach dem Studium verschiedener Einträge im Entwicklerforum bezüglich dieses Problems wurde die Reihenfolge und Anordnung der Konfigurationseinträge in der Konfigurationsdatei mehrfach verändert und das Wiki anschließend neu gestartet. Eine Veränderung ergab sich jedoch nicht. Die Logdatei des Wikis zeigte eine Exception (Ausnahme) in der Ausführung des versands durch die API des Wikis B17. Durch weitere Recherche im Forum der Entwickler wurde nun systematisch jeder dort angegebene Lösungsansatz durchgespielt, ohne dass sich eine Veränderung der Situation ergab. Auch gab es im Forum keine Hinweise auf die im Log 25 aufgetretene Fehlermeldung. Letztendlich gab ein Hinweis auf die Version des verwendeten Mono- Frameworks den Ausschlag. Einer der Entwickler gab den Hinweis, dass für die Nutzung der Funktion Page Notification Mono in Version von mindestens nötig ist. Mittels des Befehls mono -- version war zu sehen, dass auf dem Server nur Mono Version installiert war. Für das verwendete Debian Etch 4 war Mono jedoch in keiner höheren Version verfügbar. Abhilfe schaffte hier letztlich die Verwendung der Debian Backport Repositories 26. Nach Einbindung des entsprechenden Repositories, dem Update von Mono auf Version und dem Neustart des Wikis wurde die korrekte Funktion der Page Notification überprüft und festgestellt B Anmeldung mit Domänenanmeldedaten Bei einem Benutzer kam es bei dem Versuch der Anmeldung am Wiki mit den Domänenanmeldedaten zu der Fehlermeldung, dass der Benutzername nicht existieren würde. Im Logfile trat ein LDAP-Fehler auf, der sich vom Prüfling nicht genauer eingrenzen ließ. Mittels des Microsoft-Werkzeugs dsquery 27 wurde auf dem Domänencontroller eine Überprüfung des entsprechenden Benutzerobjektes vorgenommen, welche jedoch nicht zum Ergebnis führte B19. Mit dem Werkzeug ADExplorer 28 wurde ebenfalls keine Auffälligkeit bemerkt. Der Prüfling erstellte deshalb im Forum der Entwickler MindTouch ein Beitrag mit Bitte um Hilfe. Trotz der diversen Vorschläge konnte keine Lösung gefunden werden. Ein Vergleich des nicht-anmeldefähigen Benutzerobjekts mit einem funktionierenden Benutzerobjekt ergab letztlich, dass beim fehlerhaften Objekt eine Einschränkung auf eine bestimmte Arbeitsstation eingerichtet war. Da diese Seite 12

16 Einschränkung unnötig war, wurde sie entfernt. Der Benutzer mit diesem Benutzerkonto kann sich seit diesem Zeitpunkt fehlerfrei anmelden. 2.8 Nicht durchgeführte Teilaspekte Obwohl im Unternehmen der Internet Explorer als Standardbrowser eingerichtet ist, verwenden einige Benutzer den Mozilla Firefox. Die Syntax zur Formulierung von Ausnahmen bei den Proxyeinstellungen in beiden Browsern unterscheidet sich allerdings. Für die bisherige Nutzung wurden deshalb bei den betreffenden Benutzern die Ausnahmen von Hand korrigiert. Für die Zukunft ist vorgesehen, die abweichenden Proxyeinstellungen für den Mozilla Firefox per Gruppenrichtlinie entweder über ein Gruppenrichtlinientemplate oder ein Skript zu verteilen. Gleiches gilt für Liste von vertrauenswürdigen Seiten, die im Mozilla Firefox angegeben werden müssen, um ein funktionierendes Single Sign-On zu gewährleisten. Näheres dazu später im Text. Bei Bedarf könnte die Webserverinstallation um einen Reverse-Proxy erweitert werden, der Anfragen an die Wissensdatenbank zwischenspeichert und somit beschleunigt. Eine Möglichkeit dafür könnte Varnish sein. Der Einsatz eines solchen Proxys hängt von der Nutzung und Auslastung der Wissensdatenbank ab, welche vom Prüfling bis auf weiteres überwacht wird. 2.9 Anpassung Layout/Design MindTouch Deki bietet mehrere vorgefertigte Skins. Eine Skin ist dabei eine Designvorlage, die das Aussehen einer Webanwendung bzw. Webseite repräsentiert. Damit ist es möglich, Inhalt und Aussehen einer Webseite voneinander zu trennen und unabhängig voneinander zu pflegen. MindTouch Deki liefert beispielsweise die Skin Ace: Blue mit, welche in der Wissensdatenbank der CHOREN genutzt wird (siehe Abbildung 5). Da diese Skin den Vorstellungen der Geschäftsführung bereits entsprach, entfiel der Punkt Anpassung Layout/Design vollständig. Die damit zur Verfügung stehende Zeit wurde stattdessen für eine weitere Verbesserung der Benutzerfreundlichkeit genutzt Einrichtung Single Sign-On Um den Mitarbeitern das zweifache Anmelden zu ersparen, wurde ein Single Sign-On-Mechanismus implementiert. Möchte ein Mitarbeiter auf das Wiki zugreifen, muss er sich zuerst an einem PC an der Domäne anmelden und anschließend mit den gleichen Zugangsdaten am Wiki authentifizieren. Um diese Prozedur abzukürzen, bietet sich ein Mechanismus an, mit dem die Anmeldung am PC für die Anmeldung am Wiki genutzt wird. Dieser Mechanismus wird Single Sign-On genannt und meint die einmalige Anmeldung an einem System und Nutzung mehrerer unabhängiger Dienste mit dieser Anmeldung. Um diesen Dienst zu nutzen, benötigt der Linuxserver, der das Wiki bereitstellt, die Anwendung Winbind 29 und ein Apache-Modul. Diese wurden über die Linux-Shell installiert B20. Im Anschluss daran wurde das installierte Apache-Modul mit dem Befehl a2enmod auth_ntlm_winbind aktiviert. Dem Apache-Benutzer www-data wurde die Verbindung zu Winbind durch Aufnahme in die von Winbind erstellte Benutzergruppe gestattet B21. Winbind installiert zusätzlich das Paket samba-common. Dieser Sambadienst 30 muss nicht gestartet werden, allerdings wird dessen Konfigurationsdatei genutzt. Zur Konfiguration von Winbind wurden einige Angaben zur Domäne in diese Datei eingetragen. Nach Abschluss dieser Konfigurationsarbeiten wurde der Linuxserver mit der Domäne verbunden und Winbind neugestartet B22. Mit dem Befehl wbinfo -u wurde überprüft, ob der Linuxserver Benutzernamen aus dem Active Directory lesen kann. Seite 13

17 Im Wiki selbst wurde der Anmeldedienst, der die Verbindung zum Active Directory herstellt, geändert. Die in Tabelle 7 aufgeführten Parameter wurden ergänzt bzw. geändert. Da bei der Nutzung von Winbind die Bindung an das Active Directory durch einen bestimmten Benutzer erfolgen muss, wurden die Anmeldedaten des Benutzers fest eingetragen. Es wurde der gleiche Benutzer eingetragen, mit dem die Erstellung der Gruppen autorisiert wurde. In der Systemsteuerung wurden 2 neue Parameter nachgetragen, welche die gesicherte Anmeldung ermöglichen und die Identifikationsnummer des Authentifizierungsdienstes angegeben. Nach einem Neustart des Wikis benötigt der Apache-Webserver noch eine Datei namens.htaccess im Stammverzeichnis der Webanwendung. In diese wurden Angaben zur Authentifizierungsmethode über Winbind eingetragen B23. Der Webserver musste danach zum Neuladen der Konfigurationsdateien veranlasst werden B24. Ab diesem Zeitpunkt ist das Wiki für einen an und in der Domäne angemeldeten Benutzer ohne Angabe seiner Zugangsdaten erreichbar. Überprüft wurde dies mit dem Internet Explorer. Bei Nutzung des Mozilla Firefox muss eventuell über die Gruppenrichtlinien der Konfigurationsschlüssel network.automatic-ntlm-auth.trusted-uris mit dem Wert verteilt werden. Für den Fall, dass dieser Schlüssel nicht gesetzt ist, muss sich der Mitarbeiter wie bisher mit seinen Zugangsdaten am Wiki anmelden. 3 Übergabe und Inbetriebnahme 3.1 Übergabe an die Mitarbeiter der IT-Abteilung Nach Abschluss aller Arbeiten und der Testphase wurde die Wissensdatenbank an die Mitarbeiter der IT-Abteilung übergeben. Dafür wurde eine Einweisung in die Funktionsweise des Wikis und die Struktur des Webservers sowie der Wiki-Verzeichnisstruktur gegeben. Sämtliche Benutzernamen und Passwörter für den Zugang sowohl zum Linuxserver als auch zu den Anwendungen wurden übergeben und hinterlegt. Desweiteren wurde auf die Hilfetexte im Wiki hingewiesen, in denen die Einrichtung und Konfiguration des Wikis sowie des Servers dargelegt ist. Diese Dokumentation wurde außerdem in Schriftform übergeben. 3.2 Übergabe an die Geschäftsführung und Inbetriebnahme Nach der Übergabe an die IT-Abteilung wurde der verantwortliche Geschäftsführer in Hamburg per über den Abschluss der Arbeiten unterrichtet. Mit seiner Antwort wurde eine Übergabe per Videokonferenzanlage vereinbart. Während dieser Videokonferenz wurde dem Geschäftsführer die Wissensdatenbank noch einmal vorgestellt und vorgeführt. Dabei wurden alle Funktionen des Wikis erläutert und Fragen des Geschäftsführers beantwortet. Weiterhin wurde auf die Dokumentation im Wiki hingewiesen und die Zusendung der Dokumentation (sowohl die Kundendokumentation als auch die Projektdokumentation) vereinbart. Nach Klärung aller Fragen wurde vom Geschäftsführer festgelegt, welche Personen als Verwalter der einzelnen Unternehmensbereiche im Wiki vorgesehen sind. Alle anderen Mitarbeiter sind den jeweiligen Nutzer-Gruppen zugewiesen worden. Nach Beendigung der Videokonferenz wurden vom Prüfling alle Mitarbeiter den entsprechenden Benutzergruppen im Active Directory zugewiesen und der Geschäftsführer über den Abschluss dieser Arbeit unterrichtet. Die Information an die Mitarbeiter über das Vorhandensein der Wissensdatenbank wurde vom Geschäftsführer vorgenommen. Seite 14

18 4 Fazit Basierend auf meinen bisherigen Erfahrungen und der Ausbildung sowohl mit Computern im Allgemeinen als auch mit Linux und Netzwerken im Besonderen ist die Installation und Konfiguration eines Linuxservers vergleichsweise zügig durchführbar gewesen. Beim Auftreten von Problemen oder mir unbekannten Situationen waren mir die Recherchemöglichkeiten im Internet stets eine Hilfe. Besonders hervorzuheben ist dabei das Entwicklerforum von MindTouch Inc. sowie die Dokumentationen der Entwickler des Betriebssystems und der Serverdienste. Eine besondere Hilfe waren stets auch die Kollegen der IT-Abteilung und der verantwortliche Geschäftsführer bei CHOREN, die mir durch das in mich gesetzte Vertrauen eine zügige Arbeitsweise ohne zeitaufwändige Besprechungen und Autorisationsprobleme ermöglichte. Schwierigkeiten traten entgegen meiner Erwartungen kaum auf. Die Probleme, mit denen ich konfrontiert wurde, ließen sich durch gezielte Recherchearbeit lösen und trugen insgesamt zum besseren Verständnis verschiedener Zusammenhänge (besonders im Active Directory) bei. Seite 15

19 5 Glossar 1 webbasiert: per Webbrowser (Microsoft Internet Explorer, Mozilla Firefox etc.) nutzbare Anwendung, welche auf einem Webserver ausgeführt wird 2 Indizierung: Aufnahme in einen Index (hier: Suchindex), mit Hilfe dessen sich Informationen schneller auffinden lassen 3 Active Directory: Verzeichnisdienst von Microsoft, mit Hilfe dessen ein Netzwerk entsprechend der realen Struktur eines Unternehmens gegliedert werden kann 4 Domäne: hierarchischer Namensraum, der zur Identifizierung von Arbeitsstationen in einem Netzwerk dient 5 Domänencontroller: Server, welche für Pflege, Vorhaltung und Änderungen am Active-Directory- Verzeichnisdienst verantwortlich ist 6 HP ProLiant DL380 G5 (Serverhardware von Hewlett-Packard): 1x Intel Xeon E5335 (QuadCore 6A ) 2GHz, 12GB RAM, 8 SAS 6B -HDDs (4x146GB, 4x73GB) 6A QuadCore: Prozessor mit 4 physischen Prozessorkernen 6B SAS (Serial Attached SCSI): serieller Nachfolger von SCSI (Small Computer System Interface), schnelle Anbindung von Festplatten und anderen Laufwerken 7 VMware Infrastructure: Softwarelösung zum gleichzeitigen Betrieb mehrerer virtualisierter Computer auf einem physischen Computer 8 WYSIWYG (What You See Is What You Get): Anzeige des Dokuments während der Bearbeitung, wie es bei der Ausgabe auf einem anderen Gerät oder in der endgültigen Fassung aussieht ( 9 Versionierung: alte Bearbeitungsstände von Artikeln/Seiten und Dateien werden nicht gelöscht oder überschrieben, sondern gespeichert und können über einen Versionsvergleich mit allen anderen Versionen verglichen werden. Der Vorteil daran ist, dass alte Versionen ohne Probleme wiederhergestellt werden können. Selbst absichtliches Zerstören von Artikeln oder Dateien ist nicht ohne weiteres möglich, da ein Stand von vor der Zerstörung problemlos restaurierbar ist. Obwohl in einem Enterprise-Wiki Vandalismus praktisch keine Rolle spielen dürfte, verhindert diese Versionierung dennoch wirkungsvoll Datenverluste durch Fehlbedienung. 10 CMS (Content Management System): Anwendungssoftware, welche die gemeinschaftliche Erstellung und Bearbeitung des Inhalts von Dokumenten ermöglicht und organisiert, meist webbasiert 11 ACL (Access Control List): Zugriffssteuerungsliste, welche festlegt, welcher Benutzer welche Dienste und Dateien nutzen darf 12 Benutzerrolle: Sammlung von Rechten, die mehreren Benutzern und Gruppen zugewiesen werden kann 13 Enterprise: Unternehmen, Betriebstyp in einer Marktwirtschaft Seite 16

20 14 Systemsteuerung: zentrale Seiten im Wiki, die nur Administratoren zugänglich sind und in denen Einstellungen am System vorgenommen werden 15.Net Framework: Softwareplattform bestehend aus Laufzeit- und Entwicklungsumgebung für Anwendungssoftware von Microsoft für Windows-Betriebssysteme 16 Perl: freie und plattformunabhängige Skriptsprache 17 PHP (PHP: Hypertext Preprocessor): Open-Source-Skriptsprache, findet hauptsächlich bei dynamischen Webanwendungen Verwendung (Name ist ein rekursives Akronym) 18 Dedizierung: Widmung einer Ressource ausschließlich einem bestimmten Zweck 19 NAT (Network Address Translation): Sammelbegriff für verschiedene Verfahren in Netzwerken, um IP-Adressinformationen 19A in Paketen durch andere zu ersetzen 19A IP-Adresse (Internet-Protokoll-Adresse): Adresse einer Netzwerkstation bei Verwendung des Internet-Protokolls (IP) 20 Proxy-ARP: vergleichbar mit NAT, bezieht sich allerdings auf MAC-Adressen 20A statt auf IP-Adressen 20A MAC-Adresse (Media-Access-Control-Adresse): Hardware-Adresse eines Netzwerkadapters 21 Proxy: Vermittler zwischen zwei Rechnernetzen, ermöglicht Verbindung zueinander inkompatibler Netze, Filterung von Daten, Zwischenspeicherung und Anonymisierung 22 A-Record: Eintrag, mit dem einem DNS-Namen eine IPv4-Adresse zugeordnet wird 23 Satellitensystem: Postfix agiert als Relayserver, der keine s empfängt, sondern nur ausgehende s an einen anderen server (hier: den MS-Exchange-Server des Unternehmens) zum Versand weiterleitet. 24 Kommandozeile, Linux-Shell, Kommandoshell: Befehlszeile eines Betriebssystems (zum Beispiel Linux), auf der ohne graphische Oberfläche Befehle eingegeben und ausgeführt werden 25 Logfile: Datei, in der Meldungen über Fehler und Ereignisse einer Anwendung oder eines Betriebssystems abgelegt werden 26 Debian Backport Repositories: Paketquellen, in denen angepasste Pakete aus neueren Debian- Versionen für ältere Debian-Versionen angeboten werden 27 dsquery: Werkzeug von Microsoft, um über die Kommandozeile das Active Directory nach Objekten zu durchsuchen 28 ADExplorer, Active Directory Explorer: Werkzeug von Microsoft, mit dessen Hilfe man alle Attribute aller Objekte eines Active Directory betrachten kann 29 Winbind: Anwendung, Bestandteil der Samba-Suite, notwendig für die Einrichtung einer einheitlichen Anmeldung 30 Samba: freie Software, die das SMB-Protokoll für Netzwerkdienste unter Linux nutzbar macht. Wird zum Beispiel verwendet für Datei- und Druckerdienste. Seite 17