IPA-Projekt vom 10. April 2015

Migration eines Source-Servers

Migration eines Source-Servers

Matthias Engels

Version: 2.0.1

Speicherdatum:

10. April 2015

Druckdatum:

10. April 2015

Impressum

Tabelle 1

Rechte ©2015 Alle Rechte vorbehalten, Matthias Engels

Design Matthias Engels, unter Benutzung von Microsoft Word 2010

Vorlagen

Bilder Bilder und Fotos von dritten werden in einem Bilderverzeichnis

gelistet, das Urheberecht liegt beim Autor der Bilder. Von mir selbst Erstellte Bilder dürfen nur mit meiner Erlaubnis weiterverwendet werden

Grafiken und Tabellen Erstellt mit Microsoft Word, Excel und Visio 2010

Firma Rafisa Informatik GmbH

Bernstrasse 88

8953 Dietikon ZH

Autor Engels, Matthias

Lernender Informatik (Systemtechnik)

Fachvorgesetzter Schärer Thomas

Ausbildner Informatik

Experte Zuck, Daniel

SIX Group Services AG

Hardturmstrasse 201

8001 Zürich

Zweitexperte Berchtold, Thomas

ETH-Zürich

D-BAUG

HIL E 24.3

Stefani-Franscini-Platz 5

8093 Zürich

Versionsprotokoll

Tabelle 2

Version Datum Beschreibung

Inhaltsverzeichnis

IMPRESSUM………………………………………………………………………………………………………………………………………… 2 VERSIONSPROTOKOLL…………………………………………………………………………………………………………………………….. 3

TEIL 1 - UMFELD UND ABLAUF ………………………………………………………………………………………………………….. 7

1. AUSGANGSLAGE…………………………………………………………………………………………………………………………… 7 2. DETAILLIERTE AUFGABENSTELLUNG…………………………………………………………………………………………………….. 7 3.PROJEKTORGANISATION…………………………………………………………………………………………………………………….. 11

3.1 Organigramm ……………………………………………………………………………………………………………………….. 11

3.2 Speicherorganisation ……………………………………………………………………………………………………………… 11

3.3 Speicherorte………………………………………………………………………………………………………………………….. 11

4.VORKENNTNISSE……………………………………………………………………………………………………………………………… 11 5.VORARBEITEN………………………………………………………………………………………………………………………………… 12 6.VERWENDETE FIRMENSTANDARDS…………………………………………………………………………………………………………. 12 7.PROJEKTMETHODE…………………………………………………………………………………………………………………………… 12 8.ZEITPLAN………………………………………………………………………………………………………………………………………. 13 9.ARBEITSPROTOKOLL………………………………………………………………………………………………………………………….. 15

TEIL 2 – PROJEKT ………………………………………………………………………………………………………………………….. 26

10.MANAGEMENT SUMMARY………………………………………………………………………………………………………………… 26 11.INFORMIEREN……………………………………………………………………………………………………………………………….. 27

11.1 Ausgangslage ……………………………………………………………………………………………………………………… 27

11.2 Analyse des bestehenden Systems …………………………………………………………………………………………. 27

11.3 Anforderungen an das neue System ……………………………………………………………………………………….. 30

11.4 Zu migrierende Daten und allfällige Datenkonversionen …………………………………………………………… 32

11.5 Vorgaben für Einbindung in das Netzwerk ………………………………………………………………………………. 32

11.6 Netzwerkplan Labor …………………………………………………………………………………………………………….. 33 11.7 SOLL-Netzwerkplan………………………………………………………………………………………………………………. 34

11.8 IST-Netzwerkplan…………………………………………………………………………………………………………………. 35

11.9 Zusammenfassung Soll/IST-Zustand Netzwerk ………………………………………………………………………… 36

1. PLANEN UND ENTSCHEIDEN ………………………………………………………………………………………………………………. 37
   1. Angewendete RAID-Level ……………………………………………………………………………………………………… 37
   2. Partitionierung und Datenablage …………………………………………………………………………………………… 38
   3. Benötigte Benutzer und Gruppen …………………………………………………………………………………………… 39
   4. Zu Installierende Software (Client/Server) ……………………………………………………………………………….. 40
   5. Migrationsablauf und Fallback-Szenario …………………………………………………………………………………. 41
   6. Migrationszeitpunkt, Point of no-Return …………………………………………………………………………………. 42
   7. Backupkonzept ……………………………………………………………………………………………………………………. 43
   8. SCM-Manager Start/Stop Script planen ………………………………………………………………………………….. 44
   9. Abnahmedatum und Freigabe ……………………………………………………………………………………………….. 44
2. VORKONFIGURATION, GRUNDINSTALLATION UND NETZWERKKONFIGURATION ……………………………………………………. 45
   1. System Vorbereiten ……………………………………………………………………………………………………………… 45
   2. RAID einrichten ……………………………………………………………………………………………………………………. 46
   3. Grundinstallation LAMP, Partitionierung, Updates und Datenablage anpassen …………………………… 55
   4. Benutzer und Gruppen erstellen …………………………………………………………………………………………….. 60
   5. Netzwerkkonfiguration anpassen …………………………………………………………………………………………… 61
3. SOFTWAREINSTALLATION UND KONFIGURATION ……………………………………………………………………………………….. 62
   1. Installation JRE/JDK ……………………………………………………………………………………………………………… 62
   2. Installation und Konfiguration Webmin ………………………………………………………………………………….. 63
   3. Installation Mercurial und SCM-Manager ……………………………………………………………………………….. 64
   4. Installation vsftpd ………………………………………………………………………………………………………………… 66
   5. Einrichten der Datenablage für vsftpd ……………………………………………………………………………………. 67
   6. Implementierung des Zugriffskonzepts …………………………………………………………………………………… 67
4. MIGRATION …………………………………………………………………………………………………………………………………. 69
   1. Vorbereiten der Migration …………………………………………………………………………………………………….. 69
   2. Migration der SCM-Manager Konfiguration ……………………………………………………………………………. 70
   3. Migration der Mercurial-Repositories …………………………………………………………………………………….. 71
   4. Prüfen der Migration ……………………………………………………………………………………………………………. 72
   5. Informieren der Benutzer ……………………………………………………………………………………………………… 72
   6. Anpassung der Clients ………………………………………………………………………………………………………….. 73
5. SERVER-SCRIPTS ……………………………………………………………………………………………………………………………. 73
   1. SCM-Manager Start/Stop Script …………………………………………………………………………………………….. 73
   2. Backup Script ………………………………………………………………………………………………………………………. 76
6. SYSTEMTEST…………………………………………………………………………………………………………………………………. 81
   1. Testobjekte …………………………………………………………………………………………………………………………. 81
   2. Testumgebung …………………………………………………………………………………………………………………….. 81
   3. Testfälle ……………………………………………………………………………………………………………………………… 82
   4. Statistik der Testfälle ……………………………………………………………………………………………………………. 88
   5. Auswertung fehlgeschlagene Tests ………………………………………………………………………………………… 88
7. AUSWERTEN ………………………………………………………………………………………………………………………………… 89
   1. Massnahmen und Konsequenzen bei fehlgeschlagenen Tests ……………………………………………………. 89
   2. Abnahmeprotokoll ……………………………………………………………………………………………………………….. 90
   3. Benutzerinformation über erfolgte Abnahme und anstehende Übergabe ……………………………………. 92
8. REFLEXION …………………………………………………………………………………………………………………………………… 93 20 VERZEICHNISSE ………………………………………………………………………………………………………………………………. 94

1. Bildverzeichnis …………………………………………………………………………………………………………………….. 94
2. Tabellenverzeichnis ……………………………………………………………………………………………………………… 94
3. Quellenverzeichnis ……………………………………………………………………………………………………………….. 94
4. Literaturverzeichnis ……………………………………………………………………………………………………………… 94

1. GLOSSAR …………………………………………………………………………………………………………………………………….. 96
   1. Abkürzungen ……………………………………………………………………………………………………………………….. 96 21.2 Begriffe ………………………………………………………………………………………………………………………………. 96

ANHANG 1 - BENUTZERHANDBÜCHER …………………………………………………………………………………………… 100

1. BENUTZERANLEITUNG SCM-SERVER ………………………………………………………………………………………………….. 100
   1. Anmelden am SCM-Manager ………………………………………………………………………………………………. 100
   2. Repositories Erstellen …………………………………………………………………………………………………………. 101
   3. Hinzufügen von Berechtigungen auf Repositories …………………………………………………………………… 101
   4. Löschen von Repositories …………………………………………………………………………………………………….. 102
2. ANLEITUNG FÜR WIEDERHERSTELLUNG VON DATEIEN ………………………………………………………………………………. 103
   1. Anmelden und zum Backupverzeichnis navigieren ………………………………………………………………….. 103
   2. Backupinhalt auflisten ………………………………………………………………………………………………………… 103
   3. Hauptbackup entpacken ……………………………………………………………………………………………………… 103 23.4 Unterbackups entpacken …………………………………………………………………………………………………….. 104

23.5 Backup aufräumen …………………………………………………………………………………………………………….. 104

ANHANG 2 – SCRIPTS ………………………………………………………………………………………………………………….. 106

1. SCM-MANAGER START/STOP SCRIPT…………………………………………………………………………………………………. 106 25. BACKUP SCRIPT ……………………………………………………………………………………………………………………………. 109

Teil 1 Umfeld und Ablauf

Teil 1 - Umfeld und Ablauf

1.Ausgangslage

Unsere Applikationsentwickler arbeiten projektbezogen mit einem Source-Control Server. Die Hardware dieses Servers ist mittlerweile schon etwas „in die Jahre gekommen“ und funktioniert nicht mehr zuverlässig.

Ein neuer Source-Control Server wird benötigt, um einen zuverlässigen Betrieb sicherzustellen.

Durch den Zugang neuer Hardware wird es nun möglich, eine Migration vorzunehmen.

Gleichzeitig ist auch ein neues Backup-Konzept nötig.

2.Detaillierte Aufgabenstellung

Eine Migration eines produktiven Servers verlangt, dass umfassende Abklärungen gemacht werden. Zuerst muss das aktuelle System analysiert werden, die neuen Bedürfnisse müssen geklärt sein. Die zu migrierenden Daten, sowie allfällige Datenkonversionen müssen vollständig bekannt sein. Neben einem klar definierten Migrationsprozess ist auch ein „Point of no Return“ festgelegt. Es gibt einen „Plan B“, falls ein Fallback nötig ist.

Für die Installation und Konfiguration des neuen Servers sind einige Arbeiten nötig. Neben den standardmässig angelegten Partitionen sollen auch Programme und Daten getrennt werden. Die Aufteilung der Partitionen soll begründet werden.

Um die Ausfallsicherheit und die Performance möglichst optimal zu halten, soll die Partitionierung auch im physikalischen Aufbau des Servers widerspiegelt werden. Die Entscheidung welche RAIDLevel zum Einsatz kommen, muss begründet werden.

Die Grundinstallation des Servers wird im Test-Labor vorgenommen. Nach dem Abschluss erfolgen der Einbau im Rack und die Einbindung ins Rafisa-Netzwerk. Der Server wird kein Mitglied der ADDomäne. Die Authentifikation wird Lokal durch das Ubuntu Server 14.04 Betriebssystem durchgeführt. Während der Installation ist das Internet notwendig. Es werden nur die StandardUbuntu-Server 14.04 Sicherheitsrichtlinien verwendet.

Auf dem Server muss für den ortsunabhängigen Datenaustausch ein FTP-Server mit einem zugehörigen Ablageverzeichnis installiert und konfiguriert werden. Das Verzeichnis wird durch den Kandidaten bestimmt. Als FTP-Server muss vsftpd installiert werden. Der Zugriff auf den FTP-Server muss über die Benutzerberechtigung geregelt werden. Anonymus ist nicht zulässig.

Die folgenden Angaben müssen beim Server-Verantwortlichen der Rafisa eingeholt werden:

• IP-Adressierungen
• Servernamen

Der Zugriff für die Installation und die Migration erfolgen hauptsächlich über Remote Desktop

Connection (z.B. xRDP)

Es müssen die benötigten Software-Pakete installiert und konfiguriert werden:

Installation des Betriebssystems, Ubuntu 14.04 Server (als LAMP Version)

Alle, bei der Installation eingerichtete Ubuntu-Server 14.04 Dienste werden so belassen wie die installiert wurden. Nach Fertigstellung der Installation sind die aktuellen Updates zu installieren, danach sind Sicherheits-Updates nur mit Supervision des Administrators durchzuführen, keine automatischen Updates.

Installation und Konfiguration von Webmin. Es ist nach den Standard Zugriffsbeschränkungen einzurichten, d.h. Port 10000 offen für das Internet.

Installation der Source-Control Software (Mercurial) Latest Stable.

Installation des SCM-Manager (Latest Stable) inklusive Start- und Stop-Skripte, welche vom Kandidaten erstellt werden müssen. CRON-Skripte für die Daten-Sicherung werden mittels Webmin eingerichtet.

Ein Start-, Herunterfahren-Skript für den SCM-Manager ist neu zu erstellen und nach folgenden Vorgaben zu programmieren:

Das Skript muss mittels ‚/bin/sh‘ startbar sein. Folgende Kriterien muss das Skript erfüllen:

• Starten: Init-Levels 2 3 4 und 5
• Stoppen: Init-Levels 0 1 und 6

Der SCM-Manager muss vom Benutzer ‚scmmanager‘ gestartet werden.

Die Start-Einträge müssen in der Datei ‚/home/scmmanager/scm-server/var/log/scmmanager.log‘ eingetragen werden.

Die Standard Linux-Initskript Startparameter ‚start, stop, status und restart‘, müssen implementiert werden.

• Beim Parameter ‚start‘ ist der SCM-Manager zu starten.
• Beim Parameter ‚stop‘ ist der SCM-Manager zu stoppen.
• Beim Parameter ‚status‘ soll angezeigt werden ob der SCM-Manager läuft oder nicht.
• Beim Parameter ‚restart‘ soll der SCM-Manager gestoppt werden, falls der gerade läuft um grad wieder gestartet zu werden.

Die Benutzer müssen analog der bestehenden Umgebung angelegt und entsprechend berechtigt werden. Dazu sind drei Linux-Benutzer anzulegen die der Gruppe ‚sudo‘ (Admins) angehören.

Es ist ein Linux-Benutzer und Linux-Gruppe „scmmanager“ einzurichten.

Die Mercurial-Benutzer werden vom bestehenden Server migriert/übernommen.

Der Benutzer ‚scmmanager‘ gehört keiner Gruppe an. Dieser Benutzer kann sich nicht anmelden und hat ‚/bin/bash‘ als Konsole.

Um die Daten zuverlässig zu sichern, muss zuerst eine Backup-Strategie festgelegt werden. Dann erfolgt die Umsetzung der Strategie durch die Implementierung eines Backup-Skripts, welches vom Kandidaten neu zu erstellen ist. Die gesicherten Dateien sollen die Berechtigungen beibehalten und das TAR-Archiv soll komprimiert sein.

Folgende Verzeichnisse sind in einem einzelnen TAR-Archiv zu sichern:

• „/home“
• „/etc“
• „/srv/mercurial“
• „/srv/mysql“
• „/srv/www“

Alle TAR-Archive die älter als 15 Tage sind, sind zu löschen.

Ist die Sicherung abgeschlossen, soll der Server herunterfahren.

Die Backup-Strategie gilt für den Server und nur Daten und das ‚/etc‘ Verzeichnis werden gesichert, keine anderen System-Dateien, keine Programme.

Das Skript soll um 18:00, montags, mittwochs und freitags gestartet werden. Es muss in /bin/sh vorliegen.

Für die Migration braucht es eine gute Kommunikation mit den betroffenen Mitarbeitern. Ein verbindlicher Migrationszeitpunkt ist mit den mit den produktiven Benutzern zu vereinbaren.

Migration der bestehenden Repositories auf den neuen Server:

Die Source-Control-Benutzer und Source-Control-Daten werden vom alten System übernommen. Die Daten müssen auf den neuen Server kopiert werden. Zuletzt müssen die Berechtigungen angepasst werden. Die Berechtigungen müssen analog dem alten System sein. Wie genau das Kopieren vonstattengehen soll, darf der Kandidat bestimmen.

Es wird erwartet, dass nach der Fertigstellung der Migration und der nötigen Zusatzaufgaben folgende Punkte getestet werden:

• Server im Rafisa Netzwerk eingebunden, Internetzugriff möglich.
• Das Backup-Konzept kann vollumfänglich umgesetzt werden.
• das Backup script funktioniert fehlerfrei
• Die Repositories können von den Clients angelegt werden.
• Die Berechtigungen sind analog dem alten System wirksam
• Die Migration war erfolgreich

Die Rahmenbedingungen für die Tests sind folgendermassen gesetzt:

1. Vorbedingungen (Testaufbau, genauer Sachverhalt, usw.)
2. Erwartetes Ergebnis
3. Eingetroffenes Ergebnis
4. Massnahmen und Konsequenzen

Es sind noch Dokumentationen zu erstellen, welche folgende zwei Gebiete abdecken:  Erstellen einer Dokumentation zur Benutzung des Source-Control Servers  Erstellen einer Dokumentation für die Wiederherstellung von Dateien.

Zielgruppe für die Dokumentationen sind Applikationsentwicklungs-Fachleute

Das migrierte System muss durch den zuständigen Ausbildungsleiter (Auftraggeber) abgenommen werden. Dazu muss ein Abnahmeprotokoll erstellt und unterzeichnet werden.

Anschliessend wird das System dem produktiven Betrieb übergeben.

3. Projektorganisation

3.1 Organigramm

Abbildung 1

3.2 Speicherorganisation

Tabelle 3

X.n.n.

Das Dokument wird auf dem Dateiserver der Rafisa auf einem Laufwerk auf das nur ich Zugriff habe gespeichert, als Backup dient ein USB-Stick und Dropbox.

4. Vorkenntnisse

• Mitarbeit bei einer früheren Migration des Source Control Servers
• Linux-Server: Kenntnisse in der Administration des Servers
• Source-Control: Kenntnisse in der Administration
• Webmin Kenntnisse (Linux Administration)

5. Vorarbeiten

• Installation eines Linux-Servers um die Kompatibilität zu testen
• Einrichten der Netzwerkverbindung
• Source Control Software
• Webmin (Admin-Tool)

6. Verwendete Firmenstandards

• IP-Adressierung
• Servernamen

7. Projektmethode

Ich habe mich für die Projektmethode IPERKA entschieden, weil ich mit ihr schon einige Erfahrungen gemacht habe und sie für dieses Projekt sehr gut geeignet ist. Sie ermöglicht eine einfache Strukturierung des Projektablaufs

IPA-Projekt vom 10. April 2015

Migration eines Source-Servers

8. Zeitplan

Tabelle 4

IPA-Projekt vom 10. April 2015

Migration eines Source-Servers

Tabelle 5

Legende:

Druckdatum: 10. April 2015 Matthias Engels Seite 14 von 109

9. Arbeitsprotokoll

Tabelle 6

Tag 1

Datum Di 24. März 2015

Arbeitszeit 09:00 – 12:00 Uhr und 12:45 – 17:00 Uhr

Ziele Planen des RAID-Verbundes, der Partitionierung und Datenablage, des

Migrationsprozesses, des Fallback-szenarios, des Backupkonzeps des

Point of no Return und des SCM-Server start/stop Scripts Arbeiten Die folgenden Arbeiten wurden ausgeführt:  RAID-Verbund planen

• Partitionierung und Datenablage planen
• Migrationsprozess planen
• Fallback-szenario planen
• Backupkonzept planen
• SCM-Server Start/Stop Script planen
• Point of no Return planen

Der Zeitplan wurde ergänzt und überarbeitet.

Probleme Es gab ein Problem bei einer Grafik aus dem Internet, ich war mir nicht sicher ob ich sie verwenden durfte, weil kein Copyright angegeben wurde.

Hilfestellungen Ein Arbeitskollege sagte mir, dass ich die Grafik verwenden kann, aber einen Verweis auf den Autor machen muss.

Ausstehende Vereinbaren des Migrationszeitpunktes und des Point of no Return mit

Arbeiten den Benutzern, Festlegen eines Datums für Abnahme und Freigabe des Systems.

Fazit Ich konnte fast die gesamte Planungsphase an diesem Tag machen, dies aber nur weil ich viele Daten schon im Voraus gesammelt und

Vereinbarungen getroffen habe. Als nächstes werden

Migrationszeitpunkt und Point of no Return definitiv festgelegt und die RAID-verbände eingerichtet.

7

Tag 2

Datum Mi 25. März 2015

Arbeitszeit 09:00 Uhr – 12:00 Uhr und 12:30 Uhr bis 17:00 Uhr

8

Tag 3

Datum Do 26. März 2015

Arbeitszeit 09:00 Uhr – 12:00 Uhr und 12:45 Uhr bis 17:00 Uhr

9

Tag 4

Datum Fr 27. März 2015

Arbeitszeit 09:00 – 11:55 und 13:00 Uhr – 17:00 Uhr

10

Tag 5

Datum Mo 30. März 2015

Arbeitszeit 09:00 Uhr – 11:55 Uhr und 12:40 Uhr – 17:00 Uhr

11

Tag 6

Datum Di 31. März 2015

Arbeitszeit 09:00 Uhr – 11:55 Uhr und 12:45 Uhr bis 17:00 Uhr

Tabelle 12

Tag 7

Datum Mi 1. April 2015

Arbeitszeit 09:00 Uhr – 12:00 Uhr und 12:30 Uhr – 17:00 Uhr

Ziele Start/Stop Script für SCM-Manager fertigstellen, Routinetest des Scripts. Dokumentieren des Start/Stop Scripts. Realisierung und Dokumentation des Backup-Scripts.

Arbeiten Die folgenden Arbeiten wurden ausgeführt:

• Fertigstellen des Start/Stop Scripts für SCM-Manager
• Dokumentieren des Start/Stop Scripts
• Routinetest des Scripts
• Realisierung des Backup-Scripts
• Dokumentation des Backup-Scripts

Probleme Keine besonderen Vorkommnisse

Hilfestellungen -

Ausstehende Realisierung des Backup-Scripts

Arbeiten Dokumentation des Backup-Scripts

Fazit Das Start-Stop Script konnte umgesetzt werden, damit ist einer der schwersten Teile dieser Arbeit vorbei, es konnte pünktlich abgeschlossen werden, weil ich noch vorarbeiten am gestrigen Tag gemacht habe.

Ich habe aber die Zeit welche ich für das Dokumentieren des Backup-

Scripts eingeplant habe unterschätzt. Ich muss morgen daran Weiterarbeiten. Ich muss in Zukunft mehr Zeit für solche Scripts einplanen.

13

Tag 8

Datum Do 2.

Arbeitszeit 09:00 – 12:00 Uhr und 12:45 Uhr – 16:00 Uhr

Tabelle 14

Tag 9

Datum Di 7. April 2015

Arbeitszeit 09:00 Uhr – 11:57 Uhr und 12:45 Uhr – 17:00 Uhr

Ziele Durchführen von Routinetests und Dokumentieren selbiger. Testen des

Backup Scripts und des SCM-Server Start/Stop Scripts. Testen der

Anleitung zur Datenwiederherstellung. Expertenbesuch Arbeiten Die folgenden Arbeiten wurden ausgeführt:

• Test: Einbindung in Rafisa-Netzwerk
• Routinetests
• Test: Umsetzung des Backupkonzepts
• Test: Funktion des Backup Scripts
• Test: SCM Start/Stop Script
• Test: Migration Erfolgreich
• Management Summary erstellt

Probleme Keine besonderen Vorkommnisse

Hilfestellungen

Ausstehende Test: Dateien Wiederherstellen

Arbeiten Test: FTP-Zugriff

Test: Vergleich der Berechtigungen zwischen den Systemen.

Fazit An diesem Tag konnte ich viele wichtige Tests ausführen. Am

Nachmittag habe ich gesehen, dass meine Dokumentation keine Management Summary hat, diese konnte ich nachträglich einbauen. Währen das Backup Script lief. Am Abend kam der Experte vorbei und schaute sich meine Arbeit an. Er hat mir geraten, den Kriterienkatalog zu studieren und Verbesserungen vorzunehmen und den Zeitplan ein wenig zu überarbeiten.

15

Tag 10

Datum Mi 8.

Arbeitszeit 12:00 Uhr und 12:45 Uhr – 17:00 Uhr

16

Tag 11

Datum Do 9.

Arbeitszeit 12:00 Uhr und 12:30 Uhr bis 17:00 Uhr

17

Tag 12

Datum Fr 10.

Arbeitszeit 12:00 Uhr und 12:45 – 17:00 Uhr

Teil 2

Projekt

Teil 2 – Projekt

10. Management Summary

Ziel dieses Projekts ist es, den bestehenden Source-Control-Server der Rafisa GmbH in der Abteilung

Applikationsentwicklung zu ersetzen. Die Hardware dieses Servers ist veraltet und ein zuverlässiger Betrieb ist nicht mehr möglich. Ein neuer Source-Control-Server wird benötigt, um einen zuverlässigen Betrieb sicherzustellen.

Durch den Zugang zu neuer Hardware ist es möglich, eine Migration vorzunehmen.

Das Projekt ist in verschiedene aufeinander folgende Phasen nach IPERKA aufgeteilt:

• Informieren
• Planen und Entscheiden
• Realisieren
• Kontrollieren
• Auswerten

In der Informationsphase werden die folgenden Punkte abgeklärt:

• Analyse des aktuellen Systems und klären der neuen Bedürfnisse.
• Zu migrierenden Daten und Dateikonversionen.
• Migrationsprozess und „Point of no Return“.
• Fallbackszenario wenn die Migration fehlschlägt.

In der Planungs- und Entscheidungsphase werden anhand der gesammelten Informationen und der Aufgabenstellung Konzepte und Pläne erstellt, welche in der Realisierung umgesetzt werden. Beispiele:

• RAID-Konzept
• Backupkonzept
• Migrationskonzept
• Fallback-Szenario
• Point of no Return

Nach Planung und Entscheidung geht es in die Realisierung. Die ausgearbeiteten Konzepte und Pläne werden jetzt realisiert. Die Migration wird durchgeführt. Das Backupkonzept wird Implementiert und die Skripts werden erstellt.

Die Migration wird an einem mit den Benutzern festgelegten Zeitpunkt ausgeführt. Nach der Migration werden die Berechtigungen angepasst. Beim Erreichen des „Point of no Return“ wird das bestehende System abgeschaltet.

Nach der Realisierung kommt die Kontrollphase. Das realisierte System wird in verschiedenen Tests auf Herz und Nieren geprüft. Die Ergebnisse werden in Testprotokollen gesammelt und Ausgewertet. Zusätzlich wird eine Statistik der Testfälle erstellt.

In der Auswertungsphase werden Massnahmen und Konsequenzen für fehlgeschlagene Tests unternommen. Die Abnahme mit dem Kunden wird durchgeführt und die Benutzer über die Aufnahme des Servers in die Produktive Umgebung informiert.

11. Informieren

11.1 Ausgangslage

Die Applikationsentwickler der Rafisa GmbH arbeiten projektbezogen mit einem Source Control Server, darauf werden die Softwareprojekte als Mercurial-Repositories abgelegt und verwaltet. Die Hardware dieses Servers ist währen längerer Zeit „in die Jahre gekommen“ eine Zuverlässige Funktion ist langfristig nicht mehr möglich.

Durch den Zugang zu neuer Hardware ist es möglich, eine Migration vorzunehmen.

Ich wurde beauftragt, diese Migration durchzuführen und gleichzeitig ein neues Backupkonzepts für diesen Server zu entwerfen und zu implementieren.

Die Ansprechperson bei diesem Projekt für Informationen ist Herr Jorge Windmeisser, im Verlauf dieses Projekts wird er als „Kunde“ bezeichnet.

11.2 Analyse des bestehenden Systems

Bevor der neue Server installiert ist, muss das bestehende System analysiert werden. Diese Analyse wurde mit dem Programm „Webmin“ durchgeführt und ist in die folgenden Teile gegliedert:

• Bestehende Hardware
• Bestehende Netzwerkkonfiguration
• Bestehende Benutzer und Gruppen
• Bestehende Scripts
• Bestehende Software

Beim Abschnitt „Bestehende Scripts“ sind Bash-Scripte gemeint, welche nicht vom System erstellt wurden. Diese wurden auch nicht im Detail untersucht, weil sie während diesem Projekt neu erstellt werden. Nur die Ansteuerung der Skripte im System wurde analysiert.

Bestehende Hardware

• Server Modell o IBM X3200 M3 Tower
• Arbeitsspeicher o 8GB RAM
• Prozessor o Intel Xeon X3430, 2.40 GHz, vier kerne
• Festplattenspeicher o 3 TB
• Partitionierung o / (root) o /srv (programme) o /backup o /run (swap)
• RAID-Level o RAID 1 mit Partition /srv Bestehende Netzwerkkonfiguration
• Netzwerkschnittstelle eth0 o IP-Adresse dynamisch über DHCP

Die IP-Adresse des bestehenden Servers ist auf dem DHCP-Server reserviert

Hostname: PC0093

Bestehende Benutzer

In der nachfolgenden Tabelle werden nur Benutzer und Gruppen erwähnt welche nicht automatisch bei der Installation erstellt wurden.

Tabelle 18

• Benutzer/Gruppe Beschreibung b_deutsch Account von Benjamin Deutsch bloodhound Account für bloodhound Daemon j_windmeisser Account von Jorge Windmeisser m_engels Account von Matthias Engels p_gabathuler Account von Philipp Gabathuler scmmanager Account für SCM-Manager Daemon

Bestehende Scripts

Backup script

Auf dem bestehenden System ist ein Backup script vorhanden welches mit einem Cronjob jeweils Montag-, Mittwoch- und Freitagabends die folgenden Verzeichnisse sichert:

• /home
• /etc
• /srv/bloodhound
• /srv/mercurial
• /srv/mysql
• /srv/postgresql
• /srv/www

Diese Verzeichnisse werden zuerst einzel gesichert und dann zu einem einem Backup zusammengefasst. Alle Backupdateien welche älter als 15 Tage sind werden automatisch gelöscht. Der Server fährt nach der Ausführung des Skripts herunter.

SCM-Start/Stop Script

Ebenfalls auf dem Bestehenden Server ist ein Start/Stop script für SCM-Manager gespeichert, es ermöglicht das automatische Starten/Stoppen des SCM-Managers bei Systemstart/Herunterfahren. Das Skript kann auch manuell mit dem Befehlen „Service scmmanager (start/stop/restart/status)“ bedient werden, dabei wird SCM-Manager jeweils gestartet, gestoppt, neu gestartet oder der Status wird angezeigt.

Bestehende Software

Um zu Wissen welche Software auf dem neuen System Installiert werden soll, wurde das bestehende System analysiert, nachfolgend eine Tabelle mit einer kurzen Beschreibung der installierten Softwarepakete:

Tabelle 19

• Softwarepaket Beschreibung Ubuntu Linux 14.04 Linux Betriebssystem, Ubuntu Distribution der Version 14.04. (Landscape Canonical, 2015) Apache Webserver Open-Source Webserver der Apache Software Foundation (Apache Foundation, 2015) Apache Bloodhound Programm für Projektmanagement und Fehlerverfolgung, kann auch als Wiki verwendet werden. (Wikipedia, 2015) MySQL DB-Server Datenbankserver für MySQL Datenbanken, sehr weit verbreitet. (Oracle, 2015) Mercurial-Server Plattformunabhäniges Versionsverwaltungssystem, Open-Source. (Mercurial Community, 2015) PHP Programm für die serverseitige Verarbeitung von PHP code für Webseiten. (PHP development Team, 2015) PhpPgAdmin Programm welches eine GUI zur Verwaltung von PostgreSQL-Datenbanken über einen Webbrowser im Netzwerk zu Verfügung stellt. (The phpPgAdmin Project, 2015) Postfix Ein E-Mail Server für Linux, wird benötigt damit Benutzer im Netzwerk E-Mails senden können. (ubuntuusers.de wiki, 2015) PostgreSQL DB-Server PostgreSQL ist eine abwandlung von MySQL und wird auf diesem Server für die Speicherung von Daten aus Bloodhound verwendet (PostgreSQL, 2015) Samba Server Open-Source Server welcher z.B. gemeinsame Dateifreigaben unter Linux und Windows ermöglicht. (Samba Team, 2015) SCM-Manager Programm welches eine GUI für Mercurial zu Verfügung stellt, ermöglicht die Verwaltung von Mercurial über einen Webbrowser im Netzwerk. (Sdorra, 2015) OpenSSH-Server SSH-Server, ermöglicht sichere Dateiübertragungen und Remote-Verwaltung des Servers über das SSH-Protokoll. (the OpenBSD Project, 2015) Webmin Programm welches eine GUI für die Verwaltung des Servers über einen Webbrowser im Netzwerk zu Verfügung stellt. (Cameron, 2015)

11.3 Anforderungen an das neue System

Die Anforderungen an das neue System wurden in einem Gespräch mit dem Fachvorgesetzten erläutert. Sie sind in die folgenden Abschnitte gegliedert:

• Hardware
• Software
• Benutzer und Gruppen
• Scripts
• Benutzer und Gruppen

Hardware

Neben den Standardpartitionen müssen Programme und Daten in eigenen Partitionen getrennt werden, dies soll im Physikalischen Aufbau des Servers durch entsprechende RAID-Arrays wiederspiegelt werden. Die Partitionierung muss begründet werden. Die Festplatten sollen gespiegelt werden.

• Server Modell o HP Pro Liant DL385 G2
• Arbeitsspeicher o 3.86GB RAM
• Prozessor o Dual-Core AMD Opteron™ Processor 2216 @ 2.4 GHz, 4 Kerne
• Festplattenspeicher o 432 GB Total*

*Dies ist ein Total der verwendeten Festplatten, ohne Anwendung eines RAID, der Effektive Speicher wird durch die RAID-Arrays und die Partitionierung verringert.

Vorgaben Betriebssystem

• Alle Bei der Installation eingerichteten Dienste werden nicht verändert.
• Nach der Installation sind die aktuellsten Updates zu installieren.
• Alle weiteren Sicherheits-Updates nur unter Aufsicht eines Administrators, keine automatischen Updates.

Neben dem Linux Betriebssystem muss die folgende Software installiert und konfiguriert werden:

• Apache Web Server
• MySQL DB-Server
• Mercurial
• OpenSSH Server
• PHP
• SCM-Manager
• FTP-Server
• Webmin

Als FTP-Server muss vsftpd installiert werden und ein Verzeichnis für den unabhängigen Datenaustausch eingerichtet werden. Der Zugriff muss über die lokalen Benutzerberechtigungen geregelt werden, Anonymus ist nicht zulässig

Das Verzeichnis zum Datenaustausch muss selbst gewählt werden.

Benutzer und Gruppen

Die Benutzer müssen analog der bestehenden Umgebung angelegt und entsprechend berechtigt werden. Dazu sind drei Linux-Benutzer anzulegen die der Gruppe ‚sudo‘ (Admins) angehören.

Es ist ein Linux-Benutzer und Linux-Gruppe „scmmanager“ einzurichten.

Die Mercurial-Benutzer werden vom bestehenden Server migriert/übernommen.

Der Benutzer ‚scmmanager‘ gehört keiner Gruppe an. Dieser Benutzer kann sich nicht anmelden und hat ‚/bin/bash‘ als Konsole.

Für die Administration des Servers werden die folgenden Benutzer angelegt werden:

• m_engels
• j_windmeisser
• t_schaerer

Scripts

Backup script

Um die Daten zuverlässig zu sichern, muss zuerst eine Backup-Strategie festgelegt werden. Dann erfolgt die Umsetzung der Strategie durch die Implementierung eines Backup-Skripts, welches vom Kandidaten neu zu erstellen ist. Die gesicherten Dateien sollen die Berechtigungen beibehalten und das TAR-Archiv soll komprimiert sein.

Folgende Verzeichnisse sind in einem einzelnen TAR-Archiv zu sichern:

• „/home“
• „/etc“
• „/srv/mercurial“
• „/srv/mysql“
• „/srv/www“

Alle TAR-Archive die älter als 15 Tage sind, sind zu löschen.

Ist die Sicherung abgeschlossen, soll der Server herunterfahren.

Die Backup-Strategie gilt für den Server und nur Daten und das ‚/etc‘ Verzeichnis werden gesichert, keine anderen System-Dateien, keine Programme.

Das Skript soll um 18:00, montags, mittwochs und freitags gestartet werden. Es muss in /bin/sh vorliegen.

SCM-Start/Stop Script

Das Skript muss mittels ‚/bin/sh‘ startbar sein. Folgende Kriterien muss das Skript erfüllen: Starten: Init-Levels 2 3 4 und 5

Stoppen: Init-Levels 0 1 und 6

Der SCM-Manager muss vom Benutzer ‚scmmanager‘ gestartet werden.

Die Start-Einträge müssen in der Datei ‚/home/scmmanager/scm-server/var/log/scmmanager.log‘ eingetragen werden.

Die Standard Linux-Initskript Startparameter ‚start, stop, status und restart‘, müssen implementiert werden.

• Beim Parameter ‚start‘ ist der SCM-Manager zu starten.
• Beim Parameter ‚stop‘ ist der SCM-Manager zu stoppen.
• Beim Parameter ‚status‘ soll angezeigt werden ob der SCM-Manager läuft oder nicht.
• Beim Parameter ‚restart‘ soll der SCM-Manager gestoppt werden, falls der gerade läuft um gerad wieder gestartet zu werden.

11.4 Zu migrierende Daten und allfällige Datenkonversionen

Der Fachvorgesetzte möchte, dass die folgenden Daten auf das neue System migriert werden:  Alle Mercurial-Repositories mit bestehenden Berechtigungen

• Mercurial Benutzer
• SCM-Manager Konfigurationsdateien

Die Berechtigungen auf diesen Dateien müssen analog dem bestehenden System sein. Die Dateien werden mit OpenSSH kopiert.

Es sind keine Datenkonversionen vorgesehen.

11.5 Vorgaben für Einbindung in das Netzwerk

Folgende Vorgaben wurden für die Einbindung in das Netzwerk gestellt:

• Server wird kein Mitglied der Active-Directory Domäne
• Redundante Einbindung des Servers in das Netzwerk Netzwerkkarten und Statischen IPAdressen

Dies sind die Netzwerkkonfigurationen welche für die Netzwerkkarten verwendet werden, die IPAdressen und der Hostname wurden mir von der Netzwerkadministration der Rafisa zu Verfügung gestellt:

Schnittstelle eth0

• IP-Adresse: 192.168.3.201
• Subnetzmaske: 255.255.255.0
• Broadcast: 192.168.3.255
• Netzwerkadresse: 192.168.3.0
• DNS-Server o 192.168.3.9 (Rafisa, Primärer DNS) o 192.168.3.11 (Rafisa, Sekundärer DNS) o 8.8.8.8 (Google, Fallback DNS)
• Gateway: 192.168.3.1

Schnittstelle eth1

• IP-Adresse: 192.168.3.202
• Subnetzmaske: 255.255.255.0
• Broadcast: 192.168.3.255
• Netzwerkadresse: 192.168.3.0
• DNS-Server o 192.168.3.9 (Rafisa, Primärer DNS) o 192.168.3.11 (Rafisa, Sekundärer DNS) o 8.8.8.8 (Google, Fallback DNS)
• Gateway: 192.168.3.1

Hostname

• SCMSRV001

Der Hostname setzt sich aus dem primär genutzten Dienst, dem Typ des Netzwerkgerätes und dessen Nummer zusammen, falls später ein zweiter Source-Control Server in das Netzwerk eingebunden wird erhält dieser den Namen:“SCMSRV002“.

11.6 Netzwerkplan Labor

Der netzwerkplan unten zeigt den Server im Labornetzwerk im 2. Obergeschoss. In diesem Netzwerk wird das RAID Konfiguriert, die Grundinstallation des Servers und das Anlegen der Benutzerkonten werden ebenfalls in dieser Umgebung vorgenommen.

Der Server ist bei der Konfiguration des RAID und der Installation des Betriebssystems an einen Bildschirm sowie Tastatur und Maus angeschlossen. Nach der Installation wird die Peripherie entfernt, um unerlaubten Zugriff zu vermeiden. Die weitere Konfiguration erfolgt am Client über das Programm „PuTTY“.

Abbildung 3

Dieser und die Nachfolgenden Netzwerkpläne zeigen jeweils stark vereinfachte Netzwerke. Nicht in diesen Plänen enthalten sind die Datei- und Domänenserver und die Drucker weil sie für dieses Projekt nicht benötigt werden. Weil in jedem Stockwerk viele Clients vorhanden sind, werden nur zwei Clients angezeigt, sie stehen symbolisch für die übrigen Clients. Die Hostnamen dieser Clients sind real vorhanden.

11.7 SOLL-Netzwerkplan

Auf diesem Netzwerkplan ist der SOLL-Zustand des Netzwerkes nach dem Erfolgreichen Abschluss zu sehen. Der bestehende Server wird für kurze Zeit weiterbetrieben, aber später aus dem Netzwerk entfernt, deshalb die gestrichelte Linie. Die Backup-Festplatte des bestehenden Systems wird in das neue eingebunden und dort weiterbetrieben. Alle Server sind von Beiden Stockwerken erreichbar.

11.8 IST-Netzwerkplan

Auf diesem Netzwerkplan ist der IST-Zustand des Netzwerks zu sehen, der bestehende Server steht im dritten Obergeschoss und ist von beiden Stockwerken erreichbar.

11.9 Zusammenfassung Soll/IST-Zustand Netzwerk

Soll-Zustand

• Neues System in Rack eingebaut
• RAID-Arrays konfiguriert
• Korrekte Partitionierung des Systems
• Linux 14.04 in LAMP-Konfiguration installiert und konfiguriert o Aktuelle Updates installiert
• Server ist in Rafisa-Netzwerk eingebunden o Netzwerkkarten gemäss Informationen konfiguriert.
• Linux-Benutzer mit Admin-Rechten erstellt o Spezielle Benutzer für Start und Stopp von Programmen erstellt
• Webmin installiert und konfiguriert
• Mercurial installiert
• SCM-Manager Installiert o Mercurial-Repositories und SCM-Einstellungen migriert
• vsftpd-Server Installiert o Verzeichnis für Datenaustausch erstellt und Freigegeben
• SCM-Start/Stop Skript erstellt o Der SCM-Server kann mit dem Befehl „service scmmanager (start/stop/restart) gestartet, gestoppt und neugestartet werden.
• Backup script erstellt o Das Backupskript startet am Montag-, Mittwoch- und Freitagabend, sichert die Dateien und Einstellungen und fährt den Server herunter.

IST-Zustand

• Bestehendes System ist noch aktiv
• Netzwerkverbindung wird über DHCP mit reservierter IP-Adresse
• Keine Redundanz bei Ausfall von Netzwerkadapter
• Hostname des bestehenden Servers sagt nichts über die Funktion des Systems
• Mercurial-Server ist noch in Benutzung
• Backup-Script läuft nach Zeitplan
• SCM-Start/Stopp Script funktioniert einwandfrei

12. Planen und Entscheiden

Nach dem alle wichtigen Informationen über das bestehende System und die Vorgaben für das neue System bekannt sind, ist ein Plan für das neue System sehr wichtig, in diesem Kapitel wird gezeigt welche Techniken zum Einsatz kommen und warum diese gewählt wurden. Viele Anforderungen sind bereits vorgegeben.

12.1 Angewendete RAID-Level

Der Kunde möchte, dass die Festplatten gespiegelt sind, so dass die volle Redundanz der Daten gewährleistet ist.

Für diese Anforderung kommen zwei RAID-Level in Frage: RAID 1 und RAID 5. In der Untenstehenden Liste werden Vor- und Nachteile dieser RAID-Level augezeigt:

RAID 1

• Vorteil: Benötigt nur zwei Festplatten für ein Array und eine Festplatte als Reserve zur Funktion. Fällt eine Platte aus sind alle Daten auf der anderen Platte vorhanden und die Spiegelung erfolgt auf die Reserve.
• Nachteil: Es steht nur die Speicherkapazität von jeweils einer Platte zu Verfügung, von insgesamt drei TB gibt es nur ein TB nutzbarer Speicher

RAID 5

• Vorteil: Mehr Speicherkapazität von drei TB sind insgesamt zwei TB nutzbar. Daten werden redundant gespeichert. Bei Ausfall einer Platte werden die verlorenen Daten automatisch ersetzt.
• Nachteil: Ist langsamer bei der Wiederherstellung. Fällt bei der Wiederherstellung eine zweite Platte aus ist das gesamte RAID verloren.

Es wurde Entschieden, RAID 1 zu verwenden, es ist schneller als RAID 5 und bei einem kompletten Ausfall des RAID-Arrays kann es einfacher wiederhergestellt werden als RAID 5. Die Grafik unten zeigt den Aufbau eines RAID 1 mit zwei Festplatten:

(Thomas Krenn Wiki, 2015) Abbildung 6

Anzahl der RAID-Arrays

Um später eine Vollständige Trennung von Programmen und Benutzerdaten zu ermöglichen werden zwei RAID-Arrays erstellt, diese haben jeweils drei Festplatten, zwei in Benutzung und eine als Reserve. Bei Ausfall einer gespiegelten Platte wird automatisch der Inhalt der intakten Festplatte auf die Reserve gespiegelt, damit ist die Redundanz wiederhergestellt.

Grösse der RAID-Arrays

In einem RAID 1 ist jeweils nur eine Festplatte aktiv in Benutzung die zweite dient als Spiegel und eine dritte (sofern vorhanden) als Ersatz.

Eine Einzelne Festplatte ist 72GB gross, also stehen pro Array 72 GB zu Verfügung.

12.2 Partitionierung und Datenablage

12.2.1 Partitionierung

Auf dem Server werden Daten, Programme und Systemeinstellungen getrennt auf eigenen Partitionen gespeichert. Nachfolgend eine Partitionstabelle für die beiden RAID-Arrays.

• Festplatten: zwei RAID 1 mit 72 GB
• RAM 4GB

• Typ Grösse Dateisystem Standort Speicherstelle Mountpoint Primär 67 GB Ext4 RAID-Array 1 Anfang / Logisch 4 GB swap RAID-Array 1 Anfang swap Logisch 24GB Ext4 RAID-Array 2 Anfang /home Logisch 24GB Ext4 RAID-Array 2 Anfang /srv Logisch 24GB Ext4 RAID-Array 2 Anfang /var

Tabelle 20

12.2.2 Lokale Datenablage

Die in der Tabelle beschriebenen Partitionen beinhalten die folgenden Daten:

• / (root) o Hauptverzeichnis mit allen Dateien, Einstellungen und Programmen welche von Anfang an Installiert wurden.
• swap
  • Die swap Partition speichert Daten, welche im Arbeitsspeicher keinen Platz mehr haben weil dieser ausgelastet ist.
• /home
  • Ordner aller Benutzer welche von Hand erstellt wurden.
• /srv o Datenpartition für Dienste, welche von diesem Server bereitgestellt werden (mercurial, apache, mysql usw.)
• /var o Datenpartition für Logdateien und generell veränderlichen Daten.
• /var/transfer o Verzeichnis in der Partition „/var“ für den Datenaustausch von Linux-Benutzern über FTP, der Zugriff ist über die Benutzerberechtigung festgelegt. Anonymer Zugriff ist nicht Zulässig.
• /backup
  • Verzeichnis auf welchem die USB-Festplatte für die Backups eingehängt wird.

12.2.3 FTP-Zugriffskonzept

Wie bereits oben erwähnt muss der Zugriff FTP-Zugriff über die Benutzerberechtigung erteilt werden, dazu gibt es zwei Konzepte:

• Die Benutzer haben vollen Zugriff auf allen Teilen des Systems.
• Die Benutzer sind auf ihre eigenen Verzeichnisse beschränkt, das freigegebene Verzeichnis ist jeweils im entsprechenden Benutzerverzeichnis „eingehängt“ und nicht verknüpft. Das Verzeichnis wird beim Systemstart eingebunden.

Ich habe mich für das zweite Zugriffskonzept entschieden, weil es mehr Sicherheit bietet und es ermöglicht, nur bestimmten Benutzern Zugriff auf das Verzeichnis zu erteilen. Ausserhalb des eigenen Verzeichnisses haben Benutzer, welche über FTP verbunden sind, keine Rechte.

12.3 Benötigte Benutzer und Gruppen

Damit das System administriert werden kann braucht es Benutzer, in den Anforderungen wurden diese schon erwähnt.

12.3.1 Namenskonvention

Der Benutzername setzt sich aus dem Anfangsbuchstaben des Vornamens, gefolgt von einem _Zeichen und dem Nachnamen.

• Beispiel: m_engels für Matthias Engels

Benutzerkonten welche Dienste Starten- und Stoppen bekommen den Namen des Dienstes als Benutzernamen in Kleinbuchstaben.

• Beispiel: scmmanager, Systembenutzer zum Starten und Stoppen des scmmanager Dienstes. Benutzergruppen welche für die Zugriffskontrolle auf spezielle Dienste benötigt werden erhalten bekommen den Namen des Dienstes in Kleinbuchstaben gefolgt von einem Bindestrich – und dem Zusatz: „users“ für „Benutzer“.
• Beispiel: ftp-users“, eine Gruppe für Benutzer welche Zugriff FTP-Verzeichnisse haben.

12.3.2 Bestehende Benutzer

Die nachfolgende Aufzählung beinhaltet alle wichtigen Benutzer, sie sind schon auf dem Bestehenden System vorhanden und werden auf dem neuen System erstellt:

• m_engels
• j_windmeisser o Alle mitglied der Gruppe „sudo“ (Admin)
• scmmanager

oBenutzer ohne anmelderechte und „bin/bash“ als Konsole, wird für den SCM-Server benutzt

12.3.3 Benötigte Benutzer

Diese Aufzählung beinhaltet Benutzer welche nicht auf dem bestehenden System vorhanden sind und neu angelegt werden:

 t_schaerer oMitglied in der Gruppe „sudo“ (Admin) und „ftp-users“ (FTP Zugriff)

12.3.4 Benötigte Gruppen

Die nachfolgende Aufzählung beinhaltet alle wichtigen Gruppen, welche Erstellt werden müssen um den Zugriff zu regeln, sie werden nach der Installation von Hand erstellt:

 ftp-users oGruppe für Benutzer welche Zugriffe auf ein FTP-Verzeichnis bekommen sollen.

oGruppenmitglieder: m_engels, j_windmeisser und t_schaerer.

12.4 Zu Installierende Software (Client/Server)

12.4.1 Server Software

Die auf dem Server zu installierenden Softwarepakete und eine kurze Beschreibung selbiger sind in der untenstehenden Tabelle:

• Softwarepaket Beschreibung Ubuntu Linux 14.04 Linux Betriebssystem, Ubuntu Distribution der Version 14.04. (Landscape Canonical, 2015) Apache Webserver Open-Source Webserver der Apache Software Foundation (Apache Foundation, 2015) Default-JRE/JDK Java-Laufzeitumgebung für die funktion von Java-Programmen und Java Entwicklungsumgebung zum Kompilieren von Java-Programmen MySQL DB-Server Datenbankserver für MySQL Datenbanken, sehr weit verbreitet. (Oracle, 2015) Mercurial-Server Plattformunabhäniges Versionsverwaltungssystem, Open-Source. (Mercurial Community, 2015) PHP Programm für die serverseitige Verarbeitung von PHP code für Webseiten. (PHP development Team, 2015) SCM-Manager Programm welches eine GUI für Mercurial zu Verfügung stellt, ermöglicht die Verwaltung von Mercurial über einen Webbrowser im Netzwerk. (Sdorra, 2015) OpenSSH-Server SSH-Server, ermöglicht sichere Dateiübertragungen und Remote-Verwaltung des Servers über das SSH-Protokoll. (the OpenBSD Project, 2015) vsftpd-Server FTP-Server für Linux-Systeme. Sehr stabil und schnell. Einfache Konfiguration. (Evans, 2015) Webmin Programm welches eine GUI für die Verwaltung des Servers über einen Webbrowser im Netzwerk zu Verfügung stellt. (Cameron, 2015)

Tabelle 21

12.4.2 Client Software

In dieser Tabelle sind die Programme welche auf dem Client vorhanden sein müssen gelistet, ist sie nicht vorhanden muss sie nachinstalliert werden:

• Softwarepaket Beschreibung NetBeans IDE 8.0.2 Vollversion Entwicklungsumgebung für Java, PHP, und andere Programmiersprachen. (NetBeans Community, 2015) TortoiseHg Programm welches eine GUI und eine WindowsShell Erweiterung für Mercurial zu Verfügung stellt. (Steve Borho and Yuki Kodama, 2015) Java Runtime Environment / Java Development Kit. Java-Laufzeitumgebung für die Funktion von Java-Programmen und Java Entwicklungsumgebung zum Kompilieren von Java-Programmen. PuTTY Terminalemulator für Fernadministration des Servers über SSH. (PuTTY Team, 2015) FileZilla FTP-Client zur Datenübertragung auf den Server und Umgekehrt. (File Zilla Team, 2015)

Tabelle 22

12.5 Migrationsablauf und Fallback-Szenario

Die Migration vom bestehenden auf das neue System wird vom eigenen Arbeitsplatz aus durchgeführt. Dazu wird „PuTTY“ Benutzt um eine sichere Verbindung zum Server über SSH aufzubauen. Auf dem neuen System wird das Programm „sftp“ des Softwarepaketes „OpenSSHServer“ benutzt.

Dieses Programm wurde schon bei der früheren Migration des SCM-Servers benutzt und hat sich bewährt.

Ein Fallback-Szenario wird benötigt, damit bei Problemen eine Rückfallebene existiert. Dies ist nach der Migration besonders wichtig.

12.5.1 Migrationsablauf

Der Ablauf der Migration ist in die folgenden Teile gegliedert:

1. Aufbau der Sftp-Verbindung zum besthenden System
2. Kopieren der Konfigurationsdateien des SCM-Servers
3. Kopieren der Mercurial-Repositories
4. Prüfen der Migration
5. Anpassen der Clients

12.5.2 Fallback-Szenario

Das Bestehende System wird nach der Migration einen Monat weiterbetrieben, damit eine Rückfallebene gewährleistet ist.

Würden nach der Migration Probleme entstehen, wird der bestehende Server bis zur Lösung des

Problems weiterbetrieben. Die migrierten Dateien werden, falls aktueller, auf das bestehende System zurückkopiert. Die Clients werden so angepasst, dass sie wieder den bestehenden Server verwenden.

Nach diesem Monat wird das bestehende System abgeschaltet und aus dem Netzwerk entfernt.

Damit aber eine Rückfallebene gewährleistet ist, wird es eingelagert. Treten während dieser Zeit Probleme auf, kann das System wieder in Betrieb genommen werden und die Daten können zurückmigriert werden.

12.6 Migrationszeitpunkt, Point of no-Return

12.6.1 Migrationszeitpunkt

Der Migrationszeitpunkt wurde mit den Benutzern des SCM-Servers auf Dienstag 31. März um 10:00 Uhr festgelegt, viele Benutzer befinden sich dann ausserhalb des Betriebs. Die Benutzer werden mit folgender E-Mail auf die anstehende Migration informiert:

Sehr geehrte Damen und Herren

Am Dienstag 31. März um 10:00 Uhr werden alle Repositories des bestehenden Source Control Server „PC0093“ auf den neuen Source Control Server „SCMSRV001“ migriert.

Während dieser Zeit ist es nicht möglich lokale Repositories auf den Server hoch- und herunterzuladen weil dies die Migration beeinträchtigen würde.

Sie werden nach der Migration eine E-Mail mit weiteren Informationen bezüglich des Zugriffs auf ihre Repositories erhalten.

Falls sie zu den Benutzern gehören, welche keinen Zugriff auf diesen Server hat, können Sie diese EMail ignorieren

Mit Freundlichen Grüssen

Matthias Engels

(Signatur Rafisa)

12.6.2 Point of no Return

Als Point of no Return wurde der 1.Mai 2015 gewählt, bis zu diesem Datum wird der bestehende Server als Rückfallebene verwendet. Nach diesem Datum wird der Bestehende Server aus dem Netzwerk entfernt.

12.7 Backupkonzept

12.7.1 Vorgaben

Die vorgegebenen Eckpunkte für das Backupkonzept sind die folgenden:

1. Backup muss am Montag, Mittwoch und Freitagabend um 18:00 Uhr ausgeführt werden
2. Das Backupskript muss in /bin/sh vorliegen
3. Die folgenden Verzeichnisse müssen gesichert werden:
   1. „/home“
   2. „/etc“
   3. „/srv/mercurial“
   4. „/srv/mysql“
   5. „/srv/www“
4. Die gesicherten Dateien sollen ihre Berechtigungen beibehalten
5. Das TAR-Archiv muss Komprimiert sein.
6. Backups welche älter als 15 Tage sind sollen gelöscht werden
7. Der Server soll nach dem Backup automatisch Herunterfahren
8. Die Strategie gilt nur für den Server und nur Daten und das ‚/etc‘ Verzeichnis werden gesichert, keine anderen Systemdateien, keine Programme.

12.7.2 Backupstrategie

Als Backupstrategie wurde ein Differenzielles Backup gewählt, bei diesem Backup werden jeweils die aktuellen Dateien und Einstellungen, und die Dateien und Einstellungen des Vorherigen Backups gesichert.

Diese Strategie wurde aus Sicherheitsgründen gewählt, wenn ein Backup, welches älter als 15 Tage ist automatisch gelöscht wird und Daten und/oder Einstellungen aus diesem Backup benötigt werden, sind diese in einem früheren Backup immer noch vorhanden.

12.7.3 Speicherort der Backups

Die Backups werden auf einer externen Festplatte gespeichert. Die Festplatte wurde schon beim bestehenden System verwendet und wird nicht formatiert. Dies weil die Backups des bestehenden Systems wichtige Daten anderer Dienste enthalten, welche dann verloren gehen würden.

12.8 SCM-Manager Start/Stop Script planen

Vorgaben

Die Vorgaben für das SCM-Manager Start/Stop Script sind die folgenden:

1. Der SCM-Manager muss vom Benutzer „scmmanager“ gestartet werden
2. Die Start-Einträge müssen in der Datei „/home/scmmanager/scmserver/var/log/scmmanager.log“ eingetragen werden.
3. Script muss via „bin/sh“ startbar sein
4. Script soll bei Init-Levels 2, 3, 4 und 5 starten
5. Script soll bei Init-Levels 0, 1 und 6 stoppen
6. Die Standard Linux-Initscript Startparameter „start, stop, status, und restart“ müssen implementiert sein
   1. Beim Parameter „start“ ist SCM-Manager zu starten
   2. Beim Parameter „stop“ ist SCM-Manager zu stoppen
   3. Beim Parameter „status“ soll angezeigt werden ob SCM-Manager läuft oder nicht
   4. Beim Parameter „restart“ soll der SCM-Manager gestoppt werden, falls der gerade läuft um wieder gestartet zu werden.

Vorarbeiten

Bevor das Skript implementiert werden kann müssen die folgenden Vorarbeiten erledigt sein:

• Benutzer „scmmanager“ angelegt
• SCM-Manager installiert
• Mercurial installiert

12.9 Abnahmedatum und Freigabe

Das Abnahmedatum wurde nach einem Gespräch mit dem Kunden auf Donnerstag, 9. April festgelegt. Am selben Tag wird das System für die Produktive Benutzung freigegeben.

13. Vorkonfiguration, Grundinstallation und Netzwerkkonfiguration

Nach Abschluss der Planungsphase, kann mit der Realisierung des Systems begonnen werden. In Diesem Kapitel geht es um diese Realisierung der einzelnen Teile des Projekts. Dabei ist zu beachten, dass kein Teil übersprungen wird, sonst muss das System aufwändig nachkonfiguriert werden. Die Anleitungen zur besseren Verständnis in Unterkapitel strukturiert.

Die Schritte 11.1 bis 11.5 werden im Labornetzwerk vorgenommen, danach wird das System im Rack eingebaut. Das System wird nach dem Einbau über das Programm „PuTTY“.

Um die Anleitung zu vereinfachen wurden für die Wichtigsten Schritte Bilder zur Beschreibung der Abläufe gemacht. Manchmal sagt ein Bild mehr als tausend Worte.

13.1 System Vorbereiten

13.1.1 Hardware einrichten

Bevor auch nur eine Installation und Konfiguration vorgenommen wird, müssen die folgenden Schritte ausgeführt werden.

1. Server im Labornetzwerk an die Stromversorgung anschliessen
2. Zusätzliche Festplatten einbauen
3. LAN-Kabel für Netzwerkverbindung anschliessen.
4. Peripheriegeräte anschliessen
   1. Bilschirm
   2. Maus
   3. Tastatur

13.1.2 Bootreihenfolge Ändern

Um die Konfiguration des RAID und die Installation des Betriebssystems vorzunehmen, muss die Bootreihenfolge geändert werden.

1. Server Einschalten
2. F9 drücken wenn die Aufforderung auf dem Bildschirm erscheint
   1. Jetzt wird das Konfigurationsprogramm für das BIOS geladen
3. Im Konfigurationsprogramm den Punkt „Standard Boot-Reihenfolge (IPL) wählen und mit Enter bestätigen.
4. Jetzt wird die Standard Boot-Reihenfolge angezeigt.
   1. Zum Ändern der Reihenfolge den entsprechenden Eintrag für das CD-Laufwerk mit den Pfeiltasten auswählen und „Enter“ drücken.
   2. Den ersten Eintrag wählen und mit „Enter“ bestätigten.
   3. Das Menü durch Drücken der „ESC“ Taste schliessen.
5. Zurück im Hauptmenü nochmals die „ESC“ Taste Drücken und das Speichern der Einstellungen mit „F10“ bestätigen.
6. Der Server startet neu, die Einstellungen werden automatisch übernommen.

13.2 RAID einrichten

Bevor das eigentliche System installiert wird, muss das RAID eingerichtet werden.

Dafür stellt der Hersteller des Server „Hewlett Packard“ eine spezielle Software zu Verfügung, sie heisst „SmartStart 7.7“. Bei diesem Server steht die Software auf eine CD-gebrannt zu Verfügung. Die neueste Version dieser Software kann auf der Herstellerseite Heruntergeladen werden: http://www8.hp.com/us/en/products/server-software/product-detail.html?oid=5219984

13.2.1 Anleitung zum Einrichten

Achtung: Beim Einrichten des RAID gehen alle Daten welche bisher auf der Festplatte gespeichert waren verloren. Bitte nur Festplatten verwenden, von denen man weiss, dass sie nicht mehr benötigt werden und keine wichtigen Daten gespeichert sind.

Die folgende Anleitung ist zum Einrichten von RAID 1 Arrays mit je zwei Festplatten im Array und einem Reservelaufwerk.

1. Server starten, beim Start das CD-Laufwerk öffnen und die CD einlegen. Die Bootreihenfolge sieht vor, dass zuerst von einer CD gestartet wird.
2. Das HP SmartStart Setup wird automatisch gestartet, fragt aber noch einmal nach ob man von der CD starten will, diese Option mit „Enter“ bestätigen
   1. Als nächstes Sprache wählen und Lizenzvereinbarung bestätigen.
3. Jetzt wird das Hauptmenü angezeigt(Abbildung 7) In diesem Hauptmenü auf „Server warten“ klicken.

Abbildung 7

- Das Wartungsmenü (Abbildung 8) wird angezeigt, in diesem auf „Array Konfigurieren“ klicken.

Abbildung 8

1. Dies ist das Konfigurationsmenü, es werden drei Spalten angezeigt(Abbildung 9). Links die verfügbaren Controller, mittig die Konfigurationsübersicht mit dem bestehenden Array und rechts die Konfigurationsmenüs.

Abbildung 9

1. Als erstes wird das bestehende Array gelöscht, dazu einfach auf das Array klicken und unter „Allgemeine Aufgaben“ auf „Löschen“. Das System wird eine Warnung anzeigen, dass beim Löschvorgang alle Logischen Laufwerke und Daten gelöscht werden, diese Bestätigen.
2. Nach der Löschung des Arrays sieht die Konfigurationsseite so aus (Abbildung 10).

Abbildung 10

1. Nun ist es möglich die Arrays neu zu erstellen. Smart Start bietet dafür einen

Konfigurationsassistenten, die nachfolgenden Bilder zeigen den Ablauf der Erstellung eines Arrays mit dem Assistenten.

1. Starten des Konfigurationsassistenten, auf „Konfigurationsassistenten“ klicken (siehe Abbildung 10)
2. Als nächstes klickt man auf „Array Erstellen“, dann auf „Beginnen“.
3. Jetzt können die Laufwerke für das Array gewählt werden (Abbildung 11).

Abbildung 11

1. Nach dem auswählen der Laufwerke für das Array wird gefragt, ob man dem Array ein Reservelaufwerk hinzufügen will, diese Option mit „ja“ bestätigen und auf „weiter drücken.
2. Es wird wieder eine Liste der Laufwerke angezeigt, für das erste Array wird das Laufwerk in „Bay 3“ gewählt, für das zweite Array jenes in „Bay 8“.
3. Auf „Fertigstellen“ drücken um die Änderungen im Array bestätigen.
   1. Für den Zweiten Array die Schritte 5.1 bis 5.6

1. Nach dem Erstellen der Arrays müssen die logischen Laufwerke erstellt werden, das sind die eigentlichen RAID-Arrays.
   1. Im Konfigurationsassistenten auf „Logisches Laufwerk erstellen“ klicken(Abbildung 12).

Abbildung 12

1. Den freien Speicher eines Arrays wählen, welcher zum Erstellen eines logischen Laufwerks wählen (Abbildung 13).

Abbildung 13

1. Fehlertoleranz wählen, bitte beachten wenn RAID 1+0 gewählt ist und nicht mehr als zwei

Festplatten ein Array bilden wird automatisch ein RAID 1 konfiguriert (Abbildung 14)

Abbildung 14

1. Die nächsten Einstellungen betreffend „Stripe-Grösse“ und „Max. Boot“ müssen nicht verändert werden, diese mit „weiter“ bestätigen.
2. Als nächstes wird die Grösse des logischen Laufwerks festgelegt, der Plan sieht vor, die maximale Grösse für den Array zu nutzen, also wird im Textfeld der Maximalwert eingegeben (Abbildung 15).

Abbildung 15

1. Die Einstellung für den Array-Beschleuniger wird deaktiviert, es gibt für diesen Server voraussichtlich keine hohen Zugriffsraten auf die Festplatten (Abbildung 16).

Abbildung 16

1. Mit einem Klick auf „weiter“ wird die Konfiguration abgeschlossen.
   1. Wiederholen der Schritte 6.1 bis 6.7 um ein logisches Laufwerk für das zweite Array zu konfigurieren.
2. Zurück im Hauptmenü des Assistenten (Abbildung 12), auf „Speichern“ Klicken um die Konfiguration der RAID-Arrays zu speichern.

1. Während der Konfiguration leuchten die LEDs der Festplatten blau. Dies zeigt an, dass sie sich im Konfigurationsmodus befinden, leuchtet daneben eine oder mehreren grünen LEDs wurde diese Festplatte im Menü ausgewählt. In Abbildung 17 wurde das zweite Array ausgewählt, es leuchten nur die benutzten Platten Nr. 6 und 7, Reservelaufwerke leuchten nicht grün. Die Platten Nr. 1 und 2 sind ein eigenständiges Array mit Platte 3 als Reserve.

Abbildung 17

13.3 Grundinstallation LAMP, Partitionierung, Updates und Datenablage anpassen

Vorbereitung

Vor der Partitionierung und der Installation von LAMP mitsamt Updates. Müssen die folgenden Bedingungen erfüllt sein:

 Server oAn das Labornetzwerk angeschlossen, DHCP und DNS-Server sind eingeschaltet oPeripheriegeräte (Bildschirm, Tastatur und Maus) sind angeschlossen Die neueste Version von Ubuntu 14.04 wird als ISO-Datei von dieser Seite Heruntergeladen:

http://www.ubuntu.com/download/server

Die ISO-Datei ist mit einem geeigneten Programm auf eine CD/DVD zu brennen. Windows bietet ein eigenes Programm an, welches für diese Zwecke ausreicht.

13.3.1 Grundinstallation

1. Server starten, beim Start das CD-Laufwerk öffnen und die CD einlegen. Die Bootreihenfolge sieht vor, dass zuerst von einer CD gestartet wird.
2. Das Installationsprogramm wird gestartet, als erstes muss die Sprache gewählt werden.
3. Auf dem Ersten Bildschirm „Install Ubuntu Server“ wählen und Enter drücken, dies startet die eigentliche Installation.
4. Der Sprachenwählbildschirm wird angezeigt, in diesem den Eintrag „German – Deutsch“ mit den Pfeiltasten wählen und Enter drücken.
5. Als nächstes ist der eigene Standort zu bestimmen, Eintrag „Schweiz“ wählen und mit Enter bestätigen.
6. Jetzt kommt die Tastaturbelegung, es wurde der erste Eintrag „Switzerland” gewählt.
7. Die Netzwerkkonfiguration wird gestartet.
   1. Als erstes muss die Primäre Netzwerkschnittstelle festgelegt werden, weil der Server über zwei Netzwerkkarten verfügt. Den Eintrag „eth0“ wählen und mit Enter bestätigen.
   2. Die Netzwerkschnittstelle wird automatisch mit DHCP erstellt, diese Konfiguration wird nach der Installation auf eine statische IP-Adresse geändert.
   3. Hostnamen des Servers gemäss Plan eingeben:“SCMSRV001“
8. Die Benutzerkonfiguration wird als nächstes durchgeführt.
   1. Vollen Namen des ersten Benutzers eingeben: „Matthias Engels“
   2. Benutzernamen eingeben: „m_engels“
   3. Passwort eingeben: „SA3eur..“
   4. Passwort wiederholen
9. Verschlüsselung des persönlichen Ordners mit „nein“ ablehnen
   1. Die Verschlüsselung wird nicht benötigt, weil der Server in einen abgeschlossenen Rack installiert wird.
10. Zeitzone prüfen und bestätigen

Die Installation wird an dieser Stelle unterbrochen, damit die Partitionierung der Festplatten durchgeführt werden kann.

13.3.2 Partitionierung

Nach der Konfiguration von Netzwerkschnittstelle, Benutzer und Zeitzone. Ist die Partitionierung der Festplatten notwendig, erst dann wird die Installation weitergeführt.

1. Partitionierungsmethode: „Manuell“ wählen.
   1. Die Erkannten RAID Arrays werden aufgelistet, Array wählen und Enter drücken.
   2. „Neue Partitionstabelle auf diesem Gerät erstellen?“ mit „ja“ bestätigen.
   3. Es wird erneut eine Liste der Arrays angezeigt, aber unter dem vorher ausgewählten wird der freie Speicher angezeigt, diesen wählen und Enter drücken.
   4. „Eine neue Partition erstellen“ wählen.
   5. Einstellungen zu Grösse, Typ, Position und Einhängepunkt können der

Partitionierungstabelle (Tabelle 20) in dieser Dokumentation entnommen werden.

1. Die Einstellung der SWAP-Partition wird in den Partitionseinstellungen unter „Benutzen als:“ festgelegt.
2. Das untere Bild ist eine Beispiel für eine Konfiguration der „/var“ Partition(Abbildung 18).

Abbildung 18

1. Nach dem alle Partitionen erstellt wurden sieht die Liste der Partitionen so aus wie auf dem unteren Bild ().

Abbildung 19

1. Mit „Partitionierung beenden und Änderungen übernehmen“ werden die Änderungen übernommen.
2. Als nächstes werden noch einmal alle Partitionstabellen und die zu formatierenden Partitionen angezeigt, diese Meldung mit „ja“ bestätigen.

13.3.3 Installation LAMP und OpenSSH-Server

1. Nach anlegen der Partitionstabelle heisst es warten, die Installation des Systems läuft weiter. 1.1. Die Frage nach den http-Proxy-Daten kann man leer lassen, es wird kein Proxy im Labornetzwerk und im Rafisa-Netzwerk verwendet.
   1. Die Konfiguration der automatischen Aktualisierungen auf dem Standard „Keine

Automatischen Aktualisierungen“ lassen, Updates können so nur von einem Administrator manuell installiert werden.

1. Das System zeigt jetzt eine Auswahl mit Softwarepaketen an, welch man für die Installation auswählen kann. In dieser Liste die Einträge „LAMP Server“ und „OpenSSH Server“ wählen und mit Enter bestätigen.

1.3.1. Der OpenSSH-Server wird für die Fernadministration benötigt, LAMP ist für diese Installation vorgegeben.

1. Für den MySQL „root“ Benutzer muss ein Passwort eingegeben werden. Bei diesem Server ist es „Passw0rd1“. Dieses Passwort muss noch einmal zur Bestätigung eingegeben werden.
2. Als letztes wird noch der GRUB-Bootloader installiert.
3. Nach der Installation von GRUB wird das System eine Meldung anzeigen, dass die Installation abgeschlossen ist. Die CD wird bei Bestätigung der Meldung automatisch ausgeworfen und der Server neu gestartet. Bitte die CD aus dem Laufwerk entfernen, sonst wird das System nicht gestartet.

13.3.4 Installation der Updates

Nach dem Neustart des Systems, mit dem bei der Installation erstellten Benutzer einloggen und den folgende Befehle ausführen:

• sudo apt-get upgrade o Dieser Befehl lädt automatisch die Updates Herunter, die Installation muss danach bestätigt werden.
• Sudo apt-get dist-upgrade o Dieser Befehl installiert automatisch Updates für alle Softwarepakete, zusätzlich werden neue Pakete Installiert und durch Änderungen unnötig gewordene Pakete werden gelöscht.

Nach dem zweiten Befehl ist ein Neustart erforderlich.

13.3.5 Anpassung der Datenablage

Einführung

Das neue System ist jetzt installiert, aber es ist erst eine Standardinstallation. Auf dem bestehenden System sind der Datenbankserver MySQL und das „www“ Verzeichnis des Apache Webservers nicht im „/var“ Verzeichnis des Servers sondern im „/srv“ Verzeichnis. Ebenso fehlt noch das „transfer“ Verzeichnis für den FTP-Server.

In diesem Abschnitt wird die Datenablage für die Verzeichnisse „/var/lib/mysql“ und „/var/www“ angepasst. Die Verzeichnisse „/var/transfer“ und „/backup“ werden zu gegebener Zeit erstellt.

Die Verzeichnisse müssen aus dem folgenden Grund verschoben werden: Das „/var“ Verzeichnis ist nur für veränderliche Daten, nicht für Datenbanken und Homepages. Andere Linux Distributionen wie SUSE oder Fedora speichern diese Ordner schon länger im „/srv“ Verzeichnis. Ubuntu hat dies beim „/var/www“ Verzeichnis umgekehrt gemacht und eine Verknüpfung in das „/srv“ Verzeichnis gelegt.

Vorgehensweise

Um nicht unnötig Konfigurationsdateien von Programmen zu ändern, welche mit MySQL oder Apache funktionieren wird die folgende Vorgehensweise benutzt:

• Prüfen, ob Verknüpfungen im „/srv“ Verzeichnis vorhanden sind und wohin sie zeigen.
• Verschieben der genannten Verzeichnisse in „/srv“ Verzeichnis
• Erstellen einer Symbolischen Verknüpfung gleichen Namens wie das verschobene Verzeichnis am Ursprungsort.

Verschieben von „www“

Die Verzeichnisse können nur als Benutzer „root“ verschoben werden, deshalb mit dem Befehl „sudo su“ ausführen, um „root-rechte“ für den Benutzer zu bekommen.

Die folgenden Befehle werden für die Verschiebung des „www“ Verzeichnisses ausgeführt:

• Service apache2 stop o Webserver stoppen
• cd /srv
• ls –la
• rm www

oalte verknüpfung löschen

• cd /var
• mv www /srv
• ln –s /srv/www www o Verknüpfung „www“ erstellen, ziel:“/srv/www“
• Service apache2 start

Verschieben von „mysql“

Das Verschieben des „mysql“ Verzeichnisses ist ein wenig komplizierter. Ubuntu benutzt ein Zugriffskontrollsystem namens „AppArmor“ welches Zugriffsberechtigungen für Programme im Dateisystem verwaltet.

Die folgenden Befehle werden für die Verschiebung des „mysql“ Ordners ausgeführt.

• Service MySQL stop
• cd /var/lib
• mv MySQL /srv
• ln –s /srv/MySQL MySQL

Jetzt ist der Ordner verschoben, MySQL kann aber wegen den AppArmor-Berechtigungen nicht gestartet werden.

Um die Zugriffsberechtigungen für AppArmor zu ändern, den folgenden Befehl eingeben:

• sudo nano /etc/apparmor.d/usr.sbin.mysqld

Unter den Zeilen mit dem Pfad „var/lib/mysql/“ werden jeweils neue Zeilen mit dem neuen Pfad des Ordners eingefügt „srv/mysql/“.

Der Screenshot unten zeigt die neuen Einträge in Gelb markiert(Abbildung 20).

Abbildung 20

• service apparmor restart o Startet den Dienst „apparmor“ neu.
• Service mysql start o MySQL Server neu starten.

Der Apache-Webserver ist unter der URL: http://10.0.0.108Erreichbar, dies ist eine DHCP-Adresse aus dem Labornetzwerk, sie ändert sich später.

MySQL ist nicht im Netzwerk erreichbar, die Konfigurtation von MySQL für das Netzwerk ist nicht bestand dieses Projekts.

13.4 Benutzer und Gruppen erstellen

13.4.1 Benutzer erstellen

In der Planung wurden zwei weitere Benutzer berücksichtigt, welche auch der Administration des Servers dienen sollen, diese werden mit dem folgenden Befehlen angelegt:

• Sudo adduser (Benutzername) –ingroup sudo o Benutzer wird erstellt und der Gruppe „sudo“ zugewiesen. Die Benutzer bekommen ein Standardpasswort „Passw0rd“.

Auch ist ein Benutzer „scmmanager“ vorgesehen, er soll über keine Anmelderechte und keine Gruppe verfügen. Der Benutzer muss über eine Bash-Shell und ein eigenes Verzeichnis haben.

Der Benutzer wird mit diesem Befehl erstellt:

• Adduser scmmanager –system –shell /bin/bash o Ein Systembenutzer mit Namen „scmmanager“ wird erstellt, er ist in keiner Gruppe, hat ein eigenes Verzeichnis und hat die Bash-Shell.

13.4.2 Gruppen erstellen

Für die Zugriffsregelung von FTP-Verzeichnissen ist eine Gruppe „ftp-users“ eingeplant. Alle bis jetzt erstellten Benutzer, ausser Systembenutzer und „root“ werden Mitglied dieser Gruppe.

Die Gruppe wird mit dem folgenden Befehl angelegt:

• sudo addgroup ftp-user o Eine neue Gruppe mit Namen „ftp-user“ wird angelegt.

Benutzer werden der Gruppe mit dem folgenden Befehl hinzugefügt:

• sudo usermod –aG ftp-users BENUTZERNAME o BENUTZERNAME ist durch den entsprechenden Benutzernamen zu ersetzen.

13.5 Netzwerkkonfiguration anpassen

Der Server steht momentan im Labornetzwerk und bezieht seine IP-Adresse dynamisch über DHCP, dies wird jetzt geändert, weil der Server in das Netzwerk der Rafisa eingebunden wird.

Vorgehensweise

Die Netzwerkeinstellungen sind in der Datei „/etc/network/interfaces“ hinterlegt, diese mit dem folgenden Befehl öffnen:

 nano /etc/network/interfaces o„nano“ ist ein einfach zu bedienender Text-Editor für die Konsole, er ist Standard bei jeder Installation.

Beim Abschnitt „#The loopback network interface“ diesen Abschnitt hinzufügen: Auto lo eth0 eth1

Unter dem Abschnitt „#The Primary network interface“ die Zeile: „iface eth0 inet dhcp“ löschen und die folgenden Zeilen eintragen:

auto eth0 iface eth0 inet static address 192.168.3.201 netmask 255.255.255.0 broadcast 192.168.3.255 network 192.168.3.0 gateway 192.168.3.1

dns-nameservers 192.168.3.9 192.168.3.11 8.8.8.8

auto eth1 iface eth1 inet statick address 192.168.3.202 netmask 255.255.255.0 broadcast 192.168.3.255 network 192.168.3.0 gateway 192.168.3.1

dns-nameservers 192.168.3.9 192.168.3.11 8.8.8.8

Dies ist die vollständige Netzwerkkonfiguration für die Netzwerkschnittstellen „eth0“ und „eth1“. Damit die Einstellungen übernommen werden, muss die Datei gespeichert und das System ausgeschaltet werden.

Der Server wird dann in das Rack eingebaut und an das Netzwerk der Rafisa angeschlossen, die vorher eingegebene Netzwerkkonfiguration wird beim Start des Systems automatisch übernommen.

Die Netzwerkkonfiguration wurde getestet, ein Testprotokoll ist in Kapitel 17. „Systemtests“ gespeichert.

14. Softwareinstallation und Konfiguration

Einführung

Der Server ist jetzt im Netzwerk der Rafisa GmbH eingebunden und kann mit dem Programm „PuTTY“ Remote-Verwaltet werden, allerdings nur über ein Terminal. Später wird mit Webmin ein Programm zur Verwaltung über das Netzwerk mit einer GUI installiert

Vorbereitung

Die folgenden Punkte müssen erfüllt sein, damit die Installationen durchgeführt werden können:

• Server Eingeschaltet o Ist der Server nicht eingeschaltet geschieht hier nichts.
• Server ist in Netzwerk erreichbar o Wenn der Server nicht im Netzwerk erreichbar ist, kann er nicht Remote-verwaltet werden.
• Server verfügt über Internetverbindung o Ohne Internetverbindung können Softwarepakete nicht heruntergeladen werden.
• Eine Remote-Verbindung über SSH mit PuTTY ist hergestellt.

oIst keine Remote-Verbindung vorhanden, muss der Server vor Ort administriert werden.

Kleiner Tipp: Text in der Zwischenablage des Clients kann in ein PuTTY-Terminal mit einem Rechtsklick eingefügt werden.

14.1 Installation JRE/JDK

Das JRE und das JDK sind getrennte Pakete welche auf dem Server installiert werden. Sie werden vom SCM-Manager zur einwandfreien Funktion benötigt.

Vorgehensweise

1. Mit PuTTY auf dem Server anmelden
2. Befehl zur Installation: „sudo apt-get install openjdk-7-jre openjdk-7-jdk
   1. Eigenes Benutzerpasswort für „root-rechte“ eingeben
   2. Installation bestätigen, der Server lädt automatisch weitere benötigte Pakete herunter.
3. Die Installation ist nach kurzer Wartezeit abgeschlossen.

14.2 Installation und Konfiguration Webmin

Webmin ist ein Programm welches die Verwaltung des Servers über eine GUI im Webbrowser ermöglicht. Das Programm wurde bis Ubunu 5.1 als offizielles Programm bei der Grundinstallation mitgeliefert. Es wurde dann aber aufgrund von Problemen aus den offiziellen Paketquellen entfernt. Diese Probleme sind heute zum Glück Geschichte.

Vorgehensweise

1. Mit PuTTY auf den Server als eigenen Benutzer anmelden.
2. Als erstes wird die Datei „sources.list“ mit „sudo nano /etc/apt/sources.list“ in einem Editor geöffnet, diese Datei enthält Einträge der Paketquellen.
3. Am Ende der Datei die folgenden zwei eintragen:
   1. deb http://download.webmin.com/download/repository sarge contrib 3.2. deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib
4. Die Datei speichern und schliessen.
5. Als nächstes muss der GPG-Schlüssel installiert werden.
   1. Befehl: „sudo wget http://www.webmin.com/jcameron-key.asc“ ausführen um den Schlüssel herunterzuladen.
   2. Den Schlüssel mit „sudo apt-key add jcameron-key.asc“ zur Liste der vertrauenswürdigen Schlüssel hinzufügen. Dies ist sehr wichtig, da das Paket sonst nicht Heruntergeladen werden kann.

5.2.1. Linux Bestätigt diesen Befehl mit „OK“.

1. Die Paketliste mit „sudo apt-get update“ neu einlesen, damit die Einträge in der „sources.list“ Datei übernommen werden.
2. Webmin mit „sudo apt-get install webmin“ herunterladen.
3. Nach der Installation ist Webmin unter der URL https://SCMSRV001:10000erreichbar oder unter https://192.168.3.201:10000/ https://192.168.3.202:10000wenn die Namensauflösung nicht funktioniert.
   1. Möglicherweise zeigt der Webbrowser an, dass die Seite nicht sicher ist, der Ladevorgang kann trotzdem fortgesetzt werden.
   2. So sieht das Anmeldefenster in Webmin aus (Abbildung 21)

Abbildung 21

Die Anmeldeinformationen sind die gleichen wie bei einer direkten Anmeldung über PuTTY.

1. Anmeldung in Webmin ist mit Benutzernamen und Passwort möglich, wenn der betreffende Benutzer in der Gruppe „sudo“ eingetragen ist.
2. Anzeigesprache in Webmin ändern:
   1. In Webmin auf „Webmin“ klicken, ein Menü wird ausgeklappt.
   2. In diesem Menü auf „Change Language and Theme klicken.
   3. Bei „Webmin UI language“ den Punkt „Personal Choice wählen und im nebenstehenden Dropdown-Menü „German (DE)“ wählen.
   4. Auf „Make Changes“ klicken, der Webmin wird neu gestartet.
   5. Webseite aktualisieren, die Sprache ist jetzt Deutsch.

14.3 Installation Mercurial und SCM-Manager

Nach dem Webmin Installiert und Konfiguriert wurde, werden jetzt die Pakete für Mercurial und den SCM-Manager heruntergeladen. Die Installationen haben zwei komplett verschiedene Vorgehensweisen welche in diesem Kapitel getrennt beschrieben werden.

14.3.1 Installation Mercurial Vorgehensweise

1. Mit PuTTY als eigenen Benutzer am Server anmelden
2. Befehl: „sudo apt-get install mercurial“ ausführen.

2.1. Installation bestätigen.

1. Nach der Installation wird Mercurial automatisch gestartet.

14.3.2 Installation SCM-Manager

Der SCM-Manager wird direkt in das „/home“ Verzeichnis des Systembenutzers „scmmanager“ installiert, dazu werden Webmin und PuTTY benötigt.

Wichtig: Pop-up Fenster müssen im Browser aktiviert sein, sonst werden bestimmte Fenster nicht angezeigt.

Vorgehensweise

1. Herunterladen der neuesten Version von SCM-Manager als Standalone-Verion unter: https://www.scm-manager.org/download/. Die „.tar.gz“ Datei wählen.
2. Webmin aufrufen unter: https://192.168.3.201:10000/anmelden als eigener Benutzer.
   1. Im Webmin-Menü den Abschnitt „sonstiges“ anklicken, ein Menü wird aufgeklappt.
   2. In diesem Menü auf „Datei-Manager (Java erforderlich) klicken.
      1. Es ist möglich, dass das Java-Plugin durch den Browser blockiert wird, der Browser zeigt in diesem Fall eine Fehlermeldung an und fragt in dieser nach, ob das Plugin gestartet werden soll.
      2. Java zeigt seinerseits auch Sicherheitswarnungen an, welche quittiert werden müssen um den Dateimanager zu starten.
   3. Nach dem Start in das Verzeichnis des Benutzers „scmmanager“ wechseln, Pfad:“ /home/scmmanager“.

1. Im Menü des Dateimanagers auf den Button „Hochladen“ drücken, ein Pop-up Fenster mit einer Eingabemaske für den Upload wird angezeigt.
2. In der Eingabemaske die folgenden Daten wie auf dem Screenshot eingeben(Abbildung 22):

Abbildung 22

1. Datei zum Hochladen ist die „.tar.gz“ Datei welche am Anfang Heruntergeladen wurde. Upload als Benutzer „scmmanager“ stellt sicher, dass dieser Benutzer automatisch Besitzer dieses Ordners wird.

Der SCM-Manager ist jetzt installiert und kann mit folgendem Befehlen in PuTTY gestartet werden:

• „sudo su scmmanager“ o Mit diesem Befehl wechselt man das Benutzerkonto zum Benutzer „scmmanager“
• „./home/scmmanager/scm-server/bin/scm-server“ o Dies ist der Pfad zum Startskript des SCM-Servers es wird später automatisch von unserem eigenen Start/Stop Script angesteuert.

SCM-Manager ist jetzt unter der folgenden URL erreichbar: http://192.168.3.202:8080/scm/.

Die Anmeldeinformationen sind die folgenden:

• Benutzername: scmadmin
• Passwort: scmadmin

Der SCM-Manager läuft so lange bis im PuTTY-Terminal „Ctrl+C“ gedrückt wird, der Server wird dann gestoppt.

Danach aus dem Benutzerkonto „scmmanager“ mit dem Befehl „exit“ ausloggen.

Anpassen der Zugriffsrechte

Damit der SCM-Manager später automatisch gestartet werden kann, müssen die Zugriffsrechte auf den Ordner „scm-server“ und zwei Unterordner angepasst werden.

In PuTTY sind die folgenden Befehle auszuführen:

• sudo chmod 777 /home/scmmanager/scm-server o Vollzugriff für das Verzeichnis „scm-server“, das Hauptverzeichnis des Servers.
• sudo chmod 777 /home/scmmanager/scm-server/conf o Vollzugriff für das Verzeichnis „scm-server/conf“, es enthält Konfigurationsdateien.
• sudo chmod 777 /home/scmmanager/scm-server/work o Vollzugriff für das Verzeichnis “scm-server/work” es enthält Informationen für den SCM-Manager Homepage.

14.4 Installation vsftpd

Einführung vsftpd ist ein FTP-Server welcher sehr stark auf Sicherheit aufbaut. Das Programm überprüft vor dem Start seine eigene Konfiguration und die Rechte aller Dateien auf die es Zugreifen soll und verweigert den Start bei einer eventuell falschen Konfiguration.

vsftpd ist der einzige Server im „main“-Zweig der Ubuntu-Distributionen, d.h. Pflege und die Versorgung mit Sicherheitsupdates ist garantiert.

Der Server ist sehr einfach zu konfigurieren, es ist möglich die Benutzer auf Ihre Homeverzeichnisse zugreifen zu lassen, ohne Umständlich Konfigurationsanleitungen zu wälzen. (ubuntuusers.de wiki, 2015)

In Webmin kann ein Modul zur Verwaltung von vsftpd installiert werden, dies ist aber nicht notwendig. Weil die Konfiguration auch so sehr einfach ist.

Vorgehensweise

Installation

• Mit PuTTY auf dem Server mit dem eigenen Benutzer anmelden
• Der Befehl zur Installation von vsftpd: „sudo apt-get install vsftpd“

Das Programm legt automatisch einen Systembenutzer „ftp“ und eine entsprechende Benutzergruppe an. Diese werden für anonymen Zugriff verwendet.

Zusätzlich wird das Verzeichnis „/srv/ftp“ angelegt, dieses Verzeichnis ist für die Daten der Anonymen Benutzer gedacht, auf diesem Server werden aber keine anonymen Benutzer zugreifen können.

Zertifikat anlegen

Nach der Installation von vsftpd muss noch ein SSL-Zertifikat erzeugt werden. Damit gesicherte Verbindungen über SSL möglich sind.

Dazu den folgenden Befehl in PuTTY ausführen:

• sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout

/etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem oDieser Befehl erstellt ein neues Zertifikat.

Nach Ausführung des Befehls müssen alle Fragen beantwortet werden, danach steht das Zertifikat zur Verfügung.

14.5 Einrichten der Datenablage für vsftpd

Einführung

Der Plan sieht vor, dass es auf dem Server ein Verzeichnis gibt, auf das die Systembenutzer zugreifen können um Daten auszutauschen. Es wird „/var/transfer“ genannt. Der Zugriff muss über die Benutzerberechtigung erfolgen.

Eine entsprechende Gruppe wurde vor der Installation von vsftpd schon angelegt, Mitglieder sind alle momentan erstellten Benutzer ausgenommen Systembenutzer und „root“

Anlegen des Ordners

Der Ordner wird mit dem Befehl „sudo mkdir /var/transfer“ angelegt. Der Ordner hat nun als Besitzer/Gruppe „root“.

Die Berechtigungen werden nun wie folgt geändert:

• Befehl „sudo chgrp ftp-users /var/transfer“ o Gruppe wird auf „ftp-users“ geändert
• Befehl „sudo chmod g+s /var/transfer“ o Wenn eine Datei/Ordner in „/var/transfer” erstellt wird, wird automatisch Gruppe „ftp-users“ als Benutzergruppe zugeteilt.
• Befehl: „chmod 777 /var/transfer“ o Berechtigungen für Order wird geändert, Vollzugriff für Besitzer, Gruppe und andere Benutzer.

14.6 Implementierung des Zugriffskonzepts

Die Konfiguration von vsftpd ist über eine Konsole wie PuTTY einfach. Alle wichtigen Einstellungen bezüglich des FTP-Zugriffs sind in der Datei „/etc/vsftpd.conf“ abgelegt, diese Datei muss nur in einem Editor bearbeitet und gespeichert werden.

Nachfolgend eine Anleitung zum Implementieren des Zugriffskonzepts:

Zugriffsrechte in vsftpd.conf

1. Mit PuTTY auf dem Server mit dem eigenen Benutzer anmelden.
2. „vsftpd.conf“ Datei mit dem Befehl „sudo nano /etc/vsftpd.conf“ in einem Editor öffnen.
   1. Vor der Zeile „local_enable=YES“ das „#“ Zeichen löschen. Lokale Benutzer wird der Zugriff gewährt.
      1. Das „#“ Zeichen deaktiviert eine Zeile in der Konfigurationsdatei.
   2. Die Zeile „write_enable=YES“ auf die gleiche Art wie vorher aktivieren.
      1. Dies erlaubt es über FTP eingeloggten Benutzern zu schreiben.
   3. Jetzt die Zeile „local_umask=022“ aktivieren und auf „local_umask=002“ ändern.
      1. Wenn eine Datei hochgeladen wird, bekommt sie damit automatisch die Zugriffsrechte

„rw-rw-r“, Ordner bekommen die Zugriffsrechte „rwxrwxr-x“ Dateien können von der Gruppe „ftp-users“ gelesen und verändert werden, Ordner haben zusätzlich ein Ausführungsrecht.

1. Die Zeile „chroot_local_user=YES“ aktivieren.
   1. Jetzt sind lokale Benutzer, welche via FTP eingeloggt sind auf ihr Benutzerverzeichnis beschränkt.
   2. Am Ende der Datei die folgende Zeile eintragen: „allow_writeable_chroot=YES“.
   3. Diese Zeile ermöglicht das Schreiben von lokalen Benutzern auf dem FTP-Server. Wird sie nicht eingefügt, ist es nicht möglich eine FTP-Verbindung als lokalen Benutzer aufzubauen.
2. Die Datei speichern und schliessen, danach vsftpd mit dem Befehl „sudo restart vsftpd“ neu starten.

FTP-Verzeichnis in Benutzerverzeichnis einhängen

Die Benutzer können sich jetzt mit FTP-einloggen aber sie sind auf Ihre Benutzerverzeichnisse beschränkt. Das Verzeichnis „/var/transfer“ muss bei jedem Benutzer „eingehängt“ werden, damit ein Datenaustausch möglich ist.

Als erstes muss in jedem Benutzerverzeichnis ein Ordner „transfer“ vorhanden sein. Dazu in der Konsole zum entsprechenden Benutzerordner navigieren und den Ordner mit dem folgenden Befehl anlegen: „sudo mkdir transfer“.

Das Verzeichnis „/var/transfer“ wird mit dem folgenden Befehl eingehängt:

• sudo mount –bind /var/transfer /home/BENUTZERNAME/transfer o Das Verzeichnis ist jetzt bis zum Herunterfahren eingehängt.

Damit das Verzeichnis auch nach einem Neustart erhalten bleibt, muss ein Eintrag in der Datei „/etc/fstab“ gemacht werden, dazu genannte Datei mit dem Befehl „nano /etc/fstab“ im Editor öffnen und eine Zeile wie diese eingeben:

• /var/transfer /home/BENUTZERNAME/transfer none bind 0 0 o BENUTZERNAME durch entprechenden Benutzernamen ersetzen.

Jede Zeile entspricht einem Einhängepunkt, bei diesem Server sind es momentan drei wie die Anzahl der Benutzer.

Der folgende Screenshot(Abbildung 23), zeigt die entsprechenden Einträge am Ende der Datei:

Abbildung 23

15. Migration

Einführung

Jetzt geht’s ans Eingemachte. Der Server ist installiert. Alle notwendigen Updates und Programme ebenso. Es existieren Benutzerkonten für die Verwaltung und ein Verzeichnis für den Datenaustausch mit FTP funktioniert ohne Probleme. Fehlen nur noch die Konfigurationsdaten für SCM-Manager und die Mercurial-Repositories des bestehenden Systems. Diese werden in diesem Kapitel migriert.

15.1 Vorbereiten der Migration

Die folgenden Punkte müssen für eine erfolgreiche Migration erfüllt sein:

• Migrationsdatum ist mit den Benutzern festgelegt.
  • Wird einfach so die Migration gestartet, gibt es Ärger mit den Benutzern, weil diese davon nichts wussten.
• Benutzer sind über die bevorstehende Migration informiert.
  • Sind die Benutzer nicht informiert, könnte die Migration schiefgehen, weil ein Benutzer in einem dummen Moment Dateien hoch- oder herunterlädt.
• Fallback-Szenario eingeplant o Wenn während oder nach der Migration ein Problem entsteht und das System ausfällt. Braucht es ein Fallback-Szenario sonst können die Benutzer nicht weiterarbeiten.
• Bestehender und neuer Server eingeschaltet o Ist ein Server nicht eingeschaltet, ist die Migration nicht möglich.
• Server sind im Netzwerk erreichbar o Wenn die Server nicht im Netzwerk erreichbar sind, muss die Migration auf andere Art durchgeführt werden.
• OpenSSH-Server ist auf dem neuen Server installiert.
  • Der OpenSSH-Server ermöglicht es erst diese Migration über das Netzwerk zu machen.
• Java Runtime Environment (JRE) und Java Development Kit (JDK) sind installiert.
  • Ohne JRE/JDK funktioniert der SCM-Manager nicht.
• Eine Remote-Verbindung mit SSH über SSH mit PuTTY ist hergestellt.
  • Ist keine Remote-Verbindung vorhanden, muss der Server vor Ort administriert werden.

Die Migration wird nur durchgeführt, wenn alle Punkte erfüllt sind. Ist auch nur ein Punkt nicht erfüllt ist dieser nachzuholen.

Während der Migration wird das bestehende System als „Quellsystem“ und das neue System als „Zielsystem“ bezeichnet

15.1.1 SCM-Server auf Quellsystem abschalten

Damit ein sicherer Ablauf der Migration garantiert ist, werden SCM-Manager und Mercurial auf dem Zielsystem zum Migrationszeitpunkt um 10:00 Uhr abgeschaltet, die Benutzer wurden darüber im Voraus informiert.

1. Mit PuTTY auf dem bestehenden System mit eigenem Benutzer anmelden.
2. Befehl: „sudo service scmmanager stop“ eingeben.

2.1. Nach Aufforderung, Benutzerpasswort eingeben.

1. Nach Ausführung dieses Befehls muss die Meldung „SCM successfully stopped“ erscheinen, dies bestätigt die Abschaltung des SCM-Servers.

15.1.2 Aufbau der sicheren Verbindung

Bevor die Migration startet, muss eine sichere Verbindung über SSH zum Quellsystem aufgebaut werden.

Vorgehensweise

1. Mit PuTTY auf dem Server mit dem eigenen Benutzer anmelden.
2. Befehl „sudo sftp m_engels@192.168.3.41“ eingeben.
   1. Dieser Befehl baut eine mit SSH gesicherte FTP-Verbindung auf, als erstes wird ein Benutzerkonto auf dem entsprechenden System angegeben, gefolgt von einem @ als Trennzeichen. Danach kommt die IP-Adresse des Systems.
   2. Passwort des Benutzers auf dem bestehenden System nach Aufforderung eingeben.
3. Die Verbindung ist hergestellt.
   1. Alle Linux-Befehle welche jetzt in der Konsole ausgeführt werden, betreffen das verbundene System. Damit ein Befehl auf dem System, von welchem die Verbindung aufgebaut wurde, wirksam wird muss ein „l“ für „local“ vorangestellt werden.
      1. Bsp. „cd /“ wechselt auf dem Verbundenen System zum Wurzelverzeichnis.
      2. Bsp. „lcd /“ wechselt auf dem lokalen System zum Wurzelverzeichnis.

15.2 Migration der SCM-Manager Konfiguration

Die SCM-Manager Konfiguration ist sehr wichtig, sie beinhaltet die Ablageorte der Repositories, Benutzerkonten und deren Zugriffsrechte auf die Repositories.

Die Konfigurationsdateien sind auf dem folgenden Pfad im Quellsystem gespeichert:

 /home/scmmanager/.scm

oDas Verzeichnis „.scm“ ist ein verstecktes Verzeichnis es kann in der Konsole nur mit dem Befehl „ls –la“ sichtbar gemacht werden.

15.2.1 Kopieren des Verzeichnisses „.scm“

Nach dem Aufbauen einer sicheren Verbindung gemäss Kapitel 14.1.2, kann der Ordner „/.scm“ nach folgender Anleitung Kopiert werden:

1. Befehl: „cd /home/scmmanager“ ausführen.
   1. Wechselt auf dem Quellsystem zum Benutzerverzeichnis des Benutzers „scmmanager“.
2. Befehl: „lcd /home/scmmanager“ ausführen.
   1. Wechselt auf dem Zielsystem zum Benutzerverzeichnis von „scmmanager“.
3. Befehl: „ls –la“ ausführen.
   1. Auflisten des gesamten Verzeichnisinhaltes auf dem Quellsystem, der Ordner „/.scm“ wird auch aufgelistet.
4. Befehl „get –r .scm“ ausführen.
   1. Das Verzeichnis „.scm“ rekursiv, d.h. mit allen Dateien und Unterordnern auf den lokalen Speicherort, bei welchem man sich befindet, kopieren. Der Bestehende Ordner wird überschrieben.
5. Nach kurzer Wartezeit ist das Verzeichnis kopiert.

15.2.2 Anpassen der Zugriffsrechte für „.scm“

Nach ausführen des Kopierbefehls muss geprüft werden, ob dieser korrekt ausgeführt wurde.

Dazu den Befehl „lls –la“ ausführen.

• Damit werden alle Verzeichnisse auf dem lokalen System aufgelistet, welche einen „.“

Vorangestellt haben, die Ausgabe des Befehls sieht etwa so aus wie auf dem Screenshot.(Abbildung 24)

Abbildung 24

Bei diesem Kopiervorgang werden die Benutzerberechtigungen nicht automatisch für diesen Ordner übernommen. Aber nur für den Hauptordner und die kopierten Dateien. Weil der SCM-Manager schon einmal lokal gestartet wurde, existieren im Ordner Dateien mit Benutzer und Gruppe „root“ dies muss geändert werden. Dazu die folgenden Befehle auf den Ordner „.scm“ ausführen:

• „sudo chgrp –R nogroup /home/scmmanager/.scm“ o Die Gruppe „nogroup“ wird Rekursiv Besitzergruppe des Ordners „.scm“.
• „sudo chown –R scmmanager /home/scmmanager/.scm“ o Der Benutzer „scmmanager“ wird Rekursiv Besitzer des Ordners „.scm“.

15.3 Migration der Mercurial-Repositories

Jetzt sind die Repositories an der Reihe, dies sind die wichtigsten Dateien dieser Migration. Würden diese nicht Kopiert wäre es wie ein Buch ohne Text. Der SCM-Server wäre leer. Die Repositories sind auf dem Quellsystem auf dem folgenden Pfad gespeichert:

 /srv/mercurial

15.3.1 Kopieren des Verzeichnisses „mercurial“

Nach dem Aufbauen einer sicheren Verbindung gemäss Kapitel 14.1.2, kann der Ordner „mercurial“ nach folgender Anleitung Kopiert werden:

1. Befehl: „cd /srv“ ausführen
   1. Wechselt auf dem Quellsystem zum Verzeichnis „/srv“.
   2. Auf dem Quellsystem in das Verzeichnis „/srv“ wechseln.
2. Befehl „lcd /srv“ ausführen
   1. Wechselt auf dem Zielsystem zum Verzeichnis „/srv“.
3. Befehl „get –r mercurial“ ausführen
   1. Das Verzeichnis „mercurial“ rekursiv, d.h. mit allen Dateien und Unterordnern auf den lokalen Speicherort, bei welchem man sich befindet, kopieren.
4. Nach kurzer Wartezeit ist das Verzeichnis kopiert.
5. Mit dem Befehl „exit“ sftp beenden.

15.3.2 Anpassen der Zugriffsrechte für „/srv/mercurial“

Nach dem Kopiervorgang müssen die Zugriffsrechte auf den kopierten Ordner angepasst werden, sonst kann der SCM-Server nicht darauf zugreifen. Dazu die folgenden Befehle in PuTTY ausführen.

• „sudo chgrp –R nogroup /srv/mercurial“ o Die Gruppe „nogroup“ wird Rekursiv Besitzergruppe des Ordners „mercurial“.
• „sudo chown –R scmmanager /srv/mercurial“ o Der Benutzer „scmmanager“ wird Rekursiv Besitzer des Ordners „mercurial“.

15.4 Prüfen der Migration

Einführung

Nach dem die Migration durchgeführt wurde ist es notwendig, sie zu Prüfen. Der Beschriebene Test ist ein Routinetest und wird später in der Testphase wiederholt und detailliert Dokumentiert.

Vorbedingungen

• Server ist Eingeschaltet und im Netzwerk erreichbar
• SCM-Manager ist gestartet
• NetBeans ist auf dem Testclient gestartet
• Es sind Repositories auf dem Client gespeichert, welche neuer sind als die Repositories auf dem Server

Durchgeführte Tests

• Bei SCM-Manager mit SCM-Benutzerkonto anmelden o Soll-Ergebnis: Anmeldung erfolgreich o Ist-Ergebnis: Anmeldung erfolgreich
• NetBeans: Repository Pushen/Pullen mit angepassten Pfaden o Soll-Ergebnis: Repository Push/Pull funktioniert

oIst-Ergebnis: Repository Push/Pull funktioniert, bei mehreren Projekten musste jeder Pfad einzeln angepasst werden.

15.5 Informieren der Benutzer

Um die Benutzer der Rafisa GmbH über die abgeschlossene Migration zu informieren, wurde die folgende E-Mail gesendet:

Sehr geehrte Damen und Herren

Die Migration des SCM-Managers und der Mercurial-Repositories ist abgeschlossen.

Die Dienste „SCM-Manager“ und „mercurial“ sind per 1. April nicht mehr erreichbar.

Die Dienste Apache Webserver, Bloodhound, MySQL, PostgreSQL und PHP sind weiterhin auf dem bestehenden Server erreichbar.

Bitte beachten Sie folgendes, der neue Server läuft im Testbetrieb, es kann zu Ausfällen kommen. Meldungen über allfällige Probleme oder Störungen am Server sind erwünscht.

Die URL für den neuen SCM-Server lautet: http://192.168.3.201:8080

Alle Bestehenden Benutzerkonten wurden migriert, die Berechtigungen sind erhalten geblieben.

Wenn sie in Ihrer Entwicklungsumgebung ein Repository Pullen/Pushen wollen, beachten sie bitte die neuen Pfade.

Push/Pull alt: http://pc0093:8080/scm/hg/PFAD/ZU/REPOSITORY

Push/Pull neu: http://192.168.3.202:8080/scm/hg/PFAD/ZU/REPOSITORY

Der neue Pfad muss bei einem Push/Pull des entsprechenden Repositories eingegeben werden. Bei Fragen bezüglich der Umstellung Ihres Clients stehe ich Ihnen gerne zur Verfügung.

Falls Sie zu den Benutzern gehören, welche keinen Zugriff auf diesen Server hat, können sie diese EMail ignorieren

Mit Freundlichen Grüssen

Matthias Engels

(Signatur Rafisa)

15.6 Anpassung der Clients

Die Anpassung der Clients wird von den Applikationsentwicklern, welche die Repositories nutzen selbst vorgenommen. Bei Problemen können sich die Applikationsentwickler an mich wenden um Hilfe zu erhalten.

16. Server-Scripts

Damit verschiedene Dienste im System automatisch gestartet oder gestoppt werden, sind Scripts notwendig. Auch für Backupaufgaben werden Scripts genutzt. Scripts automatisieren Abläufe welche sonst manuell ausgeführt werden. Bei verschiedenen Programmen werden Scripts bei der Installation automatisch mitgeliefert.

Gemäss Plan werden zwei Scripts benötigt, diese werden in diesem Kapitel erstellt.

Beide Scripts werden auf dem Migrierten Server erstellt und getestet. Die Benutzer wurden schon nach der Migration informiert, dass sich der Server im Testbetrieb befindet und der Betrieb deshalb eingeschränkt ist.

16.1 SCM-Manager Start/Stop Script

Das Script ist in drei Teile gegliedert: Startparameter, Funktionen und Befehlsabfrage. Auf den nächsten Seiten werden die Erstellung des Scripts, die Startparameter und die Funktionen beschrieben.

Das vollständige Skript ist im Anhang 2: Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. hinterlegt.

16.1.1 Erstellen des Scripts

1. Mit PuTTY auf dem Server als eigenen Benutzer anmelden und mit „sudo su“ die „root-rechte“ anfragen.
2. Mit dem Befehl „nano /etc/init.d/scmmanager“ wird ein Editor gestartet und die Datei angelegt.

2.1. Dies ist der Speicherort für alle Scripts welche beim Booten und Herunterfahren aufgerufen werden.

16.1.2 Startparameter

Dies ist der „Kopf“ des Scripts, er wird beim Start als erstes ausgelesen und Enthält wichtige Informationen:

#! /bin/sh

### BEGIN INIT INFO

# Provides: scmserver

# Required-Start: $remote_fs $syslog $network

# Required-Stop: $remote_fs $syslog $network

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: Starten des SCM-Servers bei Boot und auf Bash-Kommando. # Description:

### END INIT INFO

Dieser Text ist sehr Wichtig, er darf nicht gelöscht werden.

Dieser Header ist ein Standardheader, Ich habe diesen von einem anderen Skript übernommen welches auf dem Bestehenden System gelagert ist.

„JAVA_HOME“ hinzufügen

Der nächste Codeblock fügt die „JAVA_HOME“ Variable hinzu, dies ist eine Umgebungsvariable welche von SCM-Manager benötigt wird. #JAVA_HOME Umgebungsvariable hinzufügen. export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64

export PATH=$PATH:$JAVA_HOME/bin

Standard Rückgabewert

Damit das Script nur bei Fehlern eine Rückmeldung gibt, wird ein Standardwert vordefiniert: RETVAL=0

Dienstnamen definieren

Der Dienst benötigt einen bestimmten Namen dieser wird jetzt definiert:

appname=ScmServerDaemon

16.1.3Funktionen im Script

In den nächsten Abschnitten werden verschiedene Funktionen beschrieben welche im Skript zu bestimmten Bedingungen ausgeführt werden. Achtung: Gezeigt werden nur die wichtigsten Befehle. Verzweigungen im Skript und andere Funktionen wurden hier bewusst ausgelassen. Einem Kommentar, welches im Script vorkommt ist das „#“ Zeichen vorangestellt.

Startfunktion

#Das SCM-Server Start-Script als Benutzer „scmmanager“ aufrufen und start-Befehl ausführen bin/su scmmanager –c „/home/scmmanager/scm-server/bin/scm-server start

#Umleitung von Fehlermeldungen in die entsprechende Logdatei

» /home/scmmanager/scm-server/var/log/scmmanager.log 2>&1 &“

#Starteintrag in die entsprechende Logdatei einfügen

echo „SCM-Server successfully started“ » /home/scmmanager/scm-server/var/log/scmmanager.log

Stoppfunktion

#Prozess-ID des SCM-Servers suchen, detaillierte Prozessinformationen mit „ps auxwww“ abfragen,

#Ausgabe mit einer „pipe“ umleiten, mit „grep java“ die Prozessinformationen nach dem Wort „java“

#abfragen, dieses Ergebnis ebenfalls mit einer „pipe“ umleiten, mit „grep ${appname} nach dem #Dienstnamen durchsuchen und mit einer letzten „pipe“ die ausgabe umleiten, mit „awk ‚{print $2}‘ #die Prozessnummer ausgeben und in der Variable „SCM_PID“ speichern.

SCM_PID=$( ps auxwww | grep java | grep ${appname} | awk '{print $2 }' ) #Alle Prozesse mit der ID aus der Variable „$SCM_PID“ stoppen.

kill -9 $SCM_PID

Statusfunktion

Der Status Befehl verwendet die gleichen Suchparameter wie der Stopp-Befehl, ausser die Prozessnummer wird nicht ermittelt.

#Diese Verzweigung prüft die Rückgabewerte des Befehls, ist ein Rückgabewert vorhanden, wird dieser

#gelöscht und dem Benutzer gemeldet, das SCM läuft.

#Gibt es keinen Rückgabewert, wird dem Benutzer gemeldet, dass SCM nicht läuft. if ps auxwww | grep java | grep ${appname} > /dev/null then

echo „$appname is running“

else

echo „$appname is not running“ fi

Restartfunktion

Die Restart-Funktion verwendet die Befehle aus der Status- und der Stopp-Funktion. Zuerst wird eine eigene Stoppfunktion ausgeführt, dies . Nach dem sie durchgelaufen ist, wird die Start-Funktion aufgerufen.

#Die Restart-Befehl verwendet verwendet die gleichen Suchparameter wie der Stopp-Befehl, ausser #am Ende des Befehls, da werden die Anzahl Zeilen mit dem Befehl wc -l gezählt. Das Ergebnis wird #der Variable „STAT“ zugewiesen.

STAT=$( ps auxwww | grep java | grep ${appname} | wc –l)

16.1.4 Einbinden des Scripts

Nachdem das Script in der Datei geschrieben und diese gespeichert wurde, muss es jetzt noch ausführbar gemacht werden und in die Runlevel eingebunden werden.

Dazu müssen die folgenden Befehle ausgeführt werden:

• „sudo chmod 755 scmmanager“

oÄndert die Zugriffsberechtigungen auf Vollzugriff für den Ersteller/Besitzer und auf „lesen und ausführen“ für die Gruppe und andere Benutzer.

• „update-rc.d scmmanager scmmanager start 20 2 3 4 5 . stop 20 0 1 6“ o Dieser Befehl erstellt Verknüpfungen mit den entsprechenden Runleveln, bei den

Ordnern für die Runlevel 2, 3, 4 und 5 werden Verknüpfungen zum starten des Skripts angelegt, bei den Ordnern für Runlevel 0, 1 und 6 werden Verknüpfungen zum Stoppen des Dienstes angelegt.

Nach dem Einbinden stehen die folgenden neuen Befehle zur Verfügung:

• sudo service scmmanager start o Den Dienst starten
• sudo service scmmanager stop o Den Dienst stoppen
• Sudo service scmmanager status o Den Status des Dienstes abfragen
• Sudo service scmmanager restart o Den Dienst neu starten.

16.2 Backup Script

Das SCM Start/Stop Script ist installiert und Funktioniert. Aber dem Server ein sehr wichtiges Script, etwas, das immer dabei sein muss. Das Backup Script. In diesem Kapitel geht es um das Einbinden des Backupmediums, das Erstellen des Scripts, den Ablauf des Backups und die Automatisierung. Die Beim Backup erstellten „.tar.gz“ Dateien sind sog. „Tar-Archive“ sie werden hier Backups genannt.

16.2.1 Backupmedium in Server einbinden

Die Backupfestplatte ist die des bestehenden Systems. Diese Festplatte wurde zuerst aus dem entsprechenden Dateisystem „ausgehängt“ und an das neue System angeschlossen. Das Backupscript des bestehenden Systems wurde deaktiviert. Die Backups des bestehenden Systems werden nicht mehr benötigt.

Der Server erkennt automatisch die neue Festplatte wenn sie angeschlossen wird und teilt ihr einen Namen zu.

Formatieren der Festplatte

1. Anmelden in Webmin mit dem eigenen Benutzer
2. Das Menü „Hardware“ öffnen und dort auf „Festplatten-Partitionen“ klicken.
   1. Es wird eine Tabelle mit den allen Festplatten und Ihren Partitionen angezeigt. Die Angeschlossene Platte ist am Ende der Tabelle, diese anklicken.
   2. Auf „Lösche Partitionen“ klicken.
   3. Als nächstes auf „Lösche und benenne neu“ klicken, eine neue Partitionstabelle wird erstellt.
3. Es existieren noch keine Partitionen auf dieser Festplatte, auf „Primäre Partition hinzufügen“ klicken.
   1. Als Partitionstyp „Linux EXT“ wählen.
   2. Die Partition wird angelegt und in der Liste der Partitionen angezeigt, diese anklicken.
   3. Im Menü „Erzeuge Dateisystem“ den Punkt „New Linux Native (ext4) (ext4) wählen und auf „Erzeuge Dateisystem“ klicken.
   4. Die Optionen auf Standardeinstellungen lassen und auf „Dateisystem erstellen“ klicken.
   5. Das Dateisystem wird automatisch erstellt.

Einhängen der Partition

1. In PuTTY den Befehl:„cd/“ ausführen und dann den Befehl:„sudo mkdir /backup“ ausführen.
   1. Das Backupverzeichnis wird im Wurzelverzeichnis erstellt.
2. In Webmin als eigenen Benutzer anmelden und im Menü „System“ auf „Lokale- und NetzwerkDateisysteme“ klicken.
   1. Unter „Füge Mount hinzu„ die folgenden Optionen wählen (Abbildung 25) und anklicken.

Abbildung 25

1. Die Folgenden Einstellungen wie auf dem Screenshot (Abbildung 26) machen und auf „Speichern“ klicken, die Partition wird automatisch auch nach einem Neustart eingebunden.

Abbildung 26

16.2.2 Erstellen des Scripts

1. Mit PuTTY auf dem Server als eigenen Benutzer anmelden und mit „sudo su“ die „root-rechte“ anfragen.
2. Mit dem Befehl „nano /usr/local/bin/backup.sh“ wird ein Editor gestartet und die Datei angelegt.

2.1. Dieser Speicherort ist speziell für selbst erstellte Scripts gedacht. Scripts welche dort abgelegt werden, können später mit dem „Cron“ dienst automatisch gestartet werden.

16.2.3 Ablauf des Backups

In den nächsten Abschnitten werden Befehle beschrieben welche beim Ablauf des Backups ausgeführt werden. Achtung: wenn es mehrere Befehle sind, wird nur einer als Beispiel gezeigt. Das Vollständige Skript ist im Anhang 2. Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. hinterlegt.

Einem Kommentar, welches im Script vorkommt ist auch hier das „#“ Zeichen vorangestellt.

Vorbereitung

Dies ist der Anfang des Skripts, es werden Variablen und Werte deklariert, welche später Verwendet werden

#!/bin/bash

#Erstellen der Variablen und Werte deklarieren

HOSTNAME=$(hostname)

DIRECTORY=“/backup/$HOSTNAME/tmp„ #Pfad zum Temporären Verzeichnis

TIME=$(date '+%Y_%m_%d') #Aktuelles Datum yyyy_mm_dd

Temporären Ordner erstellen

Das Skript prüft ob ein Ordner im Pfad der Variable „DIRECTORY“ existiert, ist keiner vorhanden wird er mit diesem Befehl angelegt:

• /bin/mkdir –p $DIRECTORY o Dieser Befehl erstellt einen Ordner, die Option „-p“ die Übergeordneten Verzeichnisse wenn diese nicht existieren.

Erstellen der Backups

Jedes Backup wird mit einem Befehl wie diesem angelegt:

• /bin/tar –cpzf „$DIRECTORY/VERZEICHNISNAME.tar.gz“ „VERZEICHNISNAME“ o /bin/tar steht für den tar-Befehl in der Konsole die Parameter –cpzf bedeuten, dass ein neues Backup erzeugt wird(-c), die Zugriffsrechte beim Backup bleiben erhalten(p), das Backup wird zusätzlich mit „gzip“ Komprimiert (z) und das Backup wird in die im Pfad angegebene Datei geschrieben (f).

o„$DIRECTORY/VERZEICHNISNAME.tar.gz“ steht für den Speicherort des Backups. o„VERZEICHNISNAME“ für das zu sichernde Verzeichnis.

Alle Backups werden jetzt in einem Temporären Ordner erstellt, im nächsten Schritt werden sie zusammengefasst.

Zusammenfassen der Backups

Dies ist der Codeblock welcher die Backups zusammengefasst, der Dateiname besteht aus der Zeit an dem das Skript ausgeführt wurde und dem Hostnamen:

#Alle Backups im Zwischenverzeichnis zu einem Backup zusammenfassen und abspeichern.

/bin/tar -cpzf “/backup/$HOSTNAME/$TIME@$HOSTNAME.tar.gz„ “/backup/$HOSTNAME/tmp

Temporäres Verzeichnis löschen

Das Temporäre Verzeichnis wird mit dem folgenden Befehl gelöscht:

• /bin/rm -r $DIRECTORY o #„rm –r“ ist ein Rekursiver löschbefehl, er löscht alle Dateien und Ordner rekursiv,

d.h. Unterordner werden mit einbezogen.

Löschen älterer Backups

Backups, deren Inhalt sich in den letzten 15 Tagen nicht geändert hat werden mit dem folgenden Befehl gelöscht:

• /usr/bin/find „/backup/$HOSTNAME/“ -mtime +15 –delete o #“find” ist ein Suchbefehl, er sucht die angegebenen Dateien. o #„-mtime +15“ ist ein Suchparameter, der Dateiinhalt muss älter als 15 Tage sein.

o#„-delete“ ist eine Anweisung an „find“ gefundene Dateien werden gelöscht.

Herunterfahren des Systems

Nach dem das Script durchgelaufen ist wird das System Heruntergefahren und ausgeschaltet.

• /sbin/shutdown –P 0 o #Ausschalten nach dem Herunterfahren (-P) o #sofortiges herunterfahren (0)

Der Befehl zum Herunterfahren wird erst beim letzten Test aktiviert und wenn das System im produktiven Betrieb ist, er ist während der Testphase nur hinderlich. Weil das System dann Heruntergefahren wird, wenn das Skript manuell ausgelöst wird.

16.2.4 Modifizieren des Herunterfahrvorgangs

Damit ein Ausschalten des Systems nach dem Herunterfahren garantiert ist, muss in der Datei „/etc/default/grub“ eine Zeile verändert werden:

1. Die Datei mit dem Befehl „sudo nano /etc/default/grub“ in einem Editor öffnen.
2. In der Datei die Zeile „GRUB_CMDLINE_LINUX_DEFAULT=““ “ suchen.
   1. Zwischen den Anführungs- und Schlusszeichen „quiet splash acpi=force“ eintragen.
   2. Datei Speichern.
3. Mit dem Befehl „sudo update-grub“ werden die Einstellungen übernommen.
4. Nach einem Neustart werden die Einstellungen wirksam.

Diese Änderung bewirkt, dass der Server keine Meldungen beim Boot anzeigt und der Server nach dem Herunterfahren des Systems über ACPI abgeschaltet wird.

16.2.5 Bereitstellen des Scripts

Nach dem das Script erstellt und gespeichert ist müssen die Berechtigungen angepasst werden.

Dazu den folgenden Befehl ausführen:

 chmod 755 /usr/local/bin/backup.sh oÄndert die Zugriffsberechtigungen auf Vollzugriff für den Ersteller/Besitzer und auf „lesen und ausführen“ für die Gruppe und andere Benutzer.

Das Script kann jetzt durch den Befehl „sudo ./usr/local/bin/backup.sh“ ausgeführt werden. Achtung, wenn das Script manuell gestartet wird, wird der Server nach dem Backup heruntergefahren.

16.2.6Automatisieren des Scripts in Webmin

Das Backupscript ist jetzt funktionsbereit, es muss nur noch automatisiert werden.

Für die Automatisierung wird Cron benötigt, mit diesem Programm kann festgelegt werden, um welche Uhrzeit ein Script gestartet wird.

Für die Konfiguration dieses „Cronjobs“ wird Webmin benutzt. Es ermöglicht ein einfaches Erstellen des „Cronjobs“ mit einer GUI.

Anleitung zum Erstellen des Cronjobs

1. Anmelden in Webmin mit eigenem Benutzer
2. Das Menü „System“ aufklappen und auf den Link „Geplante Aufträge (Cron)“ klicken
   1. Es wird eine Liste mit allen Befehlen angezeigt (Abbildung 27)

Abbildung 27

1. In dieser Liste sieht man unter welchem Benutzer der Befehl ausgeführt wird, ob er Aktiviert ist und den Befehl selbst.
2. Eine Eingabemaske wird angezeigt, diese ist mit den folgenden Daten wie auf den nachfolgenden Screenshots zu füllen:
3. Auftrag-Details (Abbildung 28)

Abbildung 28

1. Wann Ausführen (Abbildung 29)

Abbildung 29

1. Minuten und Stunden (Abbildung 30)

Abbildung 30

1. Tage, Monate und Wochentage (Abbildung 31)

Abbildung 31

1. Auf „Erstellen“ klicken und der Prozess ist gespeichert.

Das Backup Script wird jetzt immer an jedem Montag, Mittwoch und Freitag um 18:00 Uhr ausgeführt.

17. Systemtest

17.1 Testobjekte

In der Untenstehenden Tabelle sind alle Testobjekte erfasst, welche für die Testfälle verwendet werden. Einige Tests werden im Abnahmeprotokoll mit dem Kunden wiederholt.

Tabelle 23

Objekt Beschreibung

• Mercurial Versionsverwaltungsprogramm auf dem Server SCM-Manager Administrationsprogramm mit GUI für Mercurial auf dem Server Apache-Webserver Webserver Tortoise Hg Mercurial-Clientprogramm NetBeans Entwicklungsumgebung für Clients, benutzt Tortoise Hg für den Zugriff auf Repositories Vsftpd FTP-Server FileZilla FTP-Client Scmmanager Start/Stop Script Script um SCM-Manager Manuell zu starten, stoppen, neustarten und status abfragen. Backup Script Backup Script auf dem Server, sichert zu vorgegebener Zeit die Systemeinstellungen, Benutzerdaten u.v.m.

17.2 Testumgebung

Diese Tabelle listet die Objekte in der Testumgebung mit Ihren Aspekten und Werten auf.

Tabelle 24

Objekt Aspekt Wert

• SCMSRV001 Prozessor Arbeitsspeicher RAID Netzwerkverbindung Betriebssystem FTP-Server SCM-Server Webserver Web-Administration SSH-Server Dual-Core AMD Opteron 4 GB RAM 2x RAID 1 Array 2x Ethernet mit statischer IP Ubuntu Server 14.04 LTS Vsftpd Mercurial und SCM-Manager Apache-Webserver Webmin OpenSSH-Server PC0037 Prozessor Arbeitsspeicher Netzwerkverbindung Betriebssystem Mercurial-Client Entwicklungsumgebung FTP-Client Webbrowser Remote-Verbindung für Server Intel Core i5 8 GB RAM 1x Ethernet mit DHCP Windows 7 SP1 Tortoise Hg NetBeansIDE FileZilla Google Chrome PuTTY Backup Festplatte Speicherplatz Dateisystem Anzahl Partitionen 2.0 TB Ext 4 1

17.3 Testfälle

Jede Tabelle für die Testprotokolle ist folgendermassen aufgebaut

• Feld Beschreibung Identifikation ID des Testfalls. Die ersten zwei Zahlen stehen für das Testprotokoll die anderen für den Testfall: ID 0101 steht für das erste Testprotokoll und den ersten Testfall. Vorbedingungen Die Vorbedingungen für den Test. Beschreibung Kurze Beschreibung des Tests. Testbericht Bericht, wo der Test ausgeführt wurde und was gemacht wurde. Resultat Soll-Resultat: das Resultat welches eintreffen soll. Ist-Resultat: das eingetroffene Resultat (Testfazit) Massnahmen und Konsequenzen Spezielle Massnahmen und Konsequenzen welche bei Abweichung des Soll-Resultats vorgenommen werden, sind hier festgehalten. Visum M.Engels dd.mm.yy

Testprotokoll 1

Dieses Testprotokoll umfasst die sog. Routinetests, diese werden jeweils nach einer Softwareinstallation oder einer Änderung im System ausgeführt.

Testdatum: 07.04.2015

Tabelle 25

• Identifikation ID 0101 Vorbedingungen Server ist im Netzwerk der Rafisa eingebunden und die statische Netzwerkkonfiguration wurde vorgenommen. Beschreibung Test der statischen Netzwerkkonfiguration im Rafisa-Netzwerk mit „Ping“ Testbericht Dieser Test wurde direkt am Server ausgeführt, es wurde versucht die folgenden Netzwerkadressen mit „Ping“ zu erreichen: 192.168.3.1 – Router der Rafisa 192.168.3.3 – Server Sifa 002 192.168.3.79 – PC0037 Resultat Soll-Resultat: Alle IP-Adressen antworten. Ist-Resultat: All IP-Adressen haben auf den „Ping“ geantwortet. Test ist Erfolgreich Visum M.Engels 07.04.15

Dieser Test ist zwar ein Routinetest, er wird aber trotzdem in das Abnahmeprotokoll eingetragen. Der Kunde soll wissen, dass die Netzwerkverbindungen geprüft wurden.

26

Tabelle 27

Tabelle 28

29

Tabelle 30

31

Testprotokoll 2

In diesem zweiten Testprotokoll sind die kritischen Tests,. Diese Tests werden so lange wiederholt bis alles ohne Probleme funktioniert.

Testdatum: 07.04.15

Tabelle 32

Tabelle 33

34

Tabelle 35

Tabelle 36

37

Tabelle 38

17.4 Statistik der Testfälle

Die Folgende Tabelle enthält eine Statistik aller Testfälle welche an einem bestimmten Datum durchgeführt wurde. Ist die Prozentzahl der Testfälle mehr als 60% gilt der Gesamtstatus als Erfolgreich. Tabelle 39

Anz.

Datum Testfälle Erfolglos Erfolgreich In % Gesamtstatus

17.5 Auswertung fehlgeschlagene Tests

Die Untenstehende Liste beinhaltet die IDs des fehlgeschlagenen Tests und der Grund warum der Test fehlgeschlagen ist:

• Test ID: 0102 o Vor dem Login-Dialog wird im Browser eine Sicherheitswarnung wegen fehlender Zertifikate angezeigt.
• Test ID: 0105 o Apache meldete nach einem Start oder Neustart:„could not reliably determine the server's fully qualified domain name…” (gekürzte Fehlermeldung)
• Test ID: 0203 o Befehl zur Wiederherstellung in der Anleitung ist Fehlerhaft, die Wiederherstellung wird nicht durchgeführt.

18. Auswerten

Nach dem die Tests durchgeführt wurden, geht es jetzt in die Auswertung. Als erstes wird eine

Statistik der Testfälle erstellt und die Fehlgeschlagenen Tests werden ausgewertet. Dann werden Massnahmen und Konsequenzen zu den fehlgeschlagenen Tests ergriffen. Die Fehlgeschlagenen Tests werden danach wiederholt.

Danach wird ein Abnahmeprotokoll für den Kunden erstellt welches von Ihm Unterzeichnet wird, dieses enthält die wichtigsten Testprotokolle und eine Bestätigung, dass das System einwandfrei funktioniert.

18.1 Massnahmen und Konsequenzen bei fehlgeschlagenen Tests

Test ID: 0102

Die Fehlermeldung wegen fehlenden Sicherheitszertifikaten kann einfach bestätigt werden. Sie ist eine Sicherheitswarnung im Benutzer zu warnen, dass die Verbindung nicht gesichert ist. Sie erschien schon beim bestehenden System.

Test ID: 0105

Damit dieser Fehler nicht mehr angezeigt wird, musste in der Datei „/etc/apache2/apache2.conf“ die Zeile „ServerName SCMSRV001“ hinzugefügt werden. Mit dem Befehl:

• sudo nano /etc/apache2/apache2.conf

Wurde die Datei in einem Editor geöffnet und die Zeile hinzugefügt, anschliessend wurde der Editor mit „Ctr+x“ geschlossen und die Datei gespeichert. Die Konfiguration wird nach einem Neustart mit dem Befehl: „sudo service apache2 restart“ übernommen.

Test ID: 0203

Der Befehl zur Wiederherstellung welcher in der Anleitung genannt wird ist Fehlerhaft. Der Korrekte Befehl zur Wiederherstellung geht so:

• tar –keep-newer-files –vxpzf DATEINAME.tar.gz –C /

Als Konsequenz daraus wurde der Befehl welcher in der Anleitung genannt wird angepasst.

Alle Fehlgeschlagenen Tests wurden nach den Korrekturen wiederholt. Es wurden keine Fehlermeldungen angezeigt.

18.2 Abnahmeprotokoll

Das Abnahmeprotokoll ist in die folgenden Teile gegliedert:

• Auftrag des Kunden
• Ausgeführte Arbeiten
• Abnahmetests
• Unterschrift

Auftrag des Kunden

• Installation eines neuen Linux-Servers.
  • Einrichten der Benutzerkonten des neuen Systems, analog des bestehenden Systems. o Installation eines FTP-Servers für die unabhängige Datenablage.
  • Installation und Konfiguration von Webmin zur Administration des Servers.
• Migration des bestehenden Source-Control Systems auf den neuen Server.
• Erstellen eines Backupkonzepts mit Backup Script
• Erstellen eines Start/Stop Scripts für SCM-Manager
• Schreiben von Anleitungen zur Datenwiederherstellung und zum Anlegen von Repositories.

Ausgeführte Arbeiten

• Bestehendes System wurde Analysiert.
• Ein Migrationszeitpunkt und ein Fallback-Szenario wurden mit dem Kunden festgelegt.
• Der neue Linux-Server ist Installiert.
  • Benutzerkonten wurden Analog des bestehenden Systems eingerichtet.

 Für den Betrieb des Source-Control-Servers wurde ein Systembenutzer erstellt.

• FTP-Server mit Verzeichnis für die unabhängige Datenablage wurde Installiert und Konfiguriert.
• Webmin ist installiert und Konfiguriert.
• Backupkonzept und Backup Script sind erstellt.
• Start/Stop Script für SCM-Manager wurde erstellt.
• Die Anleitungen zum Anlegen von Repositories und für die Wiederherstellung von Daten wurden geschrieben.
• Das Backupkonzept und Backup Script wurden auf Ihre Funktion getestet  Das SCM-Start/Stop Script wurde auf korrekte Funktion geprüft.
• Die Anleitungen zum Anlegen von Repositories und für die Wiederherstellung von Daten wurden getestet.

Abnahmetests

Die Abnahmetests werden zusammen mit dem Kunden durchgeführt.

Legende:

Unterschrift

Mit der Unterschrift wird die Ordnungsgemässe Abnahme des neuen Systems betätigt und das System am festgelegten Termin in den produktiven Betrieb übergeben:

Unterschrift Projektleiter Unterschrift Kunde

Ort, Datum und Unterschrift Ort, Datum und Unterschrift

18.3 Benutzerinformation über erfolgte Abnahme und anstehende Übergabe

Die Benutzer werden über die erfolgte Abnahme des Systems und die anstehende Übergabe in den Produktiven Betrieb mit der folgenden E-Mail informiert:

Sehr geehrte Damen und Herren

Der neue Source-Control Server SCMSRV001 wurde nach umfassenden Tests mit dem Kunden, Herr Jorge Windmeisser, freigegeben.

Es freut mich Ihnen mitteilen zu dürfen, dass der neue Source-Control Server heute Abend, Donnerstag 09.04.15 um 16:00 Uhr vom Testbetrieb in den produktiven Betrieb übergeht.

Der neue Source-Control Server fährt automatisch am Montag, Mittwoch und Freitagabend um 18:00 Uhr, nach einer Datensicherung herunter und muss danach manuell neu gestartet werden. Würde der Server ausserhalb dieser Zeiten heruntergefahren oder neu gestartet und ist dies nicht beabsichtigt, ist dies sofort bei mir zu melden.

Falls sie zu den Benutzern gehören, welche keinen Zugriff auf diesen Server hat, können Sie diese EMail ignorieren

Mit freundlichen Grüssen

Matthias Engels

(Signatur Rafisa)

19. Reflexion

Dieses Projekt ist eines der bisher grössten Projekte im Bereich der Systemtechnik welches ich im Alleingang durchgeführt habe. Ich selbst war schon einmal bei so einem Migrationsprojekt dabei, habe aber nur geholfen die eigentliche Migration durchzuführen. Ich war nicht bei den Arbeiten davor und danach dabei.

Die von mir gewählte Projektmethode IPERKA hat sich bei der Anwendung bewährt. Der Zeitplan wurde eingehalten, stellenweise war ich dem Zeitplan voraus, weil die Tätigkeiten schneller abgeschlossen wurden.

Viele wichtige Punkte welche die Migration betrafen, konnte ich im Voraus mit dem Kunden besprechen. Trotzdem mussten die Benutzer über die Anstehende Migration, den erfolgreichen Abschluss und die Übergabe des Servers in den Produktiven Betrieb informiert werden. Für mich war dies eine kleine Herausforderung, weil ich bis jetzt eher selten E-Mails direkt an die betroffenen gesendet habe. Dies war aber notwendig weil ich so alle auf einmal kontaktieren konnte.

Die Vorbereitungen der Hardware liefen bis auf ein kleines Problem mit der RAID-Konfiguration reibungslos, gleiches gilt für die Installation und Konfiguration des Betriebssystems und der

Programme. Die Migration

Die grösste praktische Arbeit lag in den Skripten, ich habe eigentlich sehr gute Kenntnisse im Schreiben von Shell-Skripten, diese hier waren aber komplexer als jene welche ich früher geschrieben habe.

Die Projektdokumentation ist die grösste welche ich bis jetzt geschrieben habe. Ich möchte mich hier bei Benjamin Deutsch bedanken, er hat eine Vorlage für Projektdokumentationen entworfen und nach einem Gespräch mit dem Fachvorgesetzten erlaubt sie zu Benutzen. Die Vorlage wurde von Mir leicht modifiziert, damit sie für mein Projekt anwendbar ist.

Die Dokumentation selbst war eine zeitintensive Angelegenheit. Teilweise mussten alle Kapitel neu nummeriert werden, weil ein neues Kapitel eingefügt werden musste.

Ich habe gemerkt, dass ich eine Tendenz habe, Dokumentationen möglichst ausführlich zu gestalten. Deshalb musste Ich mich ständig daran erinnern, das die Projektdokumentation einmal an einen anderen Informatiker mit Hintergrundwissen übergeben wird und nicht an einen einfachen Benutzer. Das gleiche galt für die Anleitungen zur Benutzung des SCM-Managers und für die Datenwiederherstellung.

Das Projekt war ein Erfolg auf der ganzen Linie, ich bin zufrieden mit meiner Arbeit und freue mich auf einen guten Abschluss dieser IPA.

20 Verzeichnisse

In den Bild- und Tabellenverzeichnissen sind nur Objekte gelistet welche nicht mit Word erstellt wurden.

20.1 Bildverzeichnis

20.4 Literaturverzeichnis

Apache Foundation. (23. 03 2015). Apache Homepage. Abgerufen am 23. 03 2015 von http://httpd.apache.org/

Cameron, J. (23. 03 2015). Webmin. Abgerufen am 23. 03 2015 von http://www.webmin.com/index.html

Coray, J., & Roggli, S. (2010). Modul 117: Informatik- und Netzinfrastruktur für ein kleines Unternehmen realisieren. Zürich CH: Compendio Bildungsmedien AG.

Evans, C. (27. 03 2015). vsftpd - secure, fast, FTP-Server for UNIX-Like systems. Abgerufen am 27. 03

2015 von https://security.appspot.com/vsftpd.html#about

File Zilla Team. (26. 03 2015). FileZilla - The free FTP solution. Abgerufen am 26. 03 2015 von https://filezilla-project.org/

Harnisch, C. (2002). Der bhv Co@ch Routing & Switching. Landsberg D: verlag moderne industrie Buch AG & Co. KG.

Landscape Canonical. (23. 03 2015). TrustyTahr/Release Notes. Abgerufen am 23. 03 2015 von https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes

Mercurial Community. (23. 03 2015). Mercurial SCM. Abgerufen am 23. 03 2015 von http://mercurial.selenic.com/about

NetBeans Community. (24. 03 2015). NetBeans IDE - Overview. Abgerufen am 24. 03 2015 von https://netbeans.org/features/index.html

Oracle. (23. 03 2015). MySQL. Abgerufen am 23. 03 2015 von http://www.mysql.de/

PHP development Team. (23. 03 2015). PHP: Hypertext Preprocessor. Abgerufen am 23. 03 2015 von http://php.net/

PostgreSQL. (23. 03 2015). PosgreSQL. Abgerufen am 23. 03 2015 von http://www.postgresql.org/about/

PuTTY Team. (26. 03 2015). Abgerufen am 26. 03 2015 von PuTTY: a free telnet/ssh client:

http://www.chiark.greenend.org.uk/~sgtatham/putty/

Samba Team. (23. 03 2015). Samba. Abgerufen am 23. 03 2015 von https://www.samba.org/samba/

Sdorra, S. (23. 03 2015). SCM-Manager. Abgerufen am 23. 03 2015 von https://www.scmmanager.org/

Steve Borho and Yuki Kodama. (24. 03 2015). TortoiseHG. Abgerufen am 24. 03 2015 von TortoiseHG

about: http://tortoisehg.bitbucket.org/about.html

the OpenBSD Project. (23. 03 2015). OpenSSH. Abgerufen am 23. 03 2015 von http://www.openssh.com/

The phpPgAdmin Project. (23. 03 2015). phpPAdmin - about. Abgerufen am 23. 03 2015 von http://phppgadmin.sourceforge.net/doku.php

Thomas Krenn Wiki. (24. 03 2015). Datei:RAID-1.png. Abgerufen am 24. 03 2015 von www.thomaskrenn.com: https://www.thomas-krenn.com/de/wiki/Datei:RAID-1.png

ubuntuusers.de wiki. (23. 03 2015). Postfix>wiki>ubuntuusers. Abgerufen am 23. 03 2015 von http://wiki.ubuntuusers.de/Postfix

ubuntuusers.de wiki. (27. 03 2015). vsftpd > Wiki > ubuntuusers.de. Abgerufen am 27. 03 2015 von http://wiki.ubuntuusers.de/vsftpd

Wikipedia. (23. 03 2015). Apache Bloodhound. Abgerufen am 23. 03 2015 von http://en.wikipedia.org/wiki/Apache_Bloodhound

Wikipedia. (25. Februar 2015). Wikipedia. Abgerufen am 26. Februar 2015 von http://de.wikipedia.org/wiki/Digital_Signage

21. Glossar

21.1 Abkürzungen

21.2 Begriffe

Advanced Configuration and Power Interface

Das Advanced Configuration and Power Interface (ACPI) ist ein offener Industriestandard für

Energieverwaltung in Desktop-Computern, Notebooks und Servern. Er wird federführend von den Unternehmen Hewlett-Packard, Intel, Microsoft, Phoenix Technologies und Toshiba entwickelt und stellt Schnittstellen zur Hardwareerkennung, Gerätekonfiguration und zur Energieverwaltung zur Verfügung. (Wikipedia, 2015)

Auslagerungsdatei

Die Auslagerungsdatei (engl. swap file oder page file) bezeichnet eine Datei auf einem

Massenspeichermedium eines Computers, die verschiedene Betriebssysteme im Rahmen ihrer Speicherverwaltung verwenden, um Prozessen einen größeren Adressraum zur Verfügung stellen zu können als durch den physisch vorhandenen Arbeitsspeicher eigentlich möglich wäre. (Wikipedia, 2015)

Linux verwendet anstelle einer Datei eine ganze Partition.

Apt-get

Das Advanced Packaging Tool (APT) ist ein Paketverwaltungssystem, das im Bereich des Betriebssystems Debian GNU/Linux entstanden ist und dpkg zur eigentlichen Paketverwaltung benutzt. Ziel ist es, eine einfache Möglichkeit zur Suche, Installation und Aktualisierung von

Programmpaketen zur Verfügung zu stellen. (Wikipedia, 2015)

broadcast

Die höchste Netzwerkadresse, wird benötigt um eine Mitteilung an alle Netzwerkgeräte zu senden.

Client

Ein Computer, welcher im Netzwerk auf den Server zugreift.

Commit

Das Übertragen von Änderungen an das Lokale Repository auf einem Client

Dynamic Host Configuration Protocol

Das Dynamic Host Configuration Protocol (DHCP) ist ein Kommunikationsprotokoll in der

Computertechnik. Es ermöglicht die Zuweisung der Netzwerkkonfiguration an Clients durch einen Server. (Wikipedia, 2015)

gateway

Die IP-Adresse des Routers im Netzwerk

JAVA_HOME

Umgebungsvariable für Java, sie beinhaltet den direkten Pfad zum Java Runtime Environment

Java Development Kit

Das Java Development Kit (JDK) des Unternehmens Oracle – ehemals von Sun Microsystems – ist eines der von Java-Entwicklern meistgenutzten Java-SDKs.

Im November 2006 gab Sun bekannt, dass das JDK unter der GNU General Public License (GPL) veröffentlicht wird.[2] Nun wird eine angepasste freie Version als ihr nunmehr offizieller Nachfolger unter dem Namen OpenJDK weitergeführt. (Wikipedia, 2015)

Java Runtime Environment

Die Java-Laufzeitumgebung (englisch Java Runtime Environment, kurz JRE) ist die Laufzeitumgebung der Java-Technik. Mit ihr werden Programme (Java-Anwendungen) weitgehend unabhängig vom darunter liegenden Betriebssystem ausgeführt. (Wikipedia, 2015)

Logisches Laufwerk

Bezeichnung eines RAID-Arrays durch die SmartStart Software.

nano

Nano ist ein freier Texteditor für Linux- und UNIX-Systeme sowie für Microsoft Windows. Er ist im Gegensatz zu anderen Anwendungen für die Befehlszeile – wie etwa vi – einfach zu bedienen, wodurch er bei Anfängern beliebt ist. (Wikipedia, 2015)

netmask

Die Subnetzmaske, sie legt fest wie viele IP-Adressen für Netzwerke und wie viele für Hosts im Netzwerk stehen.

Pull/Push

Das Hoch- bzw. Herunterladen von Änderungen an einem Repository oder eines gesamten Repository von/zum SCM-Server

PuTTY

PuTTY ist eine freie Software zum Herstellen von Verbindungen über Secure Shell, Telnet, Remote login oder serielle Schnittstellen. Dabei dient PuTTY als Client und stellt die Verbindung zu einem Server her. Beim Verbindungsaufbau wird die Identität des Benutzers mittels einer der bereitgestellten Methoden zur Authentifizierung überprüft. PuTTY ist für Windows und Linux verfügbar; inoffiziell auch für Windows Mobile und Symbian OS. (Wikipedia, 2015)

RAID

RAID ist ein Akronym für engl. „Redundant Array of Independent Disks“, also „Redundante Anordnung unabhängiger Festplatten“ (ursprünglich engl. „Redundant Array of Inexpensive Disks“; deutsch „Redundante Anordnung kostengünstiger Festplatten“; was aus Marketinggründen aufgegeben wurde). Ein RAID-System dient zur Organisation mehrerer physischer Massenspeicher[1] (üblicherweise Festplattenlaufwerke oder Solid-State-Drives) zu einem logischen Laufwerk, das eine höhere Ausfallsicherheit oder einen größeren Datendurchsatz erlaubt als ein einzelnes physisches

Speichermedium. (Wikipedia, 2015)

root-rechte

Mit den „root-rechten“ werden die Rechte des Benutzers „root“ gemeint, diese Rechte werden Benutzern gegeben welche Mitglied in der Gruppe „sudoers“ sind. Sie können nach einer Anmeldung an den Server mit dem Befehl „sudo su“ diese Rechte anfragen, sie müssen dafür aber Ihr Passwort eingeben.

Swap

Siehe Auslagerungsdatei

Tar-Archiv

tar ist ein im Unix-Umfeld sehr geläufiges Packprogramm. Außerdem wird so auch das Dateiformat bezeichnet, das von diesem Programm verwendet wird.

Der Name wurde aus tape archiver (Bandarchivierer) gebildet, da mit dem Programm ursprünglich Daten auf Bandlaufwerken gesichert wurden. Gleichzeitig ist tar auch das englische Wort für Teer (mit dem Programm werden Dateien unkomprimiert zu einer Datei „zusammengeklebt“).

Very Secure File Transfer Protocol Daemon

Der vsftpd ist ein Server für das File Transfer Protocol. Als Akronym steht sein Name für Very Secure File Transfer Protocol Daemon.

Die Bezeichnung als very secure (deutsch: sehr sicher) trägt dem Umstand Rechnung, dass der Schutz gegen unbefugte Nutzung im Mittelpunkt der Entwicklung steht. (Wikipedia, 2015)

Druckdatum: 10. April 2015 Matthias Engels Seite 9 von 109