zum Downloaden - alfsa

Diplomarbeit
ALFSA
Atemluftfüllstellenapplikation
16. Mai 2008
HTBLuVA St. Pölten
Höhere Lehranstalt für Elektronik
Ausbildungsschwerpunkt Technische Informatik
DIPLOMARBEIT
Atemluftfüllstellenapplikation (ALFSA)
ausgeführt an der
Abteilung für Elektronik der
Höheren Technischen Bundeslehr- u. Versuchsanstalt St. Pölten
Waldstraße 3, A-3100 St. Pölten
im Schuljahr
2007/08
von
Andreas Brandstätter, 5AHELI-02
Christoph Klaffl, 5AHELI-08
unter Betreuung von
Dipl.-Ing. Wolfgang Alfery
Dipl.-Päd. Ing. Gerd Riesenhuber
St. Pölten, am 2008-05-16
1
ALFSA
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende
Diplomarbeit selbständig und ohne fremde Hilfe verfasst,
andere als die angegebenen Quellen und Hilfsmittel
nicht benutzt und die den benutzten Quellen wörtlich
und inhaltlich entnommenen Stellen als solche
erkenntlich gemacht habe.
St. Pölten, am 2008-05-16
Andreas Brandstätter
Christoph Klaffl
Brandstätter Andreas, Klaffl Christoph
Seite i
ALFSA
Kurzfassung
ALFSA - Atemluftfüllstellenapplikation Mit dieser Diplomarbeit wird
ein verteiltes Datenbanksystem für die sepziellen Anforderungen der
Feuerwehr des Bezirkes Tulln realisiert. Alle Datenbankserver in dem System
agieren als Master und können von der Clientsoftware verwendet werden.
Die Syncronisation zwischen den geographisch getrennten Servern soll dabei
über das Internet stattfinden. Für die Gewährleistung der Datensicherheit,
im Bezug auf die Lesbarkeit der übertragenen Daten, soll eine sichere
Leitung mittels Verschlüsselung eingesetzt werden. Für die Verwaltung der
Server und der Feuerwehren (Benutzer, Füllstellen, ...) steht eine
Administrationsoberfläche via Webinterface bereit. Die Berechtigungen der
einzelnen Benutzer können über diese Web-Oberfläche eingestellt werden.
Um auch hier benutzerrelevante Daten zu schützen, wird SSL zur
Verschlüsselung verwendet.
Brandstätter Andreas, Klaffl Christoph
Seite ii
ALFSA
Abstract
ALFSA - (Air breath fill station application) The result of this diplom
thesis is a distributed Databasesystem for the special needs of the fire
brigade of the district Tulln. All Databaseservers in this System act as
Master and can be used by the client software. The syncronisation between
the geographically seperated servers should take place over the internet. To
provide data security, in reference to the readability of the transmitted data,
a secure line with encryption is used. The management of the severs and the
fire brigades (Users, fill stations, ...) is done via a Web-Administrative panel.
The permissions of the single users can also be set in this panel. Again SSL
is used for data encryption.
Brandstätter Andreas, Klaffl Christoph
Seite iii
ALFSA
INHALTSVERZEICHNIS
Inhaltsverzeichnis
Vorwort
Eidesstattliche Erklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kurzfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
i
ii
iii
Inhaltsverzeichnis
1
I
8
Projektmanagement
1 Projektmanagement
1.1 Spezifikation . . . . . . . . . . . . . . . .
1.2 Zeitplan . . . . . . . . . . . . . . . . . .
1.3 Strukturplan . . . . . . . . . . . . . . . .
1.4 Arbeitskalender . . . . . . . . . . . . . .
1.4.1 Brandstätter Andreas . . . . . . .
1.4.2 Klaffl Christoph . . . . . . . . . .
1.5 Diplomarbeitsbesprechungen . . . . . . .
1.5.1 Erste Diplomarbeitsbesprechung . .
1.5.2 Zweite Diplomarbeitsbesprechung .
1.5.3 Dritte Diplomarbeitsbesprechung .
1.5.4 Vierte Diplomarbeitsbesprechung .
1.5.5 Fünfte Diplomarbeitsbesprechung .
1.5.6 Sechste Diplomarbeitsbesprechung .
1.6 Besprechungsnotizen . . . . . . . . . . .
1.6.1 Erste Besprechungsnotiz . . . . . .
1.6.2 Zweite Besprechungsnotiz . . . . .
1.7 Kontakte . . . . . . . . . . . . . . . . . .
1.7.1 Entwicklerteam . . . . . . . . . .
1.7.2 Betreuer . . . . . . . . . . . . . .
1.7.3 Auftraggeber . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
11
12
12
14
16
16
17
18
19
20
21
22
22
23
24
24
24
25
Seite 1von 231
ALFSA
II
INHALTSVERZEICHNIS
Projektentwicklung
2 Verwendete Technologien
2.1 SSH . . . . . . . . . . . . . . . .
2.1.1 Allgemeines . . . . . . . .
2.1.2 Verwendung . . . . . . . .
2.1.3 Sicherheit . . . . . . . . .
2.1.4 Implementierungen . . . .
2.2 APACHE Webserver . . . . . . .
2.2.1 Allgemeines . . . . . . . .
2.2.2 Aufbau . . . . . . . . . . .
2.2.3 Implementierungen . . . .
2.2.4 Homepage . . . . . . . . .
2.3 Datenbanksystem . . . . . . . . .
2.3.1 Allgemeines . . . . . . . .
2.3.2 Anforderungen . . . . . .
2.3.3 Wartung . . . . . . . . . .
2.4 MySQL . . . . . . . . . . . . . .
2.4.1 Allgemeines . . . . . . . .
2.4.2 Aufbau . . . . . . . . . . .
2.4.3 Administration . . . . . .
2.4.4 Implemetierung . . . . . .
2.5 Linux . . . . . . . . . . . . . . .
2.5.1 Allgemeines . . . . . . . .
2.5.2 Was ist Linux? . . . . . .
2.5.3 Weitere Entwicklung . . .
2.5.4 Verbreitung . . . . . . . .
2.5.5 Distribution . . . . . . . .
2.6 Subversion . . . . . . . . . . . . .
2.6.1 Allgemeines . . . . . . . .
2.6.2 Funktionsweise . . . . . .
2.6.3 Implemetierung . . . . . .
2.7 SSL . . . . . . . . . . . . . . . .
2.7.1 Allgemeines . . . . . . . .
2.7.2 Funktionsweise . . . . . .
2.7.3 Verschlüsselungsverfahren
2.7.4 Vorteile . . . . . . . . . .
2.7.5 Nachteile . . . . . . . . . .
2.7.6 Probleme . . . . . . . . .
2.7.7 Implementierungen . . . .
2.8 PHP . . . . . . . . . . . . . . . .
2.8.1 Allgemeines . . . . . . . .
2.8.2 Funktionsweise . . . . . .
2.8.3 Syntax . . . . . . . . . . .
2.8.4 Implementierung . . . . .
2.9 JAVA . . . . . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
27
28
29
29
29
29
30
30
30
30
31
32
32
32
33
33
33
34
34
34
34
35
36
36
36
36
39
40
40
40
42
43
44
44
44
45
45
45
46
46
46
Seite 2von 231
ALFSA
INHALTSVERZEICHNIS
2.9.1
2.9.2
2.9.3
2.9.4
Allgemeines . . .
Funktionsweise .
Syntax . . . . . .
Implementierung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
47
47
48
3 Analysen und Entscheidungen
3.1 Betriebssysteme . . . . . . . . . . . . .
3.1.1 Debian Etch (LINUX) . . . . .
3.1.2 Microsoft Windows Server 2003
3.1.3 Entscheidung . . . . . . . . . .
3.2 Datenbank Server . . . . . . . . . . . .
3.2.1 MySQL [16] [17] . . . . . . . . .
3.2.2 PostgreSQL [17] . . . . . . . . .
3.2.3 Microsoft SQL Server 2005 [16]
3.2.4 Entscheidung . . . . . . . . . .
3.3 Replikation vs. Cluster [19] [18] . . . .
3.3.1 Cluster allgemein . . . . . . . .
3.3.2 Active-Passive-Cluster . . . . .
3.3.3 Active-Active-Cluster . . . . . .
3.3.4 Replikation allgemein . . . . . .
3.3.5 Master-Slave Replikation . . . .
3.3.6 Master-Master Replikation . . .
3.3.7 Entscheidung . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
49
50
50
51
51
51
52
52
53
53
53
54
54
55
55
56
4 Planung und Implementierung
4.1 Server aufsetzen . . . . . . . . . . . .
4.1.1 Installationsmedium besorgen
4.1.2 Installation . . . . . . . . . .
4.1.3 Konfiguration . . . . . . . . .
4.2 SSH Server aufsetzen . . . . . . . . .
4.2.1 Installation . . . . . . . . . .
4.2.2 Konfiguration . . . . . . . . .
4.3 Datenbankserver aufsetzten . . . . .
4.3.1 Installation . . . . . . . . . .
4.3.2 Konfiguration . . . . . . . . .
4.4 Webserver aufsetzten . . . . . . . . .
4.4.1 Installation . . . . . . . . . .
4.4.2 Konfiguration . . . . . . . . .
4.5 Subversion-Server aufsetzten . . . . .
4.5.1 Installation . . . . . . . . . .
4.5.2 Konfiguration . . . . . . . . .
4.6 Zeitspeicherung . . . . . . . . . . . .
4.6.1 Zeitumstellungsproblem . . .
4.6.2 Lösungsansatz . . . . . . . . .
4.6.3 Unixzeit . . . . . . . . . . . .
4.6.4 Einschränkungen . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
57
57
58
59
59
59
59
60
60
61
62
62
63
64
64
65
68
68
69
69
70
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Seite 3von 231
ALFSA
4.7
4.8
4.9
4.10
4.11
4.12
4.13
INHALTSVERZEICHNIS
4.6.5 Zeitsynchronität . . . . . . . . . . . . . .
Datenbankdesign . . . . . . . . . . . . . . . . .
4.7.1 Primärschlüssel . . . . . . . . . . . . . .
4.7.2 Spalte edit date . . . . . . . . . . . . . .
4.7.3 Löschen von Daten . . . . . . . . . . . .
4.7.4 Lineare Abhängigkeiten . . . . . . . . .
4.7.5 Grundlegende Struktur . . . . . . . . . .
4.7.6 Atemluftflaschen . . . . . . . . . . . . .
4.7.7 Füllungen . . . . . . . . . . . . . . . . .
4.7.8 Datenbankstruktur . . . . . . . . . . . .
4.7.9 Tabellen der Datenbank . . . . . . . . .
Datenbankzugriff . . . . . . . . . . . . . . . . .
Server - Server Syncronisation . . . . . . . . . .
4.9.1 Anforderungen . . . . . . . . . . . . . .
4.9.2 Konzept . . . . . . . . . . . . . . . . . .
4.9.3 Syncronisationsrichtung . . . . . . . . .
4.9.4 Anpassungen der Datenbankstruktur . .
4.9.5 Shell . . . . . . . . . . . . . . . . . . . .
4.9.6 CRON . . . . . . . . . . . . . . . . . . .
4.9.7 SSH . . . . . . . . . . . . . . . . . . . .
4.9.8 PHP . . . . . . . . . . . . . . . . . . . .
4.9.9 Datenbankstruktur aktualisieren . . . . .
4.9.10 Backupserver . . . . . . . . . . . . . . .
4.9.11 Fehlerbehandlung . . . . . . . . . . . . .
Client - Server Syncronisation . . . . . . . . . .
4.10.1 Vorgaben . . . . . . . . . . . . . . . . .
4.10.2 Konzept . . . . . . . . . . . . . . . . . .
4.10.3 Prinzip . . . . . . . . . . . . . . . . . . .
4.10.4 Realisierung . . . . . . . . . . . . . . . .
4.10.5 Umsetzung . . . . . . . . . . . . . . . .
4.10.6 Sequenzdiagramm . . . . . . . . . . . . .
4.10.7 Fehlerbehandlung . . . . . . . . . . . . .
Webinterface . . . . . . . . . . . . . . . . . . .
4.11.1 Übersicht . . . . . . . . . . . . . . . . .
4.11.2 index.php . . . . . . . . . . . . . . . . .
4.11.3 Template Engine . . . . . . . . . . . . .
Tests . . . . . . . . . . . . . . . . . . . . . . . .
4.12.1 Test des Webinterfaces . . . . . . . . . .
4.12.2 Test der Server - Server Synchronisation
4.12.3 Test der Client - Server Synchronisation
4.12.4 Pre-Alpha Development-Test . . . . . . .
Verwendete Hilfsmittel . . . . . . . . . . . . . .
4.13.1 Verwendete Software . . . . . . . . . . .
4.13.2 Allgemeine Quellen . . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
71
71
72
72
73
74
74
75
75
77
77
78
78
78
80
81
82
83
84
88
97
98
98
100
100
100
100
101
103
107
108
110
110
111
112
113
113
113
114
114
114
114
116
Seite 4von 231
ALFSA
III
INHALTSVERZEICHNIS
Wirtschaftlicher Teil
117
5 Allgemeines
5.1 Die Firma FRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Das Produkt ALFSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 General Public Liecense GPL . . . . . . . . . . . . . . . . . . . . . . . . . . .
118
118
118
119
6 Kostenrechnung
6.1 Kalkulation . . . . . . . . . . . . . . . .
6.1.1 Kalkulation der Fixkosten . . . .
6.1.2 Kalkulation der variablen Kosten
6.2 Support . . . . . . . . . . . . . . . . . .
6.2.1 Kalkulation der variablen Kosten
6.2.2 Preiskalkulation . . . . . . . . . .
6.2.3 Break-Even-Point . . . . . . . . .
.
.
.
.
.
.
.
120
120
120
121
122
122
122
122
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
124
124
124
125
125
125
125
126
126
127
127
127
128
128
129
130
7 Marketing
7.1 Marktanalyse . . . . . . . . . . .
7.1.1 Primäre Zielgruppe . . . .
7.1.2 Sekundäre Zielgruppe . . .
7.2 Konkurrenzanalyse . . . . . . . .
7.3 Marketing . . . . . . . . . . . . .
7.3.1 Der Firmenname . . . . .
7.3.2 Das Firmenlogo . . . . . .
7.3.3 Das Produktlogo . . . . .
7.3.4 Logos - Corporate Design
7.4 Werbung . . . . . . . . . . . . . .
7.4.1 Messen . . . . . . . . . . .
7.4.2 Feuer-Zeitschriften . . . .
7.4.3 Feuer-Webseiten . . . . . .
7.4.4 Taucher-Zeitschriften . . .
7.5 Promotionswebseite . . . . . . . .
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Handbuch
8 Administratorhandbuch
8.1 Willkommen . . . . . . . . . . . .
8.2 Voraussetzungen . . . . . . . . .
8.2.1 Hardware . . . . . . . . .
8.2.2 Software . . . . . . . . . .
8.3 Installation . . . . . . . . . . . .
8.3.1 Programmdateien kopieren
8.3.2 Rechte anpassen . . . . .
8.3.3 Einmalige Einstellungen .
8.3.4 Erster ALFSA Server . . .
Brandstätter Andreas, Klaffl Christoph
131
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
132
132
132
132
133
133
133
133
134
134
Seite 5von 231
ALFSA
8.4
V
INHALTSVERZEICHNIS
8.3.5 Konfiguration . . . . .
8.3.6 Fehlerbehandlung . . .
Bedienung . . . . . . . . . . .
8.4.1 Benutzerverwaltung . .
8.4.2 Feuerwehrverwaltung .
8.4.3 Fuellstellenverwaltung
8.4.4 Clientverwaltung . . .
8.4.5 Kompressorverwaltung
8.4.6 Serverliste . . . . . . .
8.4.7 Serververwaltung . . .
8.4.8 Konfiguration . . . . .
8.4.9 Synchronisieren . . . .
8.4.10 LOGViewer . . . . . .
8.4.11 Tabellenansicht . . . .
8.4.12 Fehlerhafte Eingabe . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Anhang
9 Anhang
9.1 Funktionen und Klassen . . . . . . . . . .
9.1.1 Teil Client-Server-Sync am Client .
9.1.2 Teil Server . . . . . . . . . . . . . .
9.1.3 Teil Client-Server-Sync am Server .
9.1.4 Teil Mehrfach genutzt . . . . . . .
9.2 Tabellen . . . . . . . . . . . . . . . . . . .
9.2.1 Tabelle abschnitte . . . . . . . . . .
9.2.2 Tabelle atemluftflaschen fuellung .
9.2.3 Tabelle atemluftflaschen maengel .
9.2.4 Tabelle atemluftflaschen . . . . . .
9.2.5 Tabelle atemluftflaschen pruefung .
9.2.6 Tabelle atemschutzgeraete maengel
9.2.7 Tabelle atemschutzgeraete . . . . .
9.2.8 Tabelle atemschutzgeraete pruefung
9.2.9 Tabelle atemschutzgeraete wartung
9.2.10 Tabelle atemschutzmasken maengel
9.2.11 Tabelle atemschutzmasken . . . . .
9.2.12 Tabelle atemschutzmasken wartung
9.2.13 Tabelle benutzer anmeldung . . . .
9.2.14 Tabelle benutzer . . . . . . . . . .
9.2.15 Tabelle benutzer schulung . . . . .
9.2.16 Tabelle bezirke . . . . . . . . . . .
9.2.17 Tabelle client . . . . . . . . . . . .
9.2.18 Tabelle dienstgrade . . . . . . . . .
9.2.19 Tabelle einsatz . . . . . . . . . . .
9.2.20 Tabelle feuerwehren . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
134
135
136
138
142
144
146
148
150
151
153
154
156
158
159
160
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
161
161
161
164
193
196
197
197
197
198
198
199
199
200
200
201
201
201
202
202
203
204
204
204
204
205
205
Seite 6von 231
ALFSA
9.3
INHALTSVERZEICHNIS
9.2.21 Tabelle
9.2.22 Tabelle
9.2.23 Tabelle
9.2.24 Tabelle
9.2.25 Tabelle
9.2.26 Tabelle
9.2.27 Tabelle
9.2.28 Tabelle
9.2.29 Tabelle
9.2.30 Tabelle
9.2.31 Tabelle
9.2.32 Tabelle
9.2.33 Tabelle
9.2.34 Tabelle
9.2.35 Tabelle
9.2.36 Tabelle
9.2.37 Tabelle
9.2.38 Tabelle
9.2.39 Tabelle
9.2.40 Tabelle
9.2.41 Tabelle
9.2.42 Tabelle
9.2.43 Tabelle
9.2.44 Tabelle
9.2.45 Tabelle
Dateiliste . .
fremdflaschen fuellung . . . .
fremdflaschen . . . . . . . . .
fuell sitzung . . . . . . . . .
fuellstelle . . . . . . . . . . .
geraetetraeger . . . . . . . .
geraetetraeger untersuchung .
gruppen . . . . . . . . . . . .
gruppen user . . . . . . . . .
kompressoren maengel . . . .
kompressoren . . . . . . . . .
kompressoren pruefung . . .
kompressoren wartung . . . .
nachrichten gelesen . . . . .
nachrichten . . . . . . . . . .
permission . . . . . . . . . .
person kontakt . . . . . . . .
person . . . . . . . . . . . . .
person telefon . . . . . . . .
schulung . . . . . . . . . . .
server details . . . . . . . . .
server . . . . . . . . . . . . .
sync . . . . . . . . . . . . . .
sync server log . . . . . . . .
sync vorgang . . . . . . . . .
verbindungskennung . . . . .
. . . . . . . . . . . . . . . . .
Verzeichnisse
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
205
206
206
206
206
207
207
207
208
208
209
209
209
210
210
210
211
211
211
212
212
212
212
213
213
213
220
Abbildungsverzeichnis
222
Listings
228
Tabellenverzeichnis
229
Literaturverzeichnis
230
Brandstätter Andreas, Klaffl Christoph
Seite 7von 231
ALFSA
Teil I
Projektmanagement
Brandstätter Andreas, Klaffl Christoph
Seite 8von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
Kapitel 1
Projektmanagement
1.1
Spezifikation
Ziel der Diplomarbeit ist es, ein hochverfügbares, verteiltes Datenbanksystem für die Feuerwehr des Bezirkes Tulln zu realisieren. Die Server sind dabei geographisch getrennt und
verfügen daher über kein eigens Netzwerk und müssen ihre Daten über ein unsichers Netzwerk (Internet) austauschen. Die Server müssen dabei ihre Daten stetig synchronsieren und
aktuell halten. Weiters muss ein asynchroner Datenaustausch mit Clients implementiert werden.
Abbildung 1.1: Struktur der verteilten Datenbank
Brandstätter Andreas, Klaffl Christoph
Seite 9von 231
ALFSA
1.2
KAPITEL 1. PROJEKTMANAGEMENT
Zeitplan
Monat
Oktober
November
Dezember
Jänner
Februar
März
April
Mai
Aufgabe
Formulierung der genauen Aufgabe
Einarbeitung in das Thema verteilte Datenbanken
Verschiedene Betriebsysteme analysieren
Datenbankkonzept erstellen
Betriebsysteme auswählen
verschiedne Datenbanksysteme analysieren
Datenbanksystem auswählen
Datenbankstruktur ausarbeiten
Server-Server Sychronisation entwerfen
Client-Server Sychronisation entwerfen
Datenbankstruktur festlegen
Dokumentation der Datenbankstruktur
Server-Server Sychronisation implementieren
Client-Server Sychronisation implementieren
Dokumentation der Software
Server-Server Sychronisation weiter implementieren
Client-Server Sychronisation weiter implementieren
Tests der Software formulieren
Dokumentation der Software
Tests der Server-Server Sychronisation
Tests der Client-Server Sychronisation
Dokumentation der Tests
Eventuelle Fehler der Server-Server Sychronisation beheben
Eventuelle Fehler der Client-Server Sychronisation beheben
Tests der Server-Server Sychronisation
Tests der Client-Server Sychronisation
Dokumentation der Tests
Weitere Inhalte der Dokumentation
Abschließen der Dokumentation
Tabelle 1.1: Zeitplan
Brandstätter Andreas, Klaffl Christoph
Seite 10von 231
ALFSA
1.3
KAPITEL 1. PROJEKTMANAGEMENT
Strukturplan
Abbildung 1.2: Strukturplan
Brandstätter Andreas, Klaffl Christoph
Seite 11von 231
ALFSA
1.4
1.4.1
KAPITEL 1. PROJEKTMANAGEMENT
Arbeitskalender
Brandstätter Andreas
KW Stunden Tätigkeit
37
12 Formulierung der Aufgabenstellung
Einarbeitung in das Thema
Besprechung mit Johannes Ofner und Christian Brandstätter
38
11 Einarbeitung in das Thema
39
14 Datenbanksychronisation Client-Server konzeptioniert
40
11 Datenbanksychronisation Client-Server grundlegend ausgeführt
Diplomarbeitsantrag fertiggestellt und abgegeben
Datenbanksycronisation Client-Server
42
15 Datenbank-Verbindung auf UTF-8 umgestellt (für Umlaute)
Grundlegende Systemänderungen
Diplomarbeitsbesprechung
Kooperationsvereinbarung eingeholt
43
7 Arbeitszeitkalender
44
17 Template-Engine
Installation der Software auf Server euklid
Logo entworfen und gezeichnet
Deckblatt entworfen
Zeitumstellungsploblem analysiert
Zeitumstellungsploblem dokumentiert
Installation der Software dokumentiert
45
13 Diplomarbeitsordner angelegt
Zustandsdiagramm der Datensynchronisierung
Plakat entworfen und gezeichnet
Client-Server Synchronisation (kleine Änderungen)
Template Engine (Bugfix)
46
9 Arbeitskalender
Plakat entworfen und gezeichnet
Sequenzdiagramm erstellt
48
4 Sourcecode-Autodokumentation
49
7 Client-Server-Syncronisierung an neue Config und DB-Struktur angepasst
grundlegende Informationen zur Dokumentation eingeholt
Logo für Scheinfirma gezeichnet
Prospekt für Scheinfirma entworfen
52
8 Synchronisation getestet und konfiguriert
1
5 Grafiken für Syncronisationsfortschritt entworfen
Brandstätter Andreas, Klaffl Christoph
Seite 12von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
2
7
3
9
5
21
6
7
10
12
8
9
7
6
10
5
13
14
14
12
19
20
22
12
270
Oberfläche der Synchronisation von Client-Server
Client-Server Synchronisation: Diverse Inhalte
Client-Server Synchronisation: verschiedene Server verwenden
Client-Server Synchronisation: Server zufällig auswählen
grafische Darstellung von Tabellen
Dokumentation: Beziehungen der Datenbank
Beziehungen erstellt
Beziehungen (eintragen / anzeigen)
Datenbank-Tabellenansicht (verbessert, foreign-keys)
Datenbankstruktur (Darstellung)
Datenbankstruktur (Verbesserungen, Dumps, Import)
Server-Server Synchronisation für Foreign Keys adapdiert
Tabellenanzeige in Server-Oberfläche implementiert
Promotionswebsite konzeptioniert
neue Client-Server-Synchronisation (komplett neu aufgebaut, mit foreign-keys)
Client für Server-Interface (Zentraldatenbank) adaptiert
Client-Server-Synchronisation verbessert
CMS für Promotionswebseite: Auswahl und Konfiguration
CMS: Konfiguration
Server-Client Synchronisation um Sicherheitsfunktionen erweitert
Client-Server Synchronisation an neue Tabellennamen angepasst, und div.
Maskottchen gezeichnet / entworfen
Beschreibung für HTL-innovativ
Client-Server Synchronisation diverse Änderungen
Client-server Synchronisation Bug behoben
Synchronisations-Hinweis und div.
Einladung und Vorbereitung für Information mit BFKDO und AFKDOS
Vorbereitung für Präsentation bei BFKDO und AFKDOS
Vorstellung von ALFSA bei BFKDO und AFKDOS (St. Andrä-Wördern)
vertiefte Analyse von verteilten Datenbanken
Aufbau und Test eines MySQL-Clusters
Abschließende Dokumentation
Abschließende Dokumentation
Abschließende Dokumentation
Gesamt
Tabelle 1.2: Arbeitskalender von Brandstätter Andreas
Brandstätter Andreas, Klaffl Christoph
Seite 13von 231
ALFSA
1.4.2
KW
37
38
39
40
41
42
44
45
47
48
49
50
51
53
54
1
2
4
KAPITEL 1. PROJEKTMANAGEMENT
Klaffl Christoph
Stunden Tätigkeit
11 Formulierung der Aufgabenstellung
Gegenüberstellung der Betriebssysteme
Softwareanforderungen der Auftraggeber studieren“ und überdenken
”
7 Gegenüberstellung der Datenbanksysteme
Gegenüberstellung der Möglichkeiten für das redundante
Datenbanksystem
8 Web-Interface Grundstruktur
11 Diplomarbeitsantrag fertiggestellt und abgegeben
Web-Interface entworfen
12 Analysieren der bestehenden Datenbank des Auftraggebers
Datenbankstruktur neu erstellen
Diplomarbeitsbesprechung
Kooperationsvereinbarung eingeholt
5 Eintragung aller Feuerwehren, Bezirke und Abschnitte
von NÖ in die Datenbank
9 Server – Server Synchronisation: Konzept erstellt
12 SSH Einarbeitung
Public-Key Authentifizierungsverfahren
Konfigurationslibarys erstellt
Web-Interface Konfigurationsseite für die Syncronisation
9 SSL Einarbeitung
Library für die Erstellung und Vewaltung der Public Keys
7 CRON Einarbeitung
Server – Server Synchronisation allgemein implementiert
10 Server – Server Synchronisation in PHP implementiert
11 Server – Server Synchronisation in JAVA implementiert
9 Testen und Vergleichen der Server – Server Synchronisation
in PHP und JAVA
13 Library für die Verwaltung von Cronjobs
Überarbeitung der Server – Server Synchronisation
Logging für dir Server – Server Synchronisation
11 Web-Interface Benutzerverwaltung
Web-Interface Server Liste
Einführung LATEX
Gegenüberstellung in LATEXdokumentiert
6 Web-Interface Füllstellenverwaltung
Optimierungen der Libaries
5 .htaccess Dateien erstellt
Cron Library - Intervalleinstellung
Brandstätter Andreas, Klaffl Christoph
Seite 14von 231
ALFSA
5
6
7
8
9
11
12
14
16
19
20
KAPITEL 1. PROJEKTMANAGEMENT
8 Beziehungen erstellt
Server-Server Syncronisierung: Einteilung der Tabellen
nach ihren Beziehungsebenen (FK)
Entwicklungsseite überarbeitet
9 Fehlerkorrekturen durchgeführt
Log Viewer programmiert
11 Login Maske erstellt
Inkompatibilitäten zu IE behoben
Server Verwaltung wurde komplett neu geschrieben
Design Änderungen
4 Cookie Funktion ( Remember Me“)
”
8 Web-Interface Benutzerverwaltung überarbeitet
Client-Server-Synchronisation verbessert
Abstract und Zusammenfassung
Server - Server Synronisation: Fehlerbereinigung
10 Server Verwaltung wurde komplett neu geschrieben
Log Viewer wurde überarbeitet
Web-Interface Client Verwaltung
12 Library für Systeminformationen
Passwort System von md5 auf crypt mit Salt umgestellt
Server – Server Syncronisation: freien Port herausfinden
Log Viewer überarbeitet
Vorbereitung für Präsentation bei BFKDO und AFKDOS
Vorstellung von ALFSA bei BFKDO und AFKDOS (St. Andrä-Wördern)
10 vertiefte Analyse von verteilten Datenbanken
Aufbau und Test eines MySQL-Clusters
7 Letzten Fehler behoben
Programmcode verbessert und unötigen Code entfernt
Dokumentation
15 abschließende Dokumentation
14 abschließende Dokumentation
264 Gesamt
Tabelle 1.3: Arbeitskalender von Klaffl Christoph
Brandstätter Andreas, Klaffl Christoph
Seite 15von 231
ALFSA
1.5
KAPITEL 1. PROJEKTMANAGEMENT
Diplomarbeitsbesprechungen
1. Diplomarbeitsbesprechung
2007/08
ALFSA
Termin
Ort
2007-10-17 14:50
HTBLuVA St. Pölten / W016
Teilnehmer
DI Wolfgang ALFERY
Andreas BRANDSTÄTTER
Christoph KLAFFL
Bericht
Klaffl, Brandstätter
Grundlegende Anforderungen für ALFSA wurden vom Projektleiter DI Johannes Ofner in
schriftlicher Form übermittelt.
Bisher wurden folgende Punkte erarbeitet:
• Erörterung der Möglichkeiten zur Realisierung einer hochverfügbaren Datenbank
• Vergleich verschiedener Open-Source Datenbank-Systeme
• Konzipierung einer Datenbank-Synchronisierung von Client und Server
• Test-Realisierung der Synchronisierung von Client und Server
Vorführung
• Benutzeroberfläche der Synchronisierung
• Test der der Synchronisierung
Planziele
Alfery
•
•
•
•
•
•
•
Diplomarbeitsordner ist anzulegen
Dokumentation ist nach den Richtlinien „Software Projekt Dokumentation“ auszuführen
Spezifikation, Zeitplan und Strukturplan ist zu erarbeiten
Für die laufende Durchführung der Diplomarbeit ist ein Arbeitskalender zu erstellen
Für die Entwicklung der Client-Server Synchronisation ist eine Darstellung als
Zustandsdiagramm anzugeben
Weiterentwicklung der Client-Server Synchronisation
Entwurf und Entwicklung der Datenbankstruktur
nächster Besprechungstermin: 2007-11-14
Brandstätter Andreas, Klaffl Christoph
Seite 16von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
2. Diplomarbeitsbesprechung
2007/08
ALFSA
Termin
Ort
2007-11-14 12:10
HTBLuVA St. Pölten / W016
Teilnehmer
DI Wolfgang ALFERY
Andreas BRANDSTÄTTER
Christoph KLAFFL
Bericht
Klaffl, Brandstätter
Folgende Punkte wurden vorgeführt:
• Diplomarbeitsordner
• Ansätze der Dokumentation ist nach den Richtlinien „Software Projekt Dokumentation“
• Spezifikation und Zeitplan
• Arbeitskalender der laufenden Durchführung
• Sequenzdiagramm und Entwurf des Zustandsdiagrammes der Client-Server
Synchronisation
Vorführung
• Client-Server Synchronisierung wurde ergänzt mit der Prüfung und Erstellung der
Tabellenstruktur sowie der Aufteilung in einzelne Datenpakete
Planziele
Alfery
•
•
•
•
•
Weiterentwicklung des Zustandsdiagrammes der Client-Server Synchronisierung
Flussdiagramme für die einzelnen Zustände
Entwurf und Entwicklung von Lösungen diverser Timeout-Szenarien
Entwurf und Realisierung eines Testprogrammes zur Evaluierung von Synchronisation und
Fehlerfällen
Entwurf der Server-Server Synchronisierung
nächster Besprechungstermin: 2008-01-09
Brandstätter Andreas, Klaffl Christoph
Seite 17von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
3. Diplomarbeitsbesprechung
2007/08
ALFSA
Termin
Ort
2008-01-09 12:10
HTBLuVA St. Pölten / W016
Teilnehmer
DI Wolfgang ALFERY
Andreas BRANDSTÄTTER
Christoph KLAFFL
Bericht
Klaffl, Brandstätter
Folgende Punkte wurden erarbeitet:
• Sequenzdiagramm der Client-Server Synchronisation
• Erarbeitung der Fehlerszenarien bei Client-Server Synchronisation
• Technische Dokumentation über verwendete Techniken
Vorführung
• Server-Server Synchronisierung wurde entworfen und realisiert
Planziele
Alfery
• Dokumentation der Diplomarbeit über den Entwurf und die Ausführung der Client-Server
Synchronisierung
• Dokumentation der Diplomarbeit über den Entwurf und die Ausführung der Server-Server
Synchronisierung
• Darstellung der Fehlerszenarien im Sequenzdiagramm
• Terminvereinbarung mit Auftraggeber zur Abstimmung der bisherigen Ergebnisse
nächster Besprechungstermin: 2008-02-20
Brandstätter Andreas, Klaffl Christoph
Seite 18von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
4. Diplomarbeitsbesprechung
2007/08
ALFSA
Termin
Ort
2008-02-27 12:10
HTBLuVA St. Pölten / W016
Teilnehmer
DI Wolfgang ALFERY
Andreas BRANDSTÄTTER
Christoph KLAFFL
Bericht
Klaffl, Brandstätter
Besprechungsnotiz mit Auftraggeber (Johannes Ofner)
• Dazu notwendige Anpassungen bzw. Änderungen
Dokumentation
• Grundlegende Technologien
• Darstellung der Fehlerszenarien
Vorführung
• Neue Client-Server Synchronisierung
Planziele
Alfery
• Änderungen und Anpassungen implementieren (siehe Besprechungsnotiz)
• Dokumentation: Ausführung der Client-Server Synchronisierung (gesicherte
Datenübertragung)
• Browserkompatibilität weiter ausführen
• Konzept zu Tests der Software erstellen
nächster Besprechungstermin: 2008-04-09
Brandstätter Andreas, Klaffl Christoph
Seite 19von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
5. Diplomarbeitsbesprechung
2007/08
ALFSA
Termin
Ort
2008-04-09 12:10
HTBLuVA St. Pölten / W016
Teilnehmer
DI Wolfgang ALFERY
Andreas BRANDSTÄTTER
Christoph KLAFFL
Bericht
Klaffl, Brandstätter
Besprechungsnotiz mit Bezirksfeuerwehr- und Abschnittsfeuerwehrkommando
• Präsentation des Projektstandes
• Diskussion und letzte Änderungsvorschläge
Dokumentation
• Logo und Prospekt
• Wirtschaftlicher Teil
Vorführung
• vertiefte Analysen von verteilten Datenbanken
• Live-MySQL-Cluster
Planziele
Alfery
• Dokumentation weiter ausführen
• Tests der Software formulieren, ausführen und dokumentieren
• Bestätigung über Projekterfolg bei Auftraggeber einholen
nächster Besprechungstermin: 2008-05-07
Brandstätter Andreas, Klaffl Christoph
Seite 20von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
6. Diplomarbeitsbesprechung
2007/08
ALFSA
Termin
Ort
2008-05-07 12:10
HTBLuVA St. Pölten / W016
Teilnehmer
DI Wolfgang ALFERY
Andreas BRANDSTÄTTER
Christoph KLAFFL
Bericht
Klaffl, Brandstätter
Vorführung
• Präsentation des End-Projektstandes
• Client-Server Synchronisation
• Server-Server Synchronisation
• Fehlerbehandlung bei Ausfall eines Server
• Server-Oberfläche
Brandstätter Andreas, Klaffl Christoph
Seite 21von 231
ALFSA
1.6
KAPITEL 1. PROJEKTMANAGEMENT
Besprechungsnotizen
1. Besprechungsnotiz
ALFSA
Termin
Ort
2008-01-26 von 15:30 bis 17:15
Feuerwehrhaus der Feuerwehr Tulln
Teilnehmer
Ofner Johannes
Brandstätter Christian
Brandstätter Andreas
Inhalte
Allgemeine Abstimmung des aktuellen Projektstandes und Abstimmung der weiteren Entwicklung.
•
•
•
Demonstration der Client Oberfläche
Besprechung von geplanten Änderungen
Besprechung der weiteren Vorgangsweise
geplante Änderungen
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Mängel nicht unterscheiden (alle Mängel wie erhebliche Mängel eintragen)
Bei Füllen von Flaschen mit Mängel zusätzlicher Button zum „nicht füllen“
Bei Fremdflaschen nur Eigentümer und Anzahl, keine Nummern vergeben
Betriebsstundenzähler ist zwingend
Barcode-Feld mitlaufend mit up/down Buttons
Up/down Buttons mit Bilder oder deutsch beschriften
Datumfelder automatisch umformatieren (Javascript)
Datum nach „d.m.Y H:i“ formatieren
Nach Barcode-Feld verlassen wieder rein springen, wenn Focus kein Eingabefeld
Berechtigungen deutsch anzeigen / Symbole
Jeder soll synchronisieren dürfen (trotzdem eigene Berechtigung)
nur 3 Dringlichkeitsstufen
Hinweis, dass synchronisiert werden soll, nach Anmeldung (wie
Nachrichtenhinweis)
„extended logon form“ deutsch schreiben
Nachrichtenempfänger erweitern (siehe weitere Notizen)
Füllstellendetails: Stationierungsfeuerwehr, freie Füllstellen-Nummer
Kompressordetails: mobil [ja/nein]
ntpdate anderer Server verwenden (Pool) bzw. verbessern
Masken und Geräte nicht einbauen
weitere Vorgangsweise
•
•
•
Client-Änderungen implementieren
Server wie geplant weiter entwickeln
Demonstration bei Bezirkskommando sowie Bezirks- und Abschnittssachbearbeitern
Brandstätter Andreas, Klaffl Christoph
Seite 22von 231
ALFSA
KAPITEL 1. PROJEKTMANAGEMENT
2. Besprechungsnotiz
ALFSA
Termin
Ort
2008-03-29 von 13:00 bis 14:45
Feuerwehrhaus der Feuerwehr St. Andrä Wördern
Teilnehmer
Ofner Johannes (Projektleiter)
Brandstätter Christian (Technischer Berater)
Brandstäter Andreas (Entwickler)
Klaffl Christoph (Entwickler)
Kudrna Norbert (Abschnittssachbearbeiter Tulln)
Hagl Georg (Stellvertreter des Leiters des Verwaltungsdienstes Tulln)
Thallauer Josef (Bezirksfeuerwehrkommandant Tulln)
Sulzer Karl (Abschnittskommandant-Stellvertreter Tulln)
Schneider Friedrich (Abschnittskommandant Kirchberg)
Mann Josef (Abschnittssachbearbeiter Kirchberg)
Quixtner Franz (Abschnittssachbearbeiter Atzenbrugg)
Inhalte
Demonstration aktuellen Projektstandes und allgemein Information über das System.
•
•
einführende Präsentation (Ofner)
technische Präsentation ALFSA/aaron (Brandstätter)
•
•
Präsentation: Verbindunsstruktur, Datenstruktur, Bedienung (Klaffl)
Demonstration des Programms: Einsatz schnellstart, Flaschendaten anzeigen, usw.
(Brandstätter, Klaffl)
Information über: Kosten, Füllstellen-Laptop, Server-Infrastruktur (Ofner)
Atemschutzausschuss (Stöhr), nicht in FDISK integrieren (Thallauer)
in der übernächsten Atemschutzausschusssitzung ist eine Präsentation erwünscht
Diskussion
Anlegen von Test-Logins (Brandstätter, Klaffl)
•
•
•
•
Diskussionspunkte
•
•
•
einfachere Startseite für Füllberechtigten
serverseitig Masken und Geräte erfassen
Mängel mit größerer Warnung
Brandstätter Andreas, Klaffl Christoph
Seite 23von 231
ALFSA
1.7
KAPITEL 1. PROJEKTMANAGEMENT
Kontakte
Bei Support- oder sonstigen Anfragen wenden Sie sich bitte an folgende Personen:
1.7.1
Entwicklerteam
• Andreas Brandstätter
Gerersdorferstraße 17
3443 Sieghartskirchen
+43 (664) 9246242
[email protected]
• Christoph Klaffl
Birkenweg 5
3550 Langenlois
+43 (664) 4332791
[email protected]
Weiters sind die Entwickler unter [email protected]“ erreichbar.
”
1.7.2
Betreuer
• Prof. Dipl. Ing. Wolfgang Alfery
Waldstrasse 3
3100 St.Pölten
+43 (2742) 75051-421
[email protected]
• Prof. Dipl. Ing. Gerd Riesenhuber
Waldstrasse 3
3100 St.Pölten
+43 (2742) 75051-421
[email protected]
Brandstätter Andreas, Klaffl Christoph
Seite 24von 231
ALFSA
1.7.3
KAPITEL 1. PROJEKTMANAGEMENT
Auftraggeber
Abbildung 1.3: Korpsabzeichen der Feuerwehren in Österreich
• Bezirksfeuerwehrkommando Tulln
Hauptstrasse 23
3434 Tulbing
+43 (2272) 62222
[email protected]
• Kontaktperson:
Johannes Offner
Jakob Schefzikgasse 37/3/11
3430 Tulln an der Donau
+43 (664) 5334541
[email protected]
Brandstätter Andreas, Klaffl Christoph
Seite 25von 231
ALFSA
Teil II
Projektentwicklung
Brandstätter Andreas, Klaffl Christoph
Seite 26von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Kapitel 2
Verwendete Technologien
2.1
2.1.1
SSH
Allgemeines
SSH (Secure Shell) ist ein Netzwerkprotokoll sowie auch ein entsprechendes Programm, mit
dem verschlüsselte und sichere Verbindungen zu entfernen Computern aufgebaut werden
können. Am häufigsten wird es benutzt ein entferntes Terminal lokal zu verwenden, dabei
werde die Ausgaben der entfernten Konsole an die lokale gesendet und die Tastenschläge der
lokalen an die entfernte.
• Versionen: SSH-1, SSH-2, SSH 3G
• Standard Port: 22
2.1.2
Verwendung
SSH ermöglicht es eine sichere, authentifizierte und verschlüsselte Verbindung zwischen zwei
Computern über ein unsicheres Netzwerk (z.B.: Internet) herzustellen. Es ist somit ein Ersatz
für die Vorgänger telnet, rlogin und rsh, die keine Methoden zur Verschlüsselung bereitstellen. Bei diesen wird jeglicher Netzverkehr ungesichert übertragen (auch Passwörter sind in
Klartext lesbar!). Die Ursprüngliche Zweck von SSH ist das Anmelden an entfernte Recher
über ein Netzwerk. Aber vorallem mit der SSH-2 Version beschränkt sich SSH nicht mehr auf
reine Terminalfunktionen:
• SFTP, SCP: Sind verschlüsselte Alternativen zu FTP (File Transfer Protocol) und
RCP (Remote Copy). Somit ist es möglich Dateien auszutauschen ohne das sie ein
Dritter einsehen kann.
Brandstätter Andreas, Klaffl Christoph
Seite 27von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
• Portweiterleitung: Es ist möglich beliebige TCP/IP Verbindungen zu tunnneln. So
kann ein lokaler, beliebiger Port (z.B.: 3000) an den entfernten Rechner weitergeleitet
werden, dabei ist es möglich das sich die Portnummern unterscheiden, also das gleichzeitig auch eine Portumsetzung stattfindet. Dieser Vorgang funktioniert auch umgekehrt,
sodass auch Ports vom entfernten Server and den lokalen Rechner weitergeleitet werden
können. Die Anwedungsgebiete für diese Funktion sind somit weit verteilt. So kann z.B.
eine unverschlüsselte und somit unsichere VNC (Virtual Network Computing) Sitzung
durch einen SSH Tunnel aufgebaut werden, sodass diese von der Verschlüsselung der
SSH Vebindung profitiert.
• SSHFS: Mit dieser Funktion ist es möglich ein entferntes Dateisystem lokal zu mounten
bzw. verwenden. Es ist somit möglich direkt auf den Speicher eines entfernten Rechners
zugreifen, als wäre es eine lokaler Speicher.
• Authorized Keys: Es ist möglich anderen Benutzer zu gestatten, das sie sich ohne Tastatureingaben (also ohne Passworteinagbe) auf den Rechner anmleden können.
Dazu wird der öffentliche Schlüssel des SSH Clients am SSH Server eingetragen. Anwendungsgebiete sind zum Beispiel Kommandoausführungen die am Client eingegeben
werden und sofort am SSH Server ausgeführt werden (Somit wird eine SSH Sitzun aufgebaut, der Befehl ausgeführt und danach wird die Sitzung gleich wieder beendet)
• Komprimierung: Es ist möglich die SSH Verbindung zusätzlich zu komprimieren um
Bandbreite zu sparen. Dies ist für langsame Verbindungen und schnelle Rechner sehr
ratsam, da dadurch eine deutliche Steigerung der Datenrate möglich ist. Auf langsamen
Rechnern bzw. bei sehr schnellen Verbindungen führt die Kompression allerdings eher
zu Verzögerungen.
2.1.3
Sicherheit
Die Sicherheit von SSH wird durch veschiedenen Methoden der Verschlüsselung und Authentifizierung erreicht:
• Authentifizierung: Beim Anmelden an einen SSH Server identifiziert sich der Sever
gegenüber dem Client mit seinem RSA-Zertifikat. Durch diese Methode kann der Client erkennen ob jemand den Server ausgetauscht hat bzw. wenn sich ein andere Server
meldet (zum Beispiel durch DNS Spoofing oder ARP Spoofing). Der SSH Client meldet
sich nach dem Sicherstellen der Gültigkeit des SSH Servers entweder mit seinem öffenltichen Schlüssel an (wobei dieser beim Server bekannt gegeben werden muss; sogennante
Public-Key-Authentifizierung) oder einem Passwort, das der Benutzer eingeben muss.
• Verschlüsselung: Nach dem die Authentifizierung erfolgreich war, wird für die SSH
Sitzung ein geheimer Schlüssel erzeugt der für die gesamte Zeitdauer der SSH Sitzung
zur Verschlüsselung verwendet wird. Der verwendete Verschlüsselungsalgorithmus hängt
dabei von der Protokollversion ab (SSH-2 verwendet standardmäßig AES mit einer
Schlüssellänge von 128Bit). Es sind folgende Verschlüsselungverfahren verfügbar: 3DES,
Brandstätter Andreas, Klaffl Christoph
Seite 28von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Blowfish, Twofish, CAST, IDEA, Arcfour, SEED und AES mit anderen Schlüssellängen.
Zusätzlich unterstützt die neue Generation von SSH (SSH G3) auch den proprietären
Snakeoil-Algorithmus CryptiCore, der einen Geschwindigkeitsgewinn brigen soll. (Cryptoexperten bezeichnen ihn als Security-through-obscurity-Algorithmus 1 )
• Schwachstellen: Die Integritätsprüfung von SSH-1 zeigt Schwachstellen, die es Dritten
erlaubt eine SSH-1 Sitzung auszuspähen. Daher sollte diese Version nicht mehr vewendet
werden und die nächst höhere SSH-2 Version ist zu bevorzugen (inkompatibel zu SSH-1).
Diese unterstützt verschiedene Verschlüsselungalgorithmen und ist modular im Hinblick
auf Transport-, Autorisierungs- und Verbindungsschichten aufgebaut.
2.1.4
Implementierungen
Ursprünglich waren SSH Implementierungen nur für UNIX Systeme vorhanden. Mittlerweile
wurden viele SSH Server und SSH Clients für andere Systeme entwickelt. Am beliebtesten ist
der OpenSSH Server, der eine freie Realisierung von SSH darstellt und mittlerweile einen sehr
großen Verbreitungsgrad erreicht hat. Da Sicherheitsexperten freie Software bevorzugen (da
nicht nur die verwendeten Algorithmen entscheidend für die Sicherheit sind, sondern auch ihre
Implementierung) wird sich dieser vorraussichtlich noch vergößern. Über Cygwin ist es auch
möglich den OpenSSH Server unter Windows Systemen zu betreiben, jedoch ist die WindowsShell nur sehr begrenzt zur Administration des Systems geeignet. Es existieren noch andere
SSH Server, wie zum Beispiel dropbear, der für seine niedrigen Ressourcenverbrauch bekannt
ist und sich deshalb sehr für embedded-Systeme eignet. Beliebte SSH Clients sind zum Beispiel
PuTTY (Windows und Linux) und WinSCP (nur Windows).
2.2
2.2.1
APACHE Webserver
Allgemeines
Der Apache HTTP Server ist der meistbenutze Webserver [1] im Internet. Er wird von der
Apache Software Foundation entwickelt, die aus zahlreichen Open Source Entwicklern besteht
und Open Source Produkte unterstützt. Er wurde aus Respekt nach den nordamerikanischen
Indianerstamm der Apachen benannt.
2.2.2
Aufbau
Der Webserver ist modular aufgebaut. Dadurch kann der Webserver mit zahlreichen Modulen in seiner Funktion erweitert werden, um beispielsweise mittels des Moduls mod ssl“
”
1
als Security-through-obscurity bezeichnet man in der Sicherheitstechnik den Versuch Sicherheit durch die
Geheimhaltung des Algorithmus zu erreichen
Brandstätter Andreas, Klaffl Christoph
Seite 29von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
die gesamte Kommunikation zum Browser zu verschlüsseln. Desweiteren bietet Apache die
Möglichkeit serversetige Skriptsprachen zu verarbeiten um so dynmaisch generierte Webseiten zur Verfügung zu stellen. Die Skriptsprachen sind jedoch nicht Bestandteil des Webservers
sondern werden entweder über ein Modul eingebunden oder über CGI (Common Gateway Interface) aufgerufen. Wobei letztere Art der Implementierung langsamer ist, da für jede Anfrage
an den Webserver ein Interpreter gestartet werden muss. Die Hauptmodule des Webservers
bilden die MPMs (Multiprocessing-Module). Sie sind ausschlaggebend dafür, wie der Server
mehrere Client-Anfragen verarbeitet. So gibt es für Multi Prozessor Systeme ein spezielles
Modul, das die Anfragen, soweit möglich, auf die CPU Kerne verteilt.
2.2.3
Implementierungen
Der Apache HTTP Server läuft auf allen gängigen Betriebsystemen, von AmigaOS über verschiedene Unix/Linux Deriviate bis hin zu Windows Systemen. Derzeit werden die stabilen
Versionen 1.3.x, 2.0.x und 2.2.x weiterhin mit Sicherheitsupdates gepflegt und letztere auch
weiterentwickelt. Daher empfielt es sich die letzte stabile Version einzusetzen, die während
des Schreibens dieses Dokumentes die Versionsnummer 2.2.8 trägt.
2.2.4
Homepage
Weitere Informationen können über die Hautptseite des Apache HTTP Servers bezogen werden:
http://httpd.apache.org/
2.3
2.3.1
Datenbanksystem
Allgemeines
Ein Datenbanksystem, abgekürzt DBS“, ist ein System zur elektronischen Datenverwaltung.
”
Es habet die Aufgabe große Datenmengen wirksam und dauerhaft zu speichern. Desweiteren muss das Datenbanksystem die Konsistenz der Daten garantieren und die gespeicherten
Informationen für Anwendungsprogramme bereistellen.
Das Datenbanksystem besteht aus 2 Teilen:
• Verwaltungssoftware/Datenbankmanagementsystem (DBMS): Die Verwaltungssoftware steuert und kontrolliert jeglichen Zugriff auf die Datenbank. Sie speichert die
Daten anhand eines Datenbankmodells (z.B. relationales Datenbankmodell). Für die
Brandstätter Andreas, Klaffl Christoph
Seite 30von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Bereitstellung der Informationen stellt sie externe Schnittstellen zur Verfügung. Die
Datenbankanfragen müssen entsprechend der jeweiligen Datenbanksprache des Datenbankmanagementsystem zusammengestellt werden um Operationen wie das Einfügen,
Ändern oder Abfragen der Daten zu ermöglichen. Die meisten der aktuell verfügbaren
Datenbanksysteme implementieren den SQL Standard, der im weiteren Verlauf der Dokumentation noch erläutert wird. Das DBMS ist somit entscheidend für die Geschwindigkeit und Funktionalität des Systems und die Auswahl eines solchen sollte daher sehr
gründlich erfolgen.
• Datenbank (DB): Die Datenbank enthält die Daten und Informationen die gespeichert
wurden. Desweiteren besitzt sie zusätzlich zu den gespeicherten Informationen einen
sogennanten Datenkatalog. Er enthält Metadaten zur Beschreibung des Aufbaus und
der Darstellung der enthaltenen Daten. Desweiteren beschreibt er auch die Beziehungen
zwischen den Datenbankelementen. Der direkte Zugriff auf die Datenbank ist nur für
administrative Operationen, wie zum Beispiel die Durchführung eines Backups, erlaubt.
Alle anderen Zugriffe werden durch das DBMS verwaltet.
2.3.2
Anforderungen
Damit sich ein Datenbanksystem auch wirklich als solches klassifizieren kann, muss es im
Gegensatz zur herkömmlichen Datenverarbeitung folgende Anforderungen erfüllen:
Strukturierung und Integrität
• Das DBS muss durch eine zentrale Struktur die Redundanz von Daten vermeiden
• Es soll die Verwaltung von strukturierten Daten ermöglichen
• Die logische Trennung von Anwendungsprogramm und Datenspeicher soll möglich sein
• Regeln zur Gewährleistung der Datenintegrität sollen bereitstehen und überwacht werden
Sprachen
Das Datenbanksystem stellt eine Datenbanksprache für folgende Aufgabenbereiche bereit:
• Datenabfrage und -manipulation (DML)
• Verwaltung der Datenbank und Definition der Datenstrukturen (DDL)
• Berechtigungssteuerung (DCL)
Brandstätter Andreas, Klaffl Christoph
Seite 31von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Diese Operationen können in einer Sprache kombiniert werden (zum Beispiel SQL). Sie können
aber auchauf unterschiedliche Sprachen aufgeteilt sein.
Mehrbenutzerfähigkeit
Ein Berechtigungssystem sorgt dafür, das nur berechtigte Benutzer die gewünschten Informationen einsehen dürfen. Desweiteren stellt das DBS sogenannte locks“ bereit und verwaltet
”
diese, um Datenelemente exklusiv für die eigenen Maniplutaionen zu sperren. Darüberhinaus
arbeitet das DBS transaktionsorientiert. Darunter versteht man den Vorgang mehrere Anfragen zu einer logischen Einheit zusammenzufassen, damit man sicher gehen kann, dass bei
einem Fehler in einem Statement keine der Anfrage durchgeführt wird, sondern stattdessen
die Daten im alten Zustand erhalten bleiben. Wichtige Vorgänge werden dabei protokolliert
und in Log Dateien gespeichert.
Betrieb
Für den einwandfreien Betrieb werden folgende Punkte vorausgesetzt:
• Große Datenmengen dürfen die Geschwindigkeit des Datenbanksystems nicht signifikant
verschlechtern
• Ermöglicht Datenbackups und Datenwiederherstellung zur Laufzeit
• Daten können im- und exportiert werden
• Kann mit anderen Datenbanksystemen zusammenarbeiten (verteilte Datenbanksysteme)
2.3.3
Wartung
Die Wartung wird von Datenbank-Administratoren (DBA) übernommen und wird vollständig
über die Verwendung der bereitgestellten Datenbanksprache ausgeführt.
2.4
2.4.1
MySQL
Allgemeines
MySQL ist ein freies und relationales Datenbankverwaltungssystem der schwedischen Firma
MySQL AB. Es steht sowohl unter der freien Lizenz GPL als auch unter einer kommerziellen Lizenz zur Verfügung (Duale Lizenz). Der Name setzt sich aus My“, dem Namen der
”
Brandstätter Andreas, Klaffl Christoph
Seite 32von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Tochter des Mitbegründers Monty Widenius, und SQL“, der Datenbanksprache die für die
”
Verwaltung und Abfragen verwendet wird, zusammen. MySQL ist das am weitest verbreitete Open Source Datenbanksystem mit ca. 6 Millionen Installtaionen. Es wird vorwiegend
für Webauftritte verwendet und daher auch gernen mit anderer Open Source Software wie
dem Apache HTTP Webserver und PHP eingesetzt. Desweiteren wird es mit zahlereichen
Produkten mitgeliefert. Vorallem die performante Arbeitsweise macht das System auch für
den Businessbereich interessant. Im Jänner 2008 wurde MySQL AB von SUN Microsystems
gekauft, an der Offenheit des Systems wird sich nach Informationen von SUN aber nichts
ändern.
2.4.2
Aufbau
MySQL wurde 1994 als Fork 2 von mSQL entwickelt und der überwiegende Teil des Codes ist in ANSI C/C++ programmiert. Schon am Anfang der Entwicklung wurde MySQL
für große Datenmenge und Schnelligkeit ausgelegt, teilweise unter Verlust von Stabilität und
Verfügbarkeit. Seit der Version 3.23 besitzt MySQL die Tabellenegine InnoDB“, die den An”
foderungen eines Datenbanksystems entspricht. Trotzdem wird standardmäßig die MyISAM“
”
Engine verwendet, die vor allem in Sachen Perfomace punkten kann, dafür aber nicht transaktionsicher ist und keine locks“ verwendet. Mit der Entwicklung des MySQL Clusters wurde
”
eine neue Tabellenengine eingeführt, bei der die gesamten Daten im Arbeitspeicher gehalten
werden aber keine Beziehungen untersützt. Dadurch ist eine syncrone Replikation der Daten
zwischen den Cluster-Rechnern möglich. Die nächsten Versionen brachten Unterstützung für
Unions, Query Cache, Unicode und Subqueries. Desweiteren implementierte die Versionsreihe 5 den SQL Standard in der Version 3 fast vollständig und unterstützt nun somit: Views,
Triggers, Stored Procedure und User Defined Functions.
2.4.3
Administration
Die Administration wird vollständig über SQL Befehle bewerkstelligt. Dies kann zum Beispiel
durch den mitgelieferten MySQL Kommandozeilenclient erfolgen. Jedoch ist es komfortabler
die MySQL GUI Tools zu verwenden, die direkt von MySQL angeboten werden.
2.4.4
Implemetierung
MySQL ist unter den gängigsten Betriebsystemen wie Windows und Linux lauffähig. Die
aktuelle stabile Version während der Ausführung dieser Diplomarbeit ist 5.0.51.
2
Fork (...) ist in der Softwareentwicklung ein (Neben-) Entwicklungszweig nach der Aufspaltung eines
”
Projektes in zwei oder mehr Folgeprojekte, wobei Teile des Quellcodes kopiert werden und dann unabhängig
von dem ursprünglichen Projekt weiterentwickelt werden.“ [22]
Brandstätter Andreas, Klaffl Christoph
Seite 33von 231
ALFSA
2.5
2.5.1
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Linux
Allgemeines
Linux ist ein freies Multibenutzer Betriebssystem das nach dem Gründer Linus Torvalds benannt wurde. Es entspricht den POSIX Richtlinien 3 und ähnelt sehr einem UNIX System.
Linux war ursprünglich ein Terminal-Emulator, da es eher in die Richtung eine Betriebsystems
tendierte wurde es von Linus Torvalds fortan als solches entwickelt. Am Anfang der Entwicklung war es als kleines Betriebssystem gedacht, aber durch die Offenheit des Quellcodes und
des ganzen Systems, beteiligte sich eine große Masse an Entwicklern an den Programmierarbeiten. Dieser Umstand führte dazu, dass Linux heute eines der technisch fortschrittlichsten
Betriebsysteme ist. Zum Beispiel ist Linux dem Windows-System von Microsoft in vielen
Bereichen, wie etwa Echtzeitfähigkeit voraus [7] [8].
2.5.2
Was ist Linux?
Mit dem Begriff Linux“ bezeichnet man den Kernel. Er ist der wichtigste Bestandteil ei”
nes Betriebsystems und ist für die Interaktion zu den Hardware- und Softwareschnittstellen
zuständig. Er verwaltet also unter anderem folgenede Aufgaben:
• Die Zuteilung von Prozessorzeit und sonstige Ressourcen an die Programme
• Kontrolliert den Zugriff auf Geräte, Speicher jeglicher Art, den Porzessoren
• Einhaltung der Zugriffsrechte auf Speicher und Geräte
• Gliederung der Ressourcen (Netzwerkstack für Netzwerkkarten, Dateisystem für Speichermedien)
• Bereitstellung der Ressourcen (Netzwerk: Sockets, Festplatte: Dateien, Geräte: Spezialdateien, ...)
Für ein vollständiges Betriebsystem benötigt man daher zusätzliche Software, welche zum
Beispiel die Grafik Ausgabe übernimmt.
2.5.3
Weitere Entwicklung
Die Weiterentwicklung von Linux wird von Firmen, Einzelpesonen, Non-Profit-Unternehmen,
uvm. sichergestellt. Wie bereits erwähnt ist der Source-Code von Linux frei verfügbar und
3
Das Portable Operating System Interface (POSIX) ist ein (...) standardisiertes Application Programming
”
Interface, das die Schnittstelle zwischen Applikation und dem Betriebssystem darstellt.“ [23]
Brandstätter Andreas, Klaffl Christoph
Seite 34von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
jeder kann sich an den Arbeiten daran beteiligen. Zum Beispiel stellt auch die Firma Google
Programmierer bereit um Linux wieter zu programmieren.
2.5.4
Verbreitung
Linux erfährt nur eine geringe Nutzung als Desktop Betriebsystem. Dies hat mehrere Gründe:
• Mangelnde Benutzerfreundlichkeit: Dieses Argument schwindet in letzter Zeit, da
aktuelle Linux Distributionen, wie bespielsweise Ubuntu, sehr einsteigerfreundlich sind
und auch zahlreiche grafische Tools bieten um das System zu konfigurieren.
• Mangelnde Hardwareunterstützung: Hersteller liefern Geräte in meisten Fällen nur
mit Treibern für Windows Betriebssysteme. Gerätetreiber für solche Hardware werden
daher von Dritten programmiert, wobei hier das Problem besteht, dass sie die genaue
Funktionsweise des Geräts nicht kennen, da Hardware-Hersteller diese geheim halten.
Durch diesen Umstand wurden viele Treiber nur durch Reverse-Engineering entwickelt.
Bei Server-Hardware bestehen allerdings viel weniger Probleme, da in diesem Bereich
Linux und demensprechend auch Treiber dafür gefragt sehr gefragt sind. Es muss jedoch angemerkt werden, dass Linux zum aktuellen Zeitpunkt mehr Geräte als andere
Betriebsysteme unterstützt [9]. Weiters sei erwähnt, dass die Zukunft bessere Hardwareunterstützung durch standardisierte Treiber [9] verspricht.
• Fehlende Programme: Vielen Nutzern, die gerne umsteigen würden, fehlt es an Software die unter anderen anderen Betriebsystemen verfügbar war, aber nicht unter Linux.
Dies betrifft vorallem Spezialsoftware wie Video- oder Musikbearbeitungsprogramme.
Es besteht aber auch die Möglichkeit Windows-Programme unter Linux auszuführen.
Abhängig von der Komplexität der jeweiligen Anwendungen kann es dabei aber zu Problemen kommen.
• Unwissenheit: Die meisten technisch unerfahrenen Anwender wissen jedoch nicht, dass
es neben Windows auch freie Alternativen gibt und es fehlt ihnen somit an grundlegendem Coumputerwissen.
In anderen Bereichen erfreut sich Linux jedoch großer Beliebheit:
• Server: Linux hat sich als ein sehr verlässliches, sicheres und vorallem als leicht wartbares Server System herausgestellt und wird daher vorallem in diesem Bereich verwendet.
• Supercomputer: Linux bietet eine gute Skalierbarkeit, Prozessverwaltung und läuft
auf vielen Architekturen. Dadurch kann das Potential von Supercomputern durch Linux
sehr gut ausgereizt werden.
• Emebedded Systeme: Da ein Linux System sehr ressourcenschonend ist und für jegliche Einsatzzwecke angepasst werden kann eignet es sich hevorragend für emebedded
Brandstätter Andreas, Klaffl Christoph
Seite 35von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Systeme. So kommt es vor, dass viele Endnutzer Linux benutzen ohne es zu wissen, da
in viele Routern, Handys, Festplattenvideorekordern, ... ein angepasstes Linux System
läuft.
2.5.5
Distribution
Linux wird über die Webseite http://kernel.org/ vertrieben. Es stehen dort sowohl die neu”
”
en Versionen als auch die alten als Quellcode zur Verfügung. Allerdings ist dies wie bereits
erwähnt nur der Kernel der noch übersetzt bzw. kompiliert werden muss. Daher greift der
Großteil zu sogenannten Distributionen, die zusätzlich zum kompilierten Kernel noch zusätzliche Software-Pakete mitliefern. Sie enthalten bereits die meiste Software die ein Betriebssystem benötigt und mit welcher der Benutzer auch gewöhnliche Arbeiten, wie das Surfen im
Internet oder die Bearbeitung von Dokumenten, ausführen kann. Abhängig von der gewählten
Distribution sind alle bzw. fast alle mitgelieferten Programme frei in der Benutzung und auch
Open Source. Einige bekannte Distributionen sind:
• Debian (http://www.debian.org/)
• Ubuntu (http://www.ubuntu.com/)
• openSuSE (http://www.opensuse.org/)
• Fedora (http://www.fedoraproject.org/)
• Sidux (http://www.sidux.org/)
2.6
Subversion
2.6.1
Allgemeines
SVN (Subversion) ist ein freies Versionsverwaltungssystem für Dateien und Verzeichnisse,
speziell für die Entwicklung von OpenSource Software. Bei solchen Projekten arbeiten sehr
viele Entwickler, die häufig rund um den Globus verteilt sind. Somit sind sie auf ein effizientes
Versionsveraltungsystem angewiesen, welches die Zusammenarbeit ermöglicht. Ein Projekt
bzw. eine Gruppe von Dateien wird als sogenanntes Repository am Server angelegt.
2.6.2
Funktionsweise
Für SVN wird ein SVN Server benötigt, der die gesamten Daten verwaltet und Änderungen
der Benutzer entgegennimmt und verarbeitet. Bevor der Benutzer/Programmierer mit der
Brandstätter Andreas, Klaffl Christoph
Seite 36von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Arbeit beginnt, lädt er sich die neue Version der Programmdateien herunter (update) und
nach Beendigung der Programmierung überträgt er die neue geänderte Version an den SVN
Server zurück (check in)
Die Lösungswege für Konflikte bei SVN erklären sich anhand des folgenden Beispieles:
Abbildung 2.1: Das Filesharing Problem [2]
Harry und Sally laden sich beide die aktuellste Version der Dateien und Verzeichnisse herunter. Sie arbeiten beide an der selben Zeit und beide checken diese Dateien zu unterschiedlichen
Zeiten ein. Somit ensteht ein Konflikt, um diesen zu vermeiden werden von Subversion sogenannte locks“ unterstützt:
”
Brandstätter Andreas, Klaffl Christoph
Seite 37von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Abbildung 2.2: Das Lock-Modify-Unlock Model [2]
Bei diese Methoden ist das gleichzeitige Bearbeiten der Dateien unmöglich. Harry holt sich
die aktuellste Version und sperrt die Datei die er bearbeitet. Sally will die Datei nun auch
bearbeiten und lädt sich wiederum die neuste Version herunter und will die Datei sperren.
Doch dieser Vorgang schägt fehl und der SVN Server meldet, dass bereits ein andere Entwickler ein lock“ auf diese Datei gesetzt hast, somit kann Sally die Datei nur lesen aber nicht
”
bearbeiten. Wenn Harry seine Arbeiten beendet hat, lädt er die neue Datei hoch und gibt sie
wieder frei. Somit kann jetzt Sally einen lock“ beantragen und die Datei bearbeiten.
”
Das dieses Verfahren wesentliche Nachteile mit sich bringt liegt auf er Hand. Es kann jeweils
nur ein Entwickler an einer Datei arbeiten. Daher gibt es ein weiteres Verfahren, dass nach
dem Copy-Modify-Merge Modell“ arbeitet:
”
Brandstätter Andreas, Klaffl Christoph
Seite 38von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Abbildung 2.3: Das Copy-Modify-Merge Model [2]
Beide bearbeiten die gleiche Datei. Nachdem Sally mit ihren Arbeiten fertig ist veröffentlicht
sie ihre Version. Wenn Harry seine Version einchecken will bekommt er vom SVN Server einen
sogenannten out-of-date error“. Dieser signalisiert Harry, dass ein anderer Entwickler auch
”
Änderungen durchgeführt hat. Er lädt sich nun diese Version herunter und muss sie mit seiner
Version vergleichen und zusammenführen. Nachdem er die beiden Versionen zusammengeführt
hat, kann er diese auf den SVN Server hochladen. Somit sind die Änderungen von Beiden im
SVN.
Die drei wichtigsten Methoden für die Verwendung von SVN sind:
• Check Out: Beim erstmaligen herunterladen eines Repositories
• Check In: Um Änderungen im Repository zu übernehmen
• Update: Neueste Version des Repositories wird heruntergeladen
2.6.3
Implemetierung
Es gibt zahlreiche freie SVN Clients und SVN Server für die meisten Betriebssysteme (AIX,
Linux, Windows, Mac OS X, *BSD, Solaris, OS/400).
Brandstätter Andreas, Klaffl Christoph
Seite 39von 231
ALFSA
2.7
KAPITEL 2. VERWENDETE TECHNOLOGIEN
SSL
2.7.1
Allgemeines
SSL ist die Abkürzung für Secure Sockets Layer“ wird aber unter den Namen Transport Layer
”
Security (TLS) weiterentwickelt. Im folgenden wird für beide Bezeichnungen die Abkürzung
SSL verwendet. SSL dient zur Verschlüsselung der Datenübertragung über das Internet. Es
wurde entwickelt um wichtige Daten, die über das Internet übertragen werde, vor Dritten und
vor Manipulationen zu schützen. Dazu bietet SSL verschiedene Verfahren zur Authentifizierung und Verschlüsselung.
2.7.2
Funktionsweise
Mit SSL lassen sich verschiedenste Protokolle (HTTP, FTP, ...), die selber keine Methoden
zur Verschlüsselung bieten, absichern. Im OSI-Modell 4 befindet sie sich somit zwischen Anwendungsschicht und Transportschicht.
Das SSL Protokoll ist in 2 Schichten aufgeteilt:
• SSL Handshake Protocol: Baut auf den SSL Record Protocol (siehe nächsten Punkt)
auf und wird vor dem eigentlichen Datentransfer ausgeführt. Es übernimmt die folgenen
Aufgaben:
– Identifikation und Authentifizierung: Diese Funktion ist optional und wird
zur Verschlüsselung der Datenübertragung nicht benötigt. Sie dient lediglich zur
Verifizierung der Identitäten von Server und Client über asymetrische Verschlüsselungalgorithmen.
– Auswahl der verwendeten Algorithmen: Durch diesen Vorgang werden die
zu verwendete Schlüssel und Algorithmen ausgehandelt.
Der Vorgang des Handshakes lässt sich in vier Phasen einteilen:
– Phase 1: Der Client schickt eine Anfrage an den Server und der Server antwortet
dem Client. Die Inhalte der Nachrichten sind die höchste Version des SSL Protokolls, die der Client unterstützt, eine 32 Bit lange Zufallszahl für die spätere
Verschlüsselung, eine Session ID und den zu verwendeten Verschlüsselungsalgorithmus.
– Phase 2: [optional] Der Server schickt zur Identifikation seiner Identität sein Serverzertifikat an den Client. Dieser kann sich dann die Echtheit des Zertifikats durch
eine Zertifizierungstelle überprüfen und bei Verdacht auf einen Betrugsversuch die
4
Das OSI-7-Schichtenmodell oder OSI-Referenzmodell beschreibt das Durchlaufen von 7 Schichten in de”
nen Funktionen und Protokolle definiert sind und einer bestimmten Aufgabe bei der Kommunikation zwischen
zwei Systemen zugeordnet sind.“ [24]
Brandstätter Andreas, Klaffl Christoph
Seite 40von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Übertragung zu dem Server verweigern. Der Server kann in dieser Phase auch einen
Zertifikatsantrag an den Client schicken, das heißt, dass der Client sich beim Server
identifiziert.
– Phase 3: [optional] In dieser Phase identifiziert sich der Client beim Server, indem
er sein Zertifikat sendet. Falls der Client kein Zertifikat besitzt teilt er diesen Umstand dem Server mit. Der Server kann das Zertifikat kontrollieren und feststellen
ob die Identität des Client stimmt. Hier kontrolliert auch der Client die Identität
des Servers mittels des zuvor empfangenen Zertifikats.
– Phase 4: Die letzte Phase schließt den Handshake Vorgang ab. Aus dem premaster-key wird durch 2 Hashfunktionen (SHA-1 und MD5) das Master Secret
durch Miteinbeziehung der 32 Bit langen Zufallszahl errechnet. Dieser einmalige
Schlüssel dient für die gesamte SSL Sitzung hinweg zur symetrischen Verschlüsselung der Datenübertragung.
• SSL Record Protocol: Bildet die untere Schicht der beiden SSL Schichten. Wird
für die Absicherung der Verbindung verwendet. Sie stellt 2 grundlegende Funktion zur
Verfügung, die unabhängig voneinader genutz werden können:
– Ende-zu-Ende-Verschlüsselung: Wird durch symetrische Verschlüsselungsalgorithmen realisiert. SSL unterstützt die folgenden Alogroithem zur Verschlüsselung:
DES, Triple DES und AES. Die benötigten Schlüssel werden dazu schon im Voraus
über das SSL Handshake Protocol ausgehandelt und gilt nur für eine Verbindung.
– Sicherung der Nachrichtenintegrität: Ihre Aufgabe ist es Sicherzustellen, dass
die Nachrichten ohne Fehler übertragen wurden. Dies wird durch verschiedene
Hash-Funktionen erreicht, wie zum Beipsiel SHA-1 und MD5
Ein einfacher SSL Sitzungaufbau sieht folgendermaßen aus:
Abbildung 2.4: SSL Sitzungsaufbau
• 1: Der Browser sendet eine Anfrage an den Webserver
Brandstätter Andreas, Klaffl Christoph
Seite 41von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
• 2: Der Webserver antwortet dem Client und teilt ihm mit, dass es sich um eine gesicherte Seite handelt und sendet den öffentlichen Schlüssel seines Zertifikates für die
asymetrische Verschlüsselung
• 3: Da es sich um einer sicher Seite handelt generiert der Browser eine Zufallszahl
• 4: Die Zufallszahl wird mit dem öffentlichen Schlüssel des Webservers verschlüsselt und
zurückgesendet
• 5: Der Webserver entschlüsselt die Nachricht mit seinem privaten Schlüssel und fängt
mit der fortlaufenden symetrischen Verschlüsselung der Verbindung an
• 6: Die gesamte Datenübertragung wird jetzt mit dem Zufallsschlüssel verschlüsselt
2.7.3
Verschlüsselungsverfahren
Symetrisch
Bei symetrischen Algorithmen werden die zu verschlüsselnden Daten mit einem geheimen
Schlüssel sowohl kodiert als auch dekodiert. Daher muss bei allen Beteiligten dafür gesorgt
werden das der Schlüssel geheim bleibt. Das größte Problem ist die Übermittlung des geheimen
Schlüssels an alle Teilnehmer. Deshalb wird in der Praxis die symetrische und asymetrische
Verschlüsselung kombiniert (siehe Hybrid-Verschlüsselung). Dadurch ist es möglich im Voraus
über das asymetrische Verfahren den geheimen Schlüssel für den verwendeten symetrischen
Algoritmus zu übertragen.
Der große Nachteil an symetrischen Verfahren ist daher das Verwenden des geheimen Schlüssels
für die Ver- und Entschlüsselung.
Asymetrisch
Bei asymetrischen Algorithmen werden zwei verschiedene Schlüssel zur Ver- und Entschlüsselung verwendet. Dieses Schlüsselpaar besteht aus einem öffentlichen Schlüssel, der von jedem
eingesehen werden kann, und einem privaten Schlüssel, den nur der Eigentümer kennen darf
und das eigentliche Geheimnis beinhaltet. Die Daten werden vom Sender mit dem öffentlichen
Schlüssel des Empfängers verschlüsselt und können dann nur noch mit dem privaten Schlüssel
des Empfängers entschlüsselt werden. Somit ist sichergestellt das nur der Empfänger die Nachricht entschlüsseln kann. Dadurch ist das System sehr sicher und wird bei Applikationen wie
SSH (Secure Shell) verwendet.
Asymetrische Verfahren beanspruchen deutlich mehr Rechenlesitung als symetrische Verfahren und arbeiten daher deutlich langsamer. In der Praxis werden daher hybride Verfahren
benutzt. Ein weiterer Nachteil besteht darin, dass die Sicherheit bei vielen asymetrischen
Brandstätter Andreas, Klaffl Christoph
Seite 42von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Verfahren nicht bewiesen ist sondern nur angenommen wird, dass die verwendeten mathematischen Einwegverfahren nur mit extrem hohen Rechenaufwand umgekehrt werden können.
Außerdem kann man durch einfaches“ probieren von Schlüsseln versuchen die mit dem öffent”
lichen Schlüssel verschlüsselten Daten zu entschlüsseln und somit auf den privaten Schlüssel
zu kommen. Jedoch würde man dafür sehr viel Rechenleistung aufbringen müssen.
Mittelsmann- oder Man-In-The-Middle-Attacken können durch die Verwendung von Prüfsummen (Nachrichtenintegrität) oder durch vertrauenswürdige Zertifizierungstellen verhindert
werden. Bei solchen Attacken steht der Angriffer in der Mitte der Datenübertragung. Beim
Aufbau der Verbindung sendet der Anfreifer seinen öffentlichen Schlüssel an den Client. Die
Antwort wird mit seinem privaten Schlüssel entschlüsselt und mit dem öffentlichen Schlüssel
des Zielservers wieder verschlüsselt und an diesem gesendet.
Hybrid
Die hybriden Verfahren kombinieren die asymetrischen mit den symetrischen Algorithmen.
Dabei wird der geheime Schlüssel für die symetrische Verschlüsselung durch das asymetrische
Verfahren übertragen. Danach läuft der gesamte Datenverkehr über das symetrische Verschlüsselungsverfahren ab. Somit benötigt der gesamte Vorgang nur beim Schlüsselaustausch
viel Rechenleistung, da bei der symetrischen Verschlüsselung die benötigte Rechenleistung
nicht so groß ist.
Hybride Verfahren kommen zum Beispiel bei SSL zum Einsatz.
2.7.4
Vorteile
Mit SSL jedes Protokoll, welches sich in der Anwendungsschicht befindet (POP3, HTTP,
FTP, SQL, ...), verschlüsselt werden ohne jegliche Unterstützung seitens des verwendeten
Protokolls.
Beispiel: Es existiert ein Netzwerk mit 5 Hosts die über einen Hub miteinander verbunden
sind. Ein Router der auch am Hub angeschlossen ist, ermöglicht den Zugang zum Internet. Ein
Benutzer ruft an einem Computer seine E-Mails ab, ist aber interessiert, dass der Inhalt nicht
für andere nicht lesbar ist (Durch den Hub können alle Netzwerkteilnehmer die übertargenen
Daten, wie in diesem Fall die E-Mails, mitlesen). Daher verwendet er eine verschlüsselte
POP3 Verbindung mit SSL. Somit können die anderen Netzwerkteilnehmer zwar noch immer
die übertragenen Daten sehen, können sie aber nicht lesen bzw. entschlüsseln da ihnen der
Schlüssel fehlt.
Brandstätter Andreas, Klaffl Christoph
Seite 43von 231
ALFSA
2.7.5
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Nachteile
Der größte Nachteil an SSL ist die Rechenzeit die am Server verbraucht wird. Diese ist beim
Verbindungsaufbau sehr hoch und lässt, je nachdem welcher Verschlüsselungsalgorithmus verwendet wird, nach wenn die Sitzung aufgebaut ist.
Ein weiterer Nachteil ist die Tatsache, dass sich die verschlüsselten Daten nicht mehr gut
komprimieren lassen und somit transparente Kompressionsmethoden nicht mehr funktionieren (zum Beispiel eine komprimierte VPN Verbindung), jedoch beinhaltet die neuren SSL
Spezifikationen Möglichkeiten zur Kompression, die jedoch aufgrund von Performanceverlusten in den meisten Fällen nicht verwendet werden.
2.7.6
Probleme
Die Verschlüsselung von HTTP hat im Zusammenhang mit dem Apache Webserver bzw. jedem anderen Webserver, der die gleiche Funktion unterstützt, Probleme. Es ist nicht möglich
einen verschlüsselten Virtual Host (VHost) über SSL an einen bestimmten Servernamen zu
binden, da der Servername erst durch das HTTP Prtotokoll gesendet wird und dieses zum
Zeitpunkt des SSL Sitzungsaufbaus noch keine Daten übertragen kann. Daher können Virtual
Hosts mit SSL nur mit IP/Port Kombinationen realisiert werden. Jedoch wurde in neueren
Spezifikationen (TLS 1.2) dieses Problem durch die Server Name Indication“ Funktion be”
hoben.
2.7.7
Implementierungen
Mit OpenSSL existiert eine freie Umsetzung des SSL Protokolls für die meisten aktuellen Betriebsysteme (Linux, Unix, Windows, Mac OS X). Sie unterstützt weitgehendst die meisten
Verschlüsselungs- und Authentifizierungsverfahren. Mit GnuTLS exisitiert eine weitere freie
Implementierung von SSL. Sie steht unter einer noch freieren“ Open Source Lizenz (BSD)
”
und darf somit mit eigenen Produkten vertrieben werden (zum Beispiel ist GnuTLS in GNOME, Exim oder Lynx vertreten), läuft allerdings nur auf Unix und Linux Systemen. Desweiteren unterstützt GnuTLS mehr Möglichkeiten zur Authentifizierung (SRP, x.509, OpenPGP),
darüber hinaus ist es auch mögliche den ganzen Datentransfer zusätzlich mittels zlib oder
LZO zu komprimieren.
Aktuelle Webbrowser, wie Firefox, Netscape, Opera oder Lynx, untersützen SSL. Sie beherschen nicht alle SSL Verfahren jedoch die gerbräuchlichsten. Die am meist vorkommende
Verschlüsselungverfahren für Webseiten sind TLS mit RSA- oder AES-Algorithmus.
Brandstätter Andreas, Klaffl Christoph
Seite 44von 231
ALFSA
2.8
2.8.1
KAPITEL 2. VERWENDETE TECHNOLOGIEN
PHP
Allgemeines
PHP ist die Kurzform für PHP: Hypertext Preprocessor“ (Früher: Personal Home Page
”
”
Tools“) und ist eine interpretierte Skriptsprache die von der Syntax her C bzw. C++ sehr
ähnelt. Sie ist Open Source und wird ständig weiterentwickelt. Im Gegensatz zu Javascript
wird PHP severseitig ausgeführt und nur die Ausgabe wird an die Clients (Browser) gesendet, dadurch bleibt dem Client der Programmcode verborgen. PHP zeichnet sich besonders
durch die leichte Erlernbarkeit aus, sodass man keine besonderen Vorkenntnisse benötigt werden um PHP Skripte zu schreiben. PHP verfügt darüber hinaus über eine große Anzahl an
Datenbanktreibern (MySQL, PostgreSQL, ....) und zusätzlichen Funktionsbibliotheken (zum
Beispiel Bibliotheken zur Erzeugung von dynamischen Bildern). PHP wird hauptsächlich für
dynamischen Webseiten eingesetzt kann aber auch für andere Zwecke verwendet werden:
• Kommandozeilen Skripts (PHP Kommandozeileninterpreter wird zum Ausführen benötigt)
• Clientseitige GUI Applikationen (ohne Webserver über die GTK Grafikbibliothek)
2.8.2
Funktionsweise
Bei PHP wird der Programmcode serverseitig ausgeführt. Dadurch wird der Quelltext nicht an
den Browser am Client gesendet sondern dem PHP Interpreter zugeführt. Bei einem Webserver
kann der PHP Interpreter über mehrere Schnittstellen (CGI,...) angebunden werden, bei der
CGI Methode muss jedoch bei jeder Ausführung eines PHP Programmcodes der Interpreter
eigens gestartet werden. Dadurch dauert diese Methode deutlich länger als bei den anderen
Möglichkeiten. Beim freien Apache Webserver kann der PHP Interpreter als Modul geladen
werden, sodass gegebenenfalls sofort mit der Ausführung begonnen wird. Eine Anfrage an
einem Webserver läuft meistens wie folgt ab:
Der Client fordet vom Webserver eine Datei an, zum Beispiel index.php. Der Webserver lädt
dann die Datei von der Festplatte, stellt fest dass es sich um eine Datei vom Typ PHP handelt und übergibt die Datei dem PHP Interpreter. Dieser arbeitet die Datei ab. Die Ausgabe
wird bereits während der Abarbeitung an den Webserver zurückgegeben und dieser sendet die
Ausgabe weiter an den Browser am Client. Durch dieses Prinzip kann der Client keinen PHP
Programmcode einsehen und muss diesen daher auch nicht ausführen. Dadurch entfallen eventuell benötigte Plugins und Zusatzsoftware, die bei einer clientseitgen Ausführung benötigt
würden. Desweiteren brauchen die Clients keine Verbindung zu dem Datenbankserver, falls einer verwendet wird. Die Nachteile liegen dafür aber auch klar auf der Hand: Für jeden Aufruf
der Datei muss diese neu intepretiert werden, da PHP standardmäßig keinen Bytecode-Cache
besitzt. Dadurch kommt es eventuell zu einer starken Auslastung des Webservers und die
Reaktionszeiten verlängern sich. Es existieren jedoch verschiedene Bytecode-Cache Systeme
um diesem Verhalten entgegenzuwirken.
Brandstätter Andreas, Klaffl Christoph
Seite 45von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Abbildung 2.5: PHP Funktionsprinzip
2.8.3
Syntax
Ein einfaches Hallo Welt“-Beispiel sieht folgendermaßen aus:
”
1
2
3
<?php
echo "Hallo Welt!";
?>
Listing 2.1: PHP Syntaxbeispiel
2.8.4
Implementierung
PHP ist plattformunabhängig und läuft auf allen gängigen Betriebssystemen. Dazu gehören
Linux, Unix, Mac OS X, Windows, ... . Es existieren PHP Module für die meisten heute
gebräuchlichen Webserver wie, Apache, lightHTTPD, Microsoft IIS, ... . Die Webserver, für
die es keine speziellen Module gibt, können den PHP Interpreter über CGI aufrufen, sofern
sie diese Methode unterstützen.
2.9
2.9.1
JAVA
Allgemeines
JAVA ist eine objektorientierte Programmiersprache der Firma Sun Microsystems. Um Java
Programme ausführen zu können ist die Java Runtime Enviroment erforderlich die frei zur
Verfügung steht. Java lehnt sich sehr an C++ an und hat auch zum Ziel die erfolgreichen
Brandstätter Andreas, Klaffl Christoph
Seite 46von 231
ALFSA
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Features von C++ bieten zu können, ist jedoch komplett aus Klassen aufgebaut. Java ist zudem plattformunabhängig, sodass Programme, die in Java geschrieben sind, auf verschiedenen
Computersystemen ausgeführt werden können.
Java gilt fälschlicherweise oftmals als sehr langsam. Jedoch ist diese Behauptung nicht unbedingt korrekt. Die GUI Libary Swing bzw. AWK ist für diesen Ruf maßgeblich verantwortlich,
da diese tatsächlich langsamer arbeiten als vergleichsweise die GUI von .NET Framework.
Dieser Umstand rührt daher, da die GUI Libary bei Java auf jedem System laufen muss. In
anderen Bereichen kann Java sehrwohl adequate Laufzeiten bieten [3].
2.9.2
Funktionsweise
Java Programme werden in Byte-Code übersetzt. Damit dieser Byte-Code ausgeführt werden kann, wird benötigt die Java Virtual Machine (JavaVM), die Teil der Java Runtime
Enviroment ist benötigt. Die JavaVM interpretiert den erzeugten Byte-Code und kompiliert
ihn gegebenfalls (JIT-Compiler). Durch den JIT-Compiler (Just in Time Compiler) wird der
Byte-Code zur Laufzeit des Programms in nativen Maschinencode umgewandelt und für die
jeweilige Computerplattform optimiert. Bei Programmen, die länger laufen und bei denen der
Programmcode mehrmals abgearbeitet wird, erreicht man dadurch viel höhere Ausführungsgeschwindikeiten als wenn der Byte-Code nur interpretiert wird.
Das Speichermanagement übernimmt Java selbst ( garbage collector“), sodass Speicherlecks
”
größtenteils vermieden werden und nicht verwendeter Speicher automatisch freigegeben wird.
Java stellt auch viele Sicherheitsfunktionen zur Verfügung mit denen überprüft wird, dass
kein ungültiger Byte-Code ausgeführt wird, sowie dass auf Programmobjekte nur zugegriffen
werden darf, wenn die Rechte dazu gegeben sind.
2.9.3
Syntax
Ein einfaches Hallo Welt“-Beispiel sieht so aus:
”
1
2
3
4
5
public class HalloWelt {
public static void main(String[] args) {
System.out.println("Hallo Welt!");
}
}
Listing 2.2: JAVA Syntaxbeispiel
Anhand des Syntax Beispiel wird deutlich, dass Java in Klassen aufgebaut ist. Beim Programmstart wird die Standardmethode main“ der Klasse aufgerufen.
”
Brandstätter Andreas, Klaffl Christoph
Seite 47von 231
ALFSA
2.9.4
KAPITEL 2. VERWENDETE TECHNOLOGIEN
Implementierung
Die Java Runtime Enviroment von Sun steht für die Betriebssysteme Linux, Mac OS X,
Solaris und Windows zur Verfügung. Es existieren auch Open-Source Alternativen, die jedoch
vom Funktionsumfang sehr beschränkt sind und deshalb den Großteil der Programme nicht
ausführen können.
Brandstätter Andreas, Klaffl Christoph
Seite 48von 231
ALFSA
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Kapitel 3
Analysen und Entscheidungen
3.1
3.1.1
Betriebssysteme
Debian Etch (LINUX)
Debian Etch ist eine Linux Distribution, die vorallem auf Stabilität achtet. Die Programmpakete müssen einen langen Testzyklus durchlaufen, bis sie wirklich in die stabile Variante
der Distribution aufgenommen werden. Dies führt dazu, dass kaum Probleme mit Programmen auftreten. Debian setzt auf den Linux Kernel 2.6 und hat somit eine solide Basis für ein
Server System, das skalierbar und effizient arbeitet. Der Linux Kernel war von Anfang der
Entwicklung an als Client/Server System ausgelegt und ist daher technisch hoch entwickelt.
Debian eignet sich für simple Anwendugen genauso wie für komplizierte Aufgaben.
Pro
• Einfache Installation und Verwaltung von Software mittels apt-get“
”
• Schnelle und Bandbreiten sparende Remoteadministration über SSH
• Schlankes Serversystem, da keine Graphische Oberfläche für den Betrieb erforderlich ist
(Ressourcenschoned)
• POSIX konform
• OpenSource“ und kostenlos
”
• Uneingeschränkte Benutzung auf einer beliebigen Anzahl von Servern/Clients
• Es werden viele verschiedene Computer Architekturen (darunter x86, x86 64, PPC,
SPARC, ...) unterstützt
Brandstätter Andreas, Klaffl Christoph
Seite 49von 231
ALFSA
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
• Sicherheitsupdates werden schnell bereitgestellt
• Durchdachtes Sicherheitskonzept (Dienste werden als eigener unpriviligierter Benutzer
ausgeführt)
Contra
• Kein direkter Support von Debian (Support kann von bestimmten Firmen wie z.B. HP
gekauft werden)
3.1.2
Microsoft
TM
Windows Server 2003
Windows Server 2003 ist ein komerzielles Serverbetriebssystem von Microsoft. Es setzt auf
einen NT Kernel und ist folglich für Netzwerkaufgaben ausgelegt. Das Hauptaugenmerk liegt
auf der einfachen Konfiguration, mit welcher allerdings nur vorgegebe Lösungen eingestellt
werden könne. Es eignet sich für simple Anwendugen und begrenzt für komplizierte Aufgaben,
da das System nicht einfach über die inkludierten Funktionen und Konfigurationen hinaus
erweitert werden kann.
Pro
• Direkter Support bei Microsoft
• Zentrale Serververwaltung (nur für Microsoft eigenen Serverdienste)
Contra
• Graphische Oberfläche wird zum Betrieb vorausgesetzt (verbraucht viele Ressourcen)
• Zusätzlich zu den teuren Lizenzen für den Server werden auch Lizenzen für die angeschlossenen Clients/Server benötigt
• Keine definierten Schnittstellen zu den Serverdiensten und fehlende Interoperabilität
mit andern Betriebssystemen
3.1.3
Entscheidung
Die Entscheidung fiel auf das freie Linux Betriebsystem, da es für die gegebenen Anforderungen bestens geeignet ist. Das System von Microsoft wäre funktionell gesehen auch geeignet,
jedoch es ist zu aufgeblasen“ bzw. verbraucht mehr Hardwareresourcen als das Linux System.
”
Desweiteren würden sich die Kosten für Lizenzen nicht rechnen.
Brandstätter Andreas, Klaffl Christoph
Seite 50von 231
ALFSA
3.2
3.2.1
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Datenbank Server
MySQL [16] [17]
MySQL ist eine freier, Open Source“ Datenbank Server, der sich großer Beliebtheit erfreut, da
”
er kostenlos und äußerst performant ist. Er ist von Grund auf mit dem Ziel, sehr schnell zu sein,
entwickelt worden. Deswegen beschränkt sich MySQL auf die grundlegenden Funktionen einer
Datenbank. Zunkünftig sollen mehr Funktionen für den Enterprise Betrieb in Unternehmen
hinzukommen.
Pro
• Freie Wahl zwischen verschiedenen Datenbanktreibern (MyISAM, InnoDB, . . . )
• Geringer Speicherverbrauch auf der Festplatte
• Freie Lizenz (GPL)
• Plattformunabhängig
• Bessere Performance gegenüber PostgreSQL und MS SQL Server [16] [17]
Contra
• Wenige Datenbankfunktionen im Vergleich zu anderen Datenbanksystemen
3.2.2
PostgreSQL [17]
PostgreSQL ist ebenfalls eine freier, Open Source“ Datenbank Server, der sich einer ähnlichen
”
Popularität erfreut wie MySQL. Er wird jedoch mit dem Ziel, möglichst viele Funktion zu
bieten, entwickelt.
Pro
• Weiterverkauf mit den eigenen Produkten möglich (BSD Lizenz)
• Plattformunabhängig
• Viele Datenbankfunktionen
Brandstätter Andreas, Klaffl Christoph
Seite 51von 231
ALFSA
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Contra
• Kein direkter Support (Support kann von anderen Firmen gekauft werden)
3.2.3
Microsoft SQL Server 2005 [16]
Microsoft SQL Server ist ein komerzieller Datenbankserver, der vorallem in Unternehmen zum
Einsatz kommt. Er ist für große Datenbanken ausgelegt und bietet alle wichtigen Funktionen
eines großen Datenbanksystems (wie z.B. Oracle). Durch die vielen komplexen Funktionen ist
er allerdings langsamer und verbraucht mehr Ressourcen (RAM + Festplattenplatz) für SQL
Queries.
Pro
• Erweiterte Replikationsmöglichkeiten
• Zertifiziert als C-2
1
konform [25]
• Bietet Funktionen, die für große Datenbank ausgelegt bzw. notwendig sind
Contra
• Lizenzkosten (für den Server und für die weiteren Clients)
• Bindung an das Windows Server 2003 Betriebssystem
• Mehr Ressourcen werden benötigt
3.2.4
Entscheidung
Der Microsoft SQL Server 2005 ist für diese Diplomarbeit nicht geeignet, da er nicht auf dem
ausgewählten Serversystem läuft. Desweitern ist der Microsoft SQL Server 2005 zu teuer. Die
Entscheidung fiel daher zwischen MySQL und PostgreSQL. Letzendlich wurde de Datenbankserver MySQL ausgewählt, da er der performantere ist.
1
C2 ist die höchste Zertifizierungsklasse für Behörden und Regierungen (in den USA) [25]
Brandstätter Andreas, Klaffl Christoph
Seite 52von 231
ALFSA
3.3
3.3.1
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Replikation vs. Cluster [19] [18]
Cluster allgemein
Ein Cluster ist ein Verbund von mehreren Systemen zu einem hocheffizienten und/oder ausfallsicheren Computersystem. Damit Cluster Systeme die Leistung erbringen, die man erwartet,
müssen sie über schnelle Netzwerkverbindungen untereinander ausgestattet sein.
Pro
• Hochverfügbarkeit und Vermeidung von Single-Point-of-Failure automatisch gegeben
bzw. leicht implementierbar
• Hohe Gesamt-Performance durch ausschließliche Speicherung der Daten im RAM möglich
(z.B. bei MySQL)
• Synchrone Datenhaltung in Echtzeit
Contra
• gute Netzwerkverbindung zwischen den Knoten ist eine Vorraussetzung (üblich >=
100Mbit)
• hoher Bedarf an Hardware bei Realisierung ohne Doppelaufgaben und Single-Piont-ofFailure (vgl Mysql-Cluster: 2xStorage Node, 2xSQL Node, 2xManagement Node)
• Es ist nicht möglich, Knoten online hinzuzufügen oder zu löschen (der Cluster muss in
solchen Fällen neu gestartet werden) (bei MySQL)
3.3.2
Active-Passive-Cluster
Bei einem Active-Passive-Cluster verliert man den Vorteil der Performancesteigerung. Dabei
wird nur ein Node für die Bearbeitung der Anfragen verwendet und die anderen synchronisieren nur die Änderungen. Falls der Master-Node ausfällt, übernimmt meist ein Slave-Node
die Aufgaben des Masters.
Pro
• Die Hardware des Passiv-Clusters wird weniger stark belastet, wodurch sich dessen
Lebensdauer erhöhen kann
Brandstätter Andreas, Klaffl Christoph
Seite 53von 231
ALFSA
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Contra
• Keine Performancesteigerung möglich, nur Erhöhung der Verfügbarkeit
• Normalerweise treten kurze Unterbrechungen bei der Übernahme auf (im Bereich einiger
Sekunden)
3.3.3
Active-Active-Cluster
Ein Active-Active-Cluster ist jenes System, das man sich unter den Namen Cluster vorstellt.
Alle Nodes des Clusters stehen für die Bearbeitung der Anfragen zur Verfügung, jedoch muss
ein Load Balancer 2 die ankommenden Anfragen auf die Nodes verteilen.
Pro
• es ist möglich höhere Performance als bei Active-Passive-Clustern zu erreichen
Contra
• Load-Balancing ist notwendig um das Active-Active System zu betreiben
3.3.4
Replikation allgemein
Bei der Replikationen werden die Daten zeitgesteuert bzw. aktionsgesteuert zu den anderen
Teilen des Datenbank Systems synchronisiert bzw. repliziert. Die Schwierigkeit besteht darin,
alle Nodes untereinadner zu synchronisieren, ohne dass Konflikte enstehen, die sich nur durch
besonders durchdachte DB-Konzepte vermeiden lassen.
Pro
• leichte Skalierbarkeit bei eigener Implementation
Contra
• kurzzeitige Asyncronität bei Zeitgestreuerter Replikation
• eigene Load-Balancing bzw. Fail-Over-Lösung notwendig
2
Der Load Balancer ist ein Lastverteiler, der die Antwortzeiten und Auslastung einzelner Server beurteilen
”
kann und eine Anfrage von außen mit der bestmöglichen Server-Performance bedienen kann.“ [26]
Brandstätter Andreas, Klaffl Christoph
Seite 54von 231
ALFSA
3.3.5
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Master-Slave Replikation
Bei der Master-Slave Replikation können keine Konflikte unter den Node entstehen, da es nur
einen Master gibt, der Datenänderungen entgegen nimmt. Jedoch können von allen beteiligten
Slave Nodes auch Datensätze gelesen werden. Bei einem Ausfall des Master Node bedeutet
das aber den Totalausfall sofern keine Fail-Over Lösung vorhanden ist.
Pro
• Slave werden als Quellen bezüglich fehlerhafter Daten ausgeschlossen
• Online Hinzufügen von Slave Nodes möglich
Contra
• Totalausfall des Systems bei Ausfall des Masters, wenn Master nicht von Slave übernommen wird
• Datenänderungen müssen am Master durchgeführt werden, nur Selects können an Slave
delegiert werden
• Im Fehlerfall können keine Datenänderungen durchgeführt werden, oder im Fail-Back
Fall müssen Daten von den Slaves auf den Master übertragen werden
3.3.6
Master-Master Replikation
Bei der Master-Master Replikation können auf jedem Node Datenänderungen vorgenommen
werden und Datensätze gelesen werden. Jedoch kommt es sehr leicht zu Konflikten, da gleiche
Einträge auf verschiedenen Nodes während der Eingabe nicht überprüft werden können. Erst
bei der Synchronisationen treten diese Probleme auf, um welche sich dann eine spezielle
Synchronisationsimplementierung kümmern muss. Vorallem Auto Increment Werte stellen
ein großes Problem dar und sollten deshalb auf Systemen mit Master-Master Replikationen
nicht eingesetzt werden.
Pro
• komplett identische Server möglich (auf Software und Konfiguration bezogen)
Contra
• Aufwendige Prüfung der zu synchronisierenden Daten notwendig (welche Daten sind
von welchen zu überschreiben)
Brandstätter Andreas, Klaffl Christoph
Seite 55von 231
ALFSA
3.3.7
KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN
Entscheidung
Nach ausführlichen Überlegungen wurde eine Master-Master Replikation ausgewählt, die wir
selbst implementiert bzw. programmiert wurde. Ein Cluster System wäre nicht möglich gewesen, da geplant ist die Server an unterschiedlichen geographischen Standorten zu betreiben.
Daraus folgt das die Netzwerk-Geschwindigkeit zwischen den Nodes zu langsam für einen
Cluster wäre.
Brandstätter Andreas, Klaffl Christoph
Seite 56von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Kapitel 4
Planung und Implementierung
4.1
Server aufsetzen
Es wurde zur Entwicklung seitens der Feuerwehr Sieghartskirchen ein Server zur Verfügung
gestellt. Die zwei weiteren Server wurden vom Entwicklerteam selbst für die Dauer der Diplomarbeit bereitgestellt.
4.1.1
Installationsmedium besorgen
Das Linux System Debian Etch“ lässt sich auf verschiedene Art und Weise installieren, wie
”
zum Beispiel über das Netzwerk, von einem USB Stick oder über eine CD-Rom. Es wurde
die CD Installationsmethode gewählt. Die benötigten ISO-Images können von der Debian
Hauptseite (http://www.debian.org/) bzw. von den zahlreichen Mirror Seiten herunterladen
werden, auch eine Downloadmöglichkeit über das BitTorrent1 System steht zur Auswahl.
Einige Seiten, über die das Installationsmedium bezogen werden kann, sind:
• http://www.debian.org/
• http://gd.tuwien.ac.at/
• http://debian.planetmirror.com/
• http://mirror.aarnet.edu.au/
• http://debian.inode.at/
• http://esda.wu-wien.ac.at/
1
Filesharing Protokoll für die schnelle Verteilung von großen Datemengen
Brandstätter Andreas, Klaffl Christoph
Seite 57von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Die aktuelle Version (während der Ausführung dieser Diplomarbeit) ist 4.0r3. Das Suffix r3“
”
kennzeichnet den vierten Release, der hauptsächlich die letzten Sicherheitsupdates seit dem
ersten Releases beinhaltet. Es ist zu empfehelen die MD5 Checksumme zu kontrollieren um
sicherzugehen, das das Image ohne Fehler heruntergeladen wurde. Das ISO-Image wird mit
einem entsprechendenen Programm auf CD gebrannt und in das CD Laufwerk des Servers
eingelegt.
4.1.2
Installation
Um die Installation zu starten wird der Server mit der Installations CD gebootet. Es sollte der
Startbildschirm von der Debian CD geladen werden. Nun können einige Optionen angegeben
werden (z.B.: für mehr Ausgabe) bzw. entscheiden werden, ob ein textbasierter Installer oder
ein graphischer Installer gestartet werden soll. Wird ENTER“ gedrückt, so wird und mit
”
den Standardeinstellungen fortgefahren, worauf sich der textbasierte Installer startet. Die
einzelnen Installationsschritte sind eingeteilt in:
1. Regionale Einstellungen: Hier wird die Sprache und das Land eingestellt sowie das
Tastaturlayout
2. Laden der Installationsmodule: Die benötigten Treiber und Installationsdaten werden geladen
3. Netzwerkkonfiguration: Es wird versucht das Netzwerk automatisch mit DHCP zu
konfigurieren, wenn dies fehlschlägt, muss selbst eine IP Einstellung gewählt werden
4. Partitionierung: Hier wird die Festplatte partitioniert und für die Installation vorbereitet
5. Installieren des Basissystem: Die Basiskomponenten werden auf die Festplatte installiert
6. Softwareauswahl: Es können Softwarepakete ausgewählt werden, die installiert werden
(WEB Server, Dateiserver, Desktop, ...)
7. Bootloader: Wird automatisch auf die erste Festplatte installiert
8. Neustart: Nach erfolgreicher Installation wird neu gestartet
Nach dem Neustart des Systems startet das Debian System automatisch von der Festplatte
und kann konfiguriert bzw. es kann Software nachinstalliert werden. Nach dem Installationsvorgang sollten die neusten Sicherheitsupdates heruntergeladen werden und installiert werden.
Dies wird über die folgenden Befehle erreicht:
1
root@euklid:˜$ apt-get update
Brandstätter Andreas, Klaffl Christoph
Seite 58von 231
ALFSA
2
3
4
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
....AUSGABE....
root@euklid:˜$ apt-get upgrade
....AUSGABE....
Listing 4.1: Systemaktualisierung
4.1.3
Konfiguration
Der Server benötigt im Wesentlichen keine weitere Konfiguration.
4.2
SSH Server aufsetzen
Damit die Server entfernt administriert werden können wird ein SSH Server benötigt, mit
dem es möglich ist eine Terminalsitzung remote zu öffnen. Desweiteren wird dieser auch für
die Server-Server Syncronisation verwendet.
4.2.1
Installation
Die Installation gestaltet sich nach dem Debian Prinzip sehr einfach und es reicht folgender
Befehl, der im Terminal ausgeführt wird:
1
2
root@euklid:˜$ apt-get install openssh-server
....AUSGABE....
Listing 4.2: SSH Server installieren
4.2.2
Konfiguration
Aus Sicherheitsgründen wird das root Login über SSH verboten, da es anfälliger für Bruteforce
Attacken ist. Eine Anmeldung ist nur mit einem unprivilegiertem Benutzeraccount möglich,
der nach Bedarf root-Berechtigung über den Befehl su“ erhält. Die Sperrung erfolgt über
”
die Direktive PermitRootLogin“ in der Konfigurationsdatei /etc/ssh/sshd config“, die mit
”
”
einem geeigneten Text Editor (vi, vim, nanu, ...) umgeschrieben wird. Ein Auszug:
1
2
3
4
.......
# Authentication:
LoginGraceTime 120
PermitRootLogin no
<<===
Brandstätter Andreas, Klaffl Christoph
Seite 59von 231
ALFSA
5
6
7
8
9
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
.......
Listing 4.3: SSH Konfiguration: Root Login verbieten
Danach wird der SSH Server über das Init Script /etc/init.d/ssh“ neugestartet:
”
1
2
root@euklid:˜$ /etc/init.d/ssh restart
* Restarting OpenBSD Secure Shell server sshd
[ OK ]
←-
Listing 4.4: SSH Server neustarten
In der Standardeinstellung von SSH in Debian wird nur das SSH-2 Protokoll erlaubt, wie
es auch erwünscht ist, da das SSH-1 Protokoll nicht mehr die nötige Sicherheit bieten kann
(siehe Kapitel 2.1 SSH)
Da sich alle Server in Netzwerken befinden, die über einen Router in das Internet gelangen,
muss eine Portweiterleitung des SSH Ports (22) an den Server im Router eingestellt werden.
Somit leitet der Router eingehende Verbindungen auf diesem Port an den Server und es ist
möglich von außen eine SSH Sitzung aufzubauen, um den Server zu administrieren.
4.3
Datenbankserver aufsetzten
4.3.1
Installation
Um den MySQL Server zu installieren genügt folgender Befehl:
1
2
root@euklid:˜$ apt-get install mysql-server
....AUSGABE....
Listing 4.5: MySQL Datenbankserver installieren
Zusätzlich zum MySQL Server wird auch der Kommandozeilen Client mysqlclient“ automa”
tisch installiert. Die Administration wird durch dieses Tool durchgeführt.
Brandstätter Andreas, Klaffl Christoph
Seite 60von 231
ALFSA
4.3.2
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Konfiguration
In der Standardeinstellung von MySQL in Debian erlaubt der MySQL Server nur Verbindungen von dem lokalen Host. Wenn man den MySQL Server über das Netzwerk adminstrieren
bzw. verwenden will muss man dies in der Konfiguration ändern. Dazu muss die Direktive
bind-address“ auskommentiert werden:
”
1
2
3
4
5
6
7
8
9
10
11
12
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address
= 127.0.0.1
<<==
#
# * Fine Tuning
#
key_buffer
= 16M
max_allowed_packet
= 16M
thread_stack
= 128K
thread_cache_size
= 8
Listing 4.6: MySQL Konfiguration: Zugriffe über das Netzwerk erlauben
Um die Einstellungen neu einzulesen bzw. zu übernehmen muss der MySQL Server neugestartet werden:
1
2
3
4
root@euklid:˜$ /etc/init.d/mysql restart
* Stopping MySQL database server mysqld ←[ OK ]
* Starting MySQL database server mysqld ←[ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing
tables.
←-
Listing 4.7: MySQL Server neustarten
Mit dieser Einstellung läuft der MySQL Server jetzt auf allen Netzwerkinterfaces und nimmt
somit aus jedem Netzwerk Verbindungen an. Dies kann ein großes Sicherheitsrisiko darstellen
und wird daher nur für die Entwicklung verwendet. Für die Server-Server Syncronisation
müssen nur lokale Verbindungen akzeptiert werden.
Als nächstes sollte ein Passwort für den root Benutzer eingerichtet werden, da dieser bei der
Standardeinstellung keines besitzt:
1
2
mysql --user=root
Welcome to the MySQL monitor.
Brandstätter Andreas, Klaffl Christoph
Commands end with ; or \g.
Seite 61von 231
ALFSA
3
4
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Your MySQL connection id is 7
Server version: 5.0.45-Debian_1ubuntu3.1-log Debian etch
distribution
5
6
7
8
←-
Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer.
mysql> update mysql.user set Password=PASSWORD(’<das neue ←Passwort kommt hier hin>’) where User=’root’;Query OK, 1 row
affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
9
10
11
12
13
14
15
←-
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> quit
Bye
Listing 4.8: MySQL Konfiguration: Passwort für den administrativen Account (root) setzten
Für die weitere Verwaltung der Datenbank wurden die freien MySQL GUI Tools verwendet.
Sie sind für die Windows- und Linuxplattform verfügbar.
4.4
Webserver aufsetzten
Für die Administration des ALFSA Systems wird ein Webserver benötigt. Die Wahl fiel auf
den freien Apache2 Webserver mit dem PHP Modul (mod-php5).
4.4.1
Installation
Um den Apache2 Webserver zu installieren genügt folgender Befehl:
1
2
root@euklid:˜$ apt-get install apache2 libapache2-mod-php5 php5- ←cli php5-common
....AUSGABE....
Listing 4.9: Apache2 und PHP5 installieren
Damit wird Apache2 heruntergeladen und installiert. Zusätzlich werden auch PHP5, der PHP
Command Line Intepreter und das PHP Modul für den Apache2 Webserver installiert.
Brandstätter Andreas, Klaffl Christoph
Seite 62von 231
ALFSA
4.4.2
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Konfiguration
In der Standardkonfiguration (welche automatisch mitinstalliert wird) ist der Webserver mit
einem VirtualHost konfiguriert, welcher auf Port 80 lauscht und bei einer Anfrage eine Testseite zurückgibt. Dieser wird über den folgenden Befehl deaktiviert:
1
2
root@euklid:˜$ a2dissite default
Site default disabled; run /etc/init.d/apache2 reload to fully
disable.
←-
Listing 4.10: Apache2: Standardmäßigen VirtualHost deaktivieren
Nun wird ein eigener VirtualHost konfiguriert, der die Datenübertragung mittels SSL sichert.
Dazu erstellt man mit einem Texteditor (z.B.: vim oder nanu) eine Konfigurationsdatei für
den VirtualHost unter /etc/apache2/sites-available/“:
”
1
root@euklid:˜$ vim /etc/apache2/sites-available/alfsa_ssl
Listing 4.11: Apache2: VirtualHost konfigurieren
Die Konfigurationsdatei sieht wie folgt aus:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<VirtualHost *:443>
# General setup for the virtual host
DocumentRoot "/home/alfsa/server-www/"
ServerName ffsieg.dyndns.org:443
ServerAdmin [email protected]
# Logfiles:
CustomLog /var/log/apache2/access-alfsa_ssl combined
ErrorLog /var/log/apache2/error-alfsa_ssl
# Possible values include: debug, info, notice, warn, error, crit ←,
# alert, emerg.
LogLevel notice
# SSL
SSLEngine On
SSLCipherSuite HIGH:MEDIUM
SSLCertificateFile
/etc/apache2/ssl/alfsa_ssl.ffsieg.dyndns. ←org.crt
SSLCertificateKeyFile /etc/apache2/ssl/alfsa_ssl.ffsieg.dyndns. ←org.key
20
Brandstätter Andreas, Klaffl Christoph
Seite 63von 231
ALFSA
21
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
</VirtualHost>
Listing 4.12: Apache2: VirtualHost Konfiguration
Die angegebenen SSL Zertifikate wurden zuvor generiert (siehe weiter unten). Weiters muss
PHP5 noch aktiviert werden. Dies geschieht mit dem folgenden Befehl:
1
2
root@euklid:˜$ a2enmod php5
Module php5 installed; run /etc/init.d/apache2 force-reload to
enable.
←-
Listing 4.13: Apache2: PHP5 aktivieren
Um alle Änderungen zu übernommen wird der Apache2 Webserver neugestartet:
1
2
root@euklid:˜$ /etc/init.d/apache2 force-reload
* Reloading web server config apache2
Listing 4.14: Apache2: Konfigurationsdateien neu einlesen
Dieser Vorgang sollte ohne eine Fehlermeldung (wie oben zu sehen ist) abgeschlossen werden.
Falls nicht sollte man die Konfigurationsdatei des VirtualHost überprüfen. Auch wenn der
Vorgang erfolgreich abgeschlossen wurde, sollte man die ErrorLog auf Fehler kontrollieren, es
könnten Probleme mit dem SSL Zertifikat auftreten.
4.5
Subversion-Server aufsetzten
Für die Verwaltung der Quellcodes war ein Versionsverwaltungssystem notwendig. Es wurde
das bekannte Subversion System SVN verwendet.
4.5.1
Installation
Es gibt verschiedene Arten einen Subversion Server zu betreiben:
• Über den Daemon svnserve“ (Läuft auf den Standardport 3690)
”
• Mittels einer SSH Verbindung
• Als Apache Modul (Port hängt von der Apache Konfiguration ab)
Brandstätter Andreas, Klaffl Christoph
Seite 64von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Der Zugang zu diesem Versionsverwaltungssystem sollte auch von der Schule aus ermöglicht
werden, daher kam erstere Methode nicht in Frage, da der Schulserver die meisten Ports (wie
auch den Subversion Stadardport) blockt.
Für die 2te Methode müsste für jeden Subversion Benutzer ein Account auf dem SSH Server
erstellt werden, dem der Zugriff über SSH erlaubt wird. Daher wurde auch diese Methode
verworfen.
Die Entscheidung fiel daher auf letzteres, das Apache Subversion Modul.
Die Installation erfolgt wie gewohnt sehr einfach über die folgenden Befehle:
1
2
root@euklid:˜$ apt-get install subversion libapache2-svn
....AUSGABE....
Listing 4.15: Subversion installieren
Damit wird das Subversion Modul für den Apache installiert und die Subversion Tools, die
benötigt werden um ein Repository anzulegen, zu sichern, ... .
4.5.2
Konfiguration
Als erster Schritt werden die Verzeichnisse für Subversion eingerichtet:
1
2
3
root@euklid:˜$ mkdir /home/svn
root@euklid:˜$ mkdir /home/svn/conf
root@euklid:˜$ mkdir /home/svn/repositories
Listing 4.16: Subversion Konfiguration: Ordnerstruktur anlegen
Als nächstes wird die Konfiguration für die Subversion Benutzer angelegt:
1
2
root@euklid:˜$ touch /home/svn/conf/passwd
root@euklid:˜$ touch /home/svn/conf/users-access-file
Listing 4.17: Subversion Konfiguration: Konfigurationsdateien anlegen
In die Datei passwd“ werden nun die Benutzer mit ihrem dazugehörigen Passwort gespeichert
”
(Datei hat das selbe Format wie die Datei htuser“ des Apache Servers). Das Passwort wird
”
im Crypt Format gespeichert. Ein Benutzer Eintrag mit Passwort kann über den folgenden
Befehl erzeugt werden:
1
root@euklid:˜$ htpasswd -n christoph
Brandstätter Andreas, Klaffl Christoph
Seite 65von 231
ALFSA
2
3
4
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
New password:
Re-type new password:
christoph:/xs182hQPisMk
Listing 4.18: Subversion Konfiguration: Benuter-/Passworteintrag generieren
Die letzte Ausgabezeile ist die Zeile, die in die passwd“ geschrieben wird. Der Übergabe”
parameter christoph“ ist der Benutzername. (Das Passwort in diesem Beispiel wurde aus
”
Sicherheitsgründen verändert)
Mittels des gleichen Befehls kann der Eintrag auch gleich direkt in die passwd“ Datei ge”
schrieben werden:
1
2
3
4
root@euklid:˜$ htpasswd /home/svn/conf/passwd christoph
New password:
Re-type new password:
Adding password for user christoph
Listing 4.19: Subversion Konfiguration: Benutzer-/Passworteintrag anlegen
Die fertige Konfigurationsdatei passwd“ sieht dann folgendermaßen aus:
”
1
2
3
christoph:58//0wxlRZyzU
silicium:Uoqpqz4QFoQMs
alfsa:/cVVoIcChBQVU
Listing 4.20: Subversion Konfiguration: passwd“ Datei
”
(Die Passwörter wurden aus Sicherheitsgründen verändert)
In der Datei users-access-file“ werden nun die Zugriffsrechte auf die Subversion Repositories
”
für die Benutzer eingestellt. Die Datei sieht folgendermaßen aus:
1
2
3
4
5
6
[/]
* =
[alfsa:/]
christoph = rw
silicium = rw
alfsa = r
Listing 4.21: Subversion Konfiguration: users-access-file“ Datei
”
Die ersten 2 Zeilen regeln die globalen Berechtigungen für jedes Repository. In diesem Fall
wird der globale Zugriff verweigert. Die 3te Zeile bewirkt das die folgenden Einträge für das
Repository alfsa“ gelten. Nun kommen die Benutzernamen mit ihren Zugriffsrechten. r“
”
”
steht dabei für Lesezugriff und w“ für den Schreibzugriff.
”
Brandstätter Andreas, Klaffl Christoph
Seite 66von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Der Benutzer alfsa“ ist der Account der verwendet wird, um auf den Testservern immer die
”
aktuelle Version von ALFSA herunterzuladen.
Die Benutzer wsind nun konfiguriert und das Repository kann nun über das Tool svnadmin“
”
erstellt werden:
1
root@euklid:˜$ svnadmin create /home/svn/repositories/alfsa
Listing 4.22: Subversion Konfiguration: Repository anlegen
Damit wird das Repository im Ordner /home/svn/repositories“ mit dem Namen alfsa“
”
”
erstellt.
Zuletzt muss nur noch das Apache Modul konfiguriert werden. Dazu wird die Konfigurationdatei /etc/apache2/mods-available/dav svn.conf“ bearbeitet:
”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# dav_svn.conf - Subversion/Apache configuration
<Location /svn>
Order allow,deny
Allow from all
# Uncomment this to enable the repository,
DAV svn
# Set this to the path to your repositories
SVNParentPath /home/svn/repositories/
SSLRequireSSL
# Uncomment the following line to enable Authz Authentication
AuthzSVNAccessFile /home/svn/conf/users-access-file
#try anonymous access first, resort to real
#authentication if necessary.
Satisfy Any
Require valid-user
# The following allows for basic http authentication. Basic ←authentication
# should not be considered secure for any particularly rigorous ←definition of
# secure.
# how to authenticate a user
AuthType Basic
AuthName "My Subversion repository"
AuthUserFile /home/svn/conf/passwd
Brandstätter Andreas, Klaffl Christoph
Seite 67von 231
ALFSA
30
31
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
</Location>
Listing 4.23: Subversion Konfiguration: Modulkonfiguration für Apache2
Die wichtigsten Schlüsselwörter sind:
• <Location /svn> - Damit wird festgelegt, dass die SVN Repositories untder der Adresse:
https://<Full Qualified Domain Name>/svn/“ erreichbar sind
”
• SSLRequireSSL - Für jeden SVN Zugriff wird eine gesicherte Verbindung benötigt, das
dient dazu, dass die Dateien nicht im Klartext über das Internet übertragen werden
• AuthzSVNAccessFile - Damit wird die Datei angegeben, in der die Zugriffberechtigungen für die Repositories stehen
• AuthUserFile - Damit wird die Datei angegeben, in der die Benutzernamen mit den
Passwörter stehen
Das Modul ist nun konfiguriert und muss nur noch aktiviert werden:
1
2
root@euklid:˜$ a2enmod dav_svn
Module dav_svn installed; run /etc/init.d/apache2 force-reload to ←enable.
Listing 4.24: Subversion Konfiguration: Apache2 Modul aktivieren
Um alle Änderungen zu übernommen wird der Apache2 Webserver neugestartet:
1
2
root@euklid:˜$ /etc/init.d/apache2 force-reload
* Reloading web server config apache2
Listing 4.25: Apache2 Konfiguration neu einlesen
Der Subversion Server ist jetzt fertig konfiguriert und kann verwendet werden.
4.6
4.6.1
Zeitspeicherung
Zeitumstellungsproblem
In Österreich wird, wie in anderen Ländern Europas, die Zeit zwischen Normalzeit (Winterzeit) und Sommerzeit umgestellt. Vom letzten Sonntag des März bis zum letzten Sonntag des
Brandstätter Andreas, Klaffl Christoph
Seite 68von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Oktobers gilt die mitteleuropäische Sommerzeit (MESZ, CEST), sonst die mitteleuropäische
Normalzeit (MEZ, CET). Die Umstellung erfolgt jeweils um 2 Uhr MEZ, welches 3 Uhr MESZ
entspricht. Ein Großteil der Datensätze in der Datenbank von ALFSA wird durch den Zeitpunkt eindeutig identifiziert. Die Zeitumstellung an sich bewirkt, dass eine Stunde pro Jahr,
die Uhrzeit nicht eindeutig ist. Andererseits fehlt eine Stunde in kontinuierlichen Ablauf der
Uhrzeit. Die fehlende Stunde stellt keine wirklichen Probleme dar. Jedoch die Stunde, die
durch die Umstellung doppelt auftritt verursacht erhebliche Probleme.
4.6.2
Lösungsansatz
Die Lösung dieses Problems liegt darin, die Zeit, die in der Datenbank gespeichert wird, nicht
nach Normal- und Sommerzeit umzustellen. Diese Bedingung wird durch die Koordinierte
Weltzeit (UTC) erfüllt. Somit ist gewährleistet, dass alle Datensätze eindeutig identifizierbar
sind. Beim Eintragen von Daten muss der aktuelle UTC-Zeitstempel ermittelt und mit den
Daten in die Datenbank geschrieben werden. Beim Anzeigen von Daten wird der gespeicherte
UTC-Zeitstempel abhängig vom Wert in Normal- bzw. Sommerzeit umgewandelt.
4.6.3
Unixzeit
Die Unixzeit ist ein Zeitstempel, der diese Bedingung erfüllt. Die Unixzeit zählt die vergangenen Sekunden seit dem 1970-01-01 00:00:00 (UTC). In PHP wird die Funktion time()
verwendet um die Unixzeit zu ermitteln. Zur Darstellung von Datum und Zeit wird standartmäßig die Funktion date() mit dem Parameter Y-m-d H:i:s (T)“ verwendet. Diese stellt
”
die Zeit in folgendem Format dar: Jahr(4-stellig)-Monat(2-stellig)-Tag(2-stellig) Stunde(2stellig):Minute(2-stellig):Sekunde(2-stellig) (Zeitzone). Die Darstellung der Zeitzone ist notwendig um die Zeit in der Stunde der Zeitumstellung von Sommer- in Normalzeit unterscheiden zu können. Tabelle 4.1 verdeutlicht die Darstellung des Datums der Unixzeit mit der
Funktion date().
Timestamp
1193528000
1193530000
1193532000
1193534000
1193536000
1193538000
Ausgabe von date( Y-m-d H:i:s (T)“, Timestamp)
”
2007-10-28 01:33:20 (CEST)
2007-10-28 02:06:40 (CEST)
2007-10-28 02:40:00 (CEST)
2007-10-28 02:13:20 (CET)
2007-10-28 02:46:40 (CET)
2007-10-28 03:20:00 (CET)
Tabelle 4.1: Unixzeit-Darstellungen
Brandstätter Andreas, Klaffl Christoph
Seite 69von 231
ALFSA
4.6.4
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Einschränkungen
Durch die Verwendung der Unixzeit als Zeitstempel wird somit das Problem der Zeitumstellung gelöst. Es ergeben sich durch die Unixzeit aber andere Einschränkungen.
Eine Einschränkung liegt darin, dass das Datum nur zwischen 1970-01-01 00:00:00 (UTC)
und 2038-01-19 03:14:08 (UTC) verarbeitet werden kann. Die Unixzeit verwendet einen longDatentyp, der auf den meisten Systemen mit 32 Bit definiert ist. Die Unixzeit zählt die
vergangenen Sekunden seit dem 1970-01-01 und wird daher am 2038-01-19 den Wertebereich
von 31 Bit überschreiten. Das 32te Bit wird zur Speicherung von negativen Zahlen verwendet.
Daher springt die Zeit beim Überlauf auf den 1901-12-13.
Diese Einschränkung des Zeitbereiches ist im Bereich vergangener Zeitpunkte (vor 1970-0101) nicht relevant, da keine Daten mit Zeiten vor 1970 gespeichert werden müssen. Im Bereich
zukünftiger Zeitpunkte (nach 2038-01-19) sind Probleme möglich. Es ist jedoch zu erwarten,
dass Debian und die in ALFSA verwendete PHP-Funktion date() rechtzeitig vor 2038 auf zumindest 64 Bit umgestellt werden. Dadurch könnten Zeitpunkte bis in 290 Milliarden Jahre
gespeichert werden. In ALFSA selbst wird die Zeit nirgends auf 32 Bit beschränkt. Daher lassen sich Probleme gegebenenfals durch ein Update von Debian und der dazugehörigen Pakete
beheben.
Eine weitere Einschränkung der Unixzeit liegt darin, dass die Zeit nur auf ganze Sekunden genau gespeichert wird. Durch die verwendung der Zeit als Teil vieler Primärschlüssel in ALFSA
können daher keine 2 Datensätze in einer Sekunde angelegt werden. Diese Einschränkungen
sind jedoch annehmbar, da nicht zu erwarten ist, dass Datensätze schneller als im Sekundentakt vom Benutzer angelegt werden.
4.6.5
Zeitsynchronität
Bei jeglicher Synchronisierung von Daten ist es erforderlich, dass die Zeit hinreichend synchron
läuft. Die Zeit der Server muss bis auf wenige Sekunden gleich laufen. Für die Clients ist eine
Abweichung von einigen Minuten verträglich. Würde der Zeitversatz bei der Synchronisation
von zu groß werden, so wäre es möglich dass unplausible Daten produziert werden.
Dies soll in einem Beispiel verdeutlicht werden:
• Server B läuft um 1 Stunde gegenüber Server A nach.
• Eine Flasche wird auf Server A gefüllt.
Dieser Datensatz wird mit Datum 2008-02-03 14:02:00 eingetragen.
• Die Flasche wird 5 Minuten später am Server B außer Dienst gestellt.
Dieser Datensatz wird mit Datum 2008-02-03 13:07:00 eingetragen.
• Beide Server synchronisieren.
Die Datenbank beinhaltet nun eine Füllung der Flasche nach dessen Außerdienststellung.
Brandstätter Andreas, Klaffl Christoph
Seite 70von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Dieses Beispiel verdeutlicht, dass es erforderlich ist, die Zeit der beteiligten Computer synchron
zu halten. Dazu wird das Protokoll NTP (Network Time Protocol) und das Linux-Programm
ntpdate bzw. der Linux-Dienst ntpd verwendet. Bei der Client-Server Synchronisation wird
ntpdate vor jeder Synchronisation ausgeführt. Auf den Servern sorgt der Dienst ntpd für eine
ständig synchrone Zeit.
Als Zeitserver wurde in der Entwicklungsphase der Zeitserver der Universität Wien
ts1.univie.ac.at verwendet. Für den Realbetrieb wird ein Pool von NTP-Servern wie zum
Beispiel europe.pool.ntp.org zu verwenden. Da dieses Pool aus einer vielzahl von Servern (946
am 2008-05-08 [5]) besteht, bietet es eine wesentlich höhere Ausfallssicherheit als ein einzelner
Server.
4.7
Datenbankdesign
Die grundlagen Datenbankstruktur waren im Wesentlichen durch den Auftraggeber gegeben.
Jedoch mussten Anpassungen dieser Struktur und der Tabellen vorgenommen werden, damit die Datenbank den hohen Anforderungen der Redundanzfreiheit genügt. Weiters wurden
Beziehungen durch Foreign-Keys definiert, um Inkonsistente Daten zu verhindern.
4.7.1
Primärschlüssel
Prinzipiell werden in Datenbanken immer Primärschlüssel definiert um Datensätze eindeutig identifizieren zu können. Häufig wird dazu ein Auto-Increment, Zählwert oder ähnlich
genanntes verwendet. Dieser Wert wird automatisch vom Datenbanksystem mit jedem Datensatz um einen Definierten Wert erhöht. So werden die Primärschlüssel von Datensätzen
zum Beispiel automatisch mit 1,2,3,4,5, usw. vergeben. Dies ist überaus geeignet, wenn genau
eine Datenbank verwendet wird.
MySQL bietet die Möglichkeit den Wert automatisch um ein mehrfaches von eins zu erhöhen.
Damit werden die Primärschlüssel von Datensätzen zum Beispiel automatisch mit 1,3,5,7,9,
usw. vergeben. Dies ist geeignet wenn eine fixe Anzahl an Datenbank-Server in einem System
arbeiten. Auf den verschiedenen Servern werden somit verschiedene Primärschlüssel vergeben.
Ein Beispiel für die Verwendung von 4 Servern:
• Server A, Offset 0, Schrittweite 4:
ergibt Primärschlüssel 0,4,8,12,16,20, usw.
• Server B, Offset 1, Schrittweite 4:
ergibt Primärschlüssel 1,5,9,13,17,21, usw.
• Server C, Offset 2, Schrittweite 4:
ergibt Primärschlüssel 2,6,10,14,18,22, usw.
Brandstätter Andreas, Klaffl Christoph
Seite 71von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
• Server D, Offset 3, Schrittweite 4:
ergibt Primärschlüssel 3,7,11,15,19,23, usw.
Durch das Prinzip der Multiple-Master Datenbank mit undefinierter Anzahl an beteiligten Computern kann jeder einzelne Client oder Server unabhängig Daten in die Datenbank
einfügen. Somit ist die vergabe von automatischen Werten als Primärschlüssel nicht mehr
geeignet.
Es wird daher eine komplett andere Grundlage zur Erzeugung eindeutiger Primärschlüssel
verwendet. Es werden mehrere atomare Eigenschaften eines Datensatzes verknüpft um in
Summe einen eindeutigen Schlüssel zu erhalten.
Folgendes Beispiel soll dies verdeutlichen.
• Ein Einsatz ist durch die ortlich zuständige Feuerwehr nicht eindeutig identifizierbar,
denn eine Feuerwehr hat mehrere Einsätze.
• Ein Einsatz ist ebenso durch die Einsatzzeit nicht eindeutig identifizierbar, denn zur
gleichen Zeit können mehrere Einsätze stattfinden.
• Ein Einsatz ist aber durch eine Kombination dieser zwei Daten eindeutig identifizierbar,
denn eine Feuerwehr kann zur gleichen Zeit nur genau einen Einsatz durchführen.
Nach diesem Prinzip werden die Primärschlüssel aller Tabellen gebildet. Dadurch ist es ausgeschlossen, dass verschiedene Clients Daten in das System einfügen, die im Konflikt zueinander
stehen.
4.7.2
Spalte edit date
Um bei synchronisationen zu erkennen, welche Daten übertragen werden müssen, wird in
jedem Datensatz das Änderungsdatum gespeichert. Dazu existiert in jeder Tabelle eine Spalte
edit date“, in der bei jeglichen Schreibzugriffen auf die Datenbank die aktuelle Unixzeit
”
(Siehe auch Kapitel 4.6.3 Unixzeit) eingefügt wird. Bei der Sychronisation werden nur jene
Datensätze übernommen, bei denen das Änderungsdatum größer als das Datum der letzten
Sychncronisation ist.
4.7.3
Löschen von Daten
In der Datenbank werden Daten grundsätzlich nicht gelöscht. Die Daten werden gegebenenfalls als gelöscht markiert. Dies hat mehrere Gründe. Einerseits ist es nicht erfordelich Daten
zu löschen. Jegliche Daten stellen zu jedem Zeitpunkt in gewisser Weise ein Abbild der Realität dar. Das heißt Atemluftflaschen, die nicht mehr verwendet werden, werden mit einem
Datum als außer Dienst gestellt. Somit existiert die Flasche für Einsätze usw. die vor diesem
Brandstätter Andreas, Klaffl Christoph
Seite 72von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Datum stattgefunden haben noch in der Datenbank. In solchen Fällen wäre es fatal eine Flasche zu löschen.
Weiters vereinfacht es die Sychronisation erheblich. Es werden nur Datensätze bei der Sychronisation übernommen, bei denen das Änderungsdatum größer als das Datum der letzten
Sychncronisation ist. Somit ist es ohne weitere Maßnahmen nicht möglich gelöschte Datensätze
bei der Sychronisation zu erkennen. Denn gelöschte Datensätze wären nicht vorhanden und
hätten somit kein Änderungsdatum um bei der Sychronisation erkannt zu werden. Um die
Löschung von Datensätzen zu sychronisieren hätten weitere Maßnahmen getrofffen werden
müssen, die allerdings nich notwendig waren, da keine Daten glöscht werden.
4.7.4
Lineare Abhängigkeiten
Jegliche Beziehungen (Abhänigkeiten) der Datenbank verlaufen nur linear in eine Richtung.
Was mit linearen Abhängigkeiten gemeint ist, soll in folgendem Beispiel gezeigt werden.
Abbildung 4.1: Abhängigkeiten Linear, Ring
Im linken Beispiel hängen alle Tabellen nur linear voneinander ab. Das heißt, alle Tabellen
können entsprechend ihrer Ebene untereinander dargestellt werden und Beziehungen zeigen
nur auf Tabellen oberhalb. Im rechten Beispiel ist dies nicht möglich. Die Tabellen hängen im
Kreis immer wieder voneinander selbst ab. Es kann somit keine Ebene definiert werden.
Für die Synchronisation ist es extrem wichtig, dass Tabellen nur linear von anderen Tabellen
abhängen, da die Synchronisation nach der Reihenfolge der einzelnen Ebenen abläuft. Zuerst
werden die Datensätze der obersten Ebene eingefügt, da diese von keinen anderen Tabellen
abhängen. Danach folgen die weiteren Ebenen Schritt für Schritt nach unten. Wird mit Beziehungen ein Ring gebildet, ist es der Synchronisation nicht mehr möglich die Ebenen zu
ermitteln und es kann keine Synchronisation durchgeführt werden.
Brandstätter Andreas, Klaffl Christoph
Seite 73von 231
ALFSA
4.7.5
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Grundlegende Struktur
Die Grundlage der Datenbank bilden die Daten von Füllstellen, Feuerwehren, Clients, Kompressoren, Benutzern, Atemluftflaschen, Geräten und Masken. Diese Daten hängen jeweils
voneinander ab wie es folgend Abbildung zeigt.
Abbildung 4.2: Grundlegende Datenbankstruktur
In dieser Darstellung werden die Pfeile als Zeiger verwendet. Atemluftflaschen zeigen beispielsweise auf die Feuerwehr, die der Besitzer der Flasche ist. Diese Pfeile stellen somit 1:n
Beziehungen dar. Eine Feuerwehr kann zum Beispiel mehrere Flaschen besitzen, aber eine
Flasche gehört nur genau einer Feuerwehr.
Diese Darstellung zeigt ledeglich die wichtigsten Tabellen der Datenbank. Weitere wichtige Tabellen folgen mit den jeweiligen Beziehungen Auszugsweise. Alle Tabellen werden im
Anhang dargestellt.
4.7.6
Atemluftflaschen
Den beinahe wichtigsten Bestandteild er Datenbank bilden die Daten der Atemluftflaschen.
Von Atemluftflaschen hängen Mängel, Prüfungen und Füllungen ab. Diese wichtigesten Beziehungen der Tabelle Atemluftflaschen werden hier gezeigt.
Abbildung 4.3: wichtige Beziehungen von Atemluftflaschen
Brandstätter Andreas, Klaffl Christoph
Seite 74von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Ebenfalls ist hier die Beziehung der Atemluftflasche auf die Eigentümerfeuerwehr zu sehen.
Atemluftflaschen stehen noch mit weiteren Tabellen in Beziehung, wie zum Beispiel der Benutzer, der die Flasche angelegt hat. Diese werden jedoch hier nicht dargestellt, sondern können
dem Anhang entnommen werden.
4.7.7
Füllungen
Ebenfalls wird hier die Grundlegende Struktur von Füllungen dargestellt, da diese ein wichtiges Detail der Datenbank darstellt.
Abbildung 4.4: Grundlegende Struktur von Füllungen
Wie hier zu sehen, werden Füllungen nicht direkt in Beziehung mit dem Benutzer, der die
Füllung vorgenommen hat, und dem Kompressor in Beziehung gesetzt, sondern, es wird eine
Ebene zwischen diesen Tabellen eingesetzt.
Beim Starten von Füllungen wird ein Einsatz erzeugt. Dieser Speichert den Einsatzort, die
zuständige Feuerwehr und Notizen zum Einsatz. Davon hängt die Füllsitzung ab, die ebenfalls
beim Starten von Füllungen erzeugt wird. Diese Tabelle speichert eine Durchgängige Füllung
eines Benutzers auf einem Kompressor. Wiederum davon hängen die eigentlichen Füllungen
ab, welche die gefüllte Flasche beinhalten.
4.7.8
Datenbankstruktur
In den folgenden zwei Seiten wird die komplette Datenbank inklusive Beziehungen dargestellt.
Leider konnte keine komprimiertere Darstellung der Datenbank gefunden werden.
Das Diagramm wurde mit DbVisualizer 6.0.10 Free edition“ erstellt. Leider kann dieses
”
Programm die Beziehungen nicht genau auf die Spaltennamen der Tabellen abbilden, wodurch
diese zuordnung im Diagramm nicht klar ersichtlich ist. Ebenso sind in den Tabellen nicht
alle Spalten, sondern nur die Primary-Keys abgebildet. Für eine genauere Darstellung der
Brandstätter Andreas, Klaffl Christoph
Seite 75von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Tabellen und Beziehungen sei daher auf den Anhang verwiesen, in dem alle Tabellen und
Beziehungen dargestellt werden.
Brandstätter Andreas, Klaffl Christoph
Seite 76von 231
ALFSA
4.7.9
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Tabellen der Datenbank
Die Tabellen der Datenbank werden im Anhang dargestellt. In folgendem Beisiel einer Tabelle
soll gezeigt werden, wie die Tabellen grafisch dargestellt sind. Ferner wird die Bedeutung der
Symbole erläutert.
Abbildung 4.5: Tabelle einsatz
Die Abbildung zeigt die Tabelle einsatz“ mit den Spalten time“, einsatzbereich fwnr“,
”
”
”
typ“, bezeichnung“, bemerkung“, time end“ und edit date“. Der Typ der jeweiligen Spal”
”
”
”
”
ten wird hellgrau neben dem Spaltennamen dargestellt.
Das Schlüssel-Symbol zeigt die Spalten an, die den Primärschlüssel bilden.
Beziehungen oder auch genannt Foreign-Keys werden links und rechts der Tabelle mit Pfeilen angezeigt. Beziehungen, die aus mehreren Spalten bestehen, werden am Ende der Pfeile
verbunden.
Links werden schwarz Beziehungen gezeigt, die von der Tabelle auf andere Tabellen verweisen. Zum Beispiel zeigt die Spalte einsatzbereich fwnr“ auf die Spalte fwnr“ der Tabelle
”
”
feuerwehren“.
”
Rechts der Tabelle werden Beziehungen gezeigt, die von anderen Tabellen auf diese verweisen.
Zum Beispiel zeigen die Spalten einsatz time“ und einsatz fwnr“ der Tabelle fuell sitzung“
”
”
”
auf die Spalten time“ und einsatzbereich fwnr“.
”
”
4.8
Datenbankzugriff
Bei jedem Datenbankzugriff, der von ALFSA Komponenten durchgeführt wird, werden alle
Variablen (Formulardaten, ...), die in ein SQL Query eingefügt werden, durch die PHP Funktion mysql real escape string()“[20] maskiert. Dadurch beugt man SQL Injections vor und
”
verhindert somit effektiv die Einschleusung von bösartigen SQL Queries [21].
Folgendes Beispiel soll illustrieren wie SQL Injections funktionieren:
Auf einem Webserver befindet sich das PHP Skript search.php“, welches zum Suchen von
”
Benutzern verwendet wird. Es akzeptiert den Parameter keyword“, welcher Bestandteil des
”
SQL Queries wird:
Brandstätter Andreas, Klaffl Christoph
Seite 77von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Aufruf : http://webserver/search.php?keyword=hugo
Erzeugter SQL Befehl: SELECT name,adresse,telefonnummer FROM benutzer WHERE
name LIKE ’%hugo%’
Eine SQL Injection sieht bei diesem Beispiel folgendermaßen aus:
Aufruf : http://webserver/search.php?keyword=hugo’+;UPDATE+benutzer+SET+name=
hacked“+ - ”
Erzeugter SQL Befehl: SELECT name,adresse,telefonnummer FROM benutzer WHERE
name LIKE ’%hugo’;UPDATE benutzer SET name= hacked“ - -%
”
Durch diese SQL Injection wird nach dem beabsichtigten SELECT Query noch ein UPDATE Query ausgeführt, welches alle Namen in der Datenbank auf hacked“ setzt. Diese un”
rechtmäßge Manipulation der Daten muss daher durch Maskierung jeglicher Benutzereingaben
verhindert werden.
4.9
4.9.1
Server - Server Syncronisation
Anforderungen
Die Server - Server Syncronisation unterlag folgenden Forderungen:
• Multi-Master: Alle Server agieren als Master und sind gleichberechtigt. Daher kann
jeder Datenbakserver für alle Arten von Datenmanipulation (INSERT, UPDATE, SELECT, ...) verwendet werden. Jegliche Änderungen der Daten an einem Datenbankserver müssen auf alle andere übernommen werden.
• Datensicherheit/Verschlüsselung: Da die ALFSA Server geographisch getrennt sind
und daher kein eigenes Netzwerk besitzen, wird die Syncronisation über das Internet
durchgeführt. Daher gilt es hier dafür zu sorgen, dass die übertragenen Daten verschlüsselt werden bzw. für andere Teilnehmer nicht einlesbar sind.
• Sichere Authentifizierung: Für die Syncronisation der Server untereinander wird verlangt, dass sich jeder Server bei dem anderen mittels eines sicheren Anmeldeverfahrens
authentifiziert.
4.9.2
Konzept
Für die Realisierung der Syncronisation wurden folgende Technologien/Programme verwendet:
Brandstätter Andreas, Klaffl Christoph
Seite 78von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
• SSH (Secure Shell)
• PHP (Hypertext Preprocessor)
• SH (Shell)
• CRON
• (JAVA)
Die aufgezählten Technologien/Programme wurden für folgende Aufgaben verwendet:
SSH
SSH sollte die Verbindung der Server untereinander übernehmen. Dazu wird eine SSH Verbindung zwischen dem lokalen und dem entfernten Server aufgebaut um über diese einen
Port Tunnel zu realisieren. Dieser Tunnel ermöglicht es, eine Verbindung zum entfernten Datenbankserver zu erstellen und Daten auszutauschen, als würde er sich im lokalen Netzwerk
befinden. Weiters ist der gesamte Datentransfer, der zwischen den 2 Servern entsteht, verschlüsselt und daher für andere nicht lesbar. Die Anmeldung am SSH Server erfolgt durch das
Public-Key Verfahren, durch welches eine sichere Authentifizierung erreicht wird. Bei Bedarf
ist es auch möglich die gesamte Verbindung zu komprimieren um Bandbreite zu sparen.
PHP
PHP übernimmt die Hauptaufgaben der Syncronisierung, die da wären:
• Aufbau, Verwaltung und Beendigung der Datenbankverbindungen und der SSH Sitzung
• Überwachung aller Vorgänge der Syncronisation
• Vergleichen der Datenbankstruktur und eventuelles aktualisieren derselbigen
• Neue und geänderte Datensätze finden und in die eigene Datenbank einfügen
• Fehlerbehandlung und Logging
SH
Ein Shell Skript wurde dazu verwendet, um das PHP Skript mittels der Kommandozeilenversion des PHP Interpreters für jeden Server, mit dem eine Syncronisation stattfinden soll,
auszuführen.
Brandstätter Andreas, Klaffl Christoph
Seite 79von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
CRON
CRON ist unter Linux/Unix Systemen ein Standarddienst, der sich um die zeitlich geplante
Ausführung von Programme jeglicher Art kümmert. Die Syncronisation wird in einem einstellbaren Zeitintervall durchgeführt und mit dieser Applikation wird diese Vorhaben realisiert.
JAVA
Während der Entwicklung der Syncronisation wurde für Testzwecke der Teil der Syncronisation, der in PHP implementiert wurde, auch in JAVA programmiert. Da JAVA wesentlich
perfomanter [3] als die Skriptsprache PHP ist, erhofften wir uns bessere Ergebnisse im Bezug
auf die Geschwindigkeit der Syncronisation. Jedoch war die JAVA Syncronisation nur sehr geringfügig schneller, daher wurde die Entwicklung der Syncronisation in JAVA eingestellt und
stattdessen weiter an er PHP Variante gearbeitet. Nach einer Analyse sind wir auf den Schluss
gekommen, dass die langsame Datenbankanbindung dafür verantwortlich ist, warum es keine
signifikanten Unterschiede in der Ausführungsgeschwindigkeit gibt. Mit der langsamen Datenbankanbindung, ist jene gemeint, die über die vergleichsweise langsame Internetverbindung
stattfindet.
Ablauf einer Syncronisation
1. Kontrollieren der lokalen Konfiguration
2. Verbindungsaufbau mit dem lokalen Datenbankserver
3. SSH Verbindung (und Tunnel) zum entfernten Server aufbauen
4. Verbindungsaufbau mit dem entfernten Datenbankserver durch den Port Tunnel
5. Tabelle für Tabelle vergleichen und synchronisieren (Reihenfolge richte sich nach den
Beziehungen zwischen den Tabellen)
6. Syncronisationsdatum schreiben
Dieser Ablauf ist sehr vereinfacht und wird im Laufe dieses Dokuments noch genauer ausgeführt.
4.9.3
Syncronisationsrichtung
Die Syncronisation ist nicht bidirektional sondern nur einseitig ausgelegt. Das bedeutet, dass
sich jeder Server die neuen Daten von den anderen Servern abholt.
Brandstätter Andreas, Klaffl Christoph
Seite 80von 231
ALFSA
4.9.4
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Anpassungen der Datenbankstruktur
Damit die Syncronisation funktioniert, musste die Datenbankstruktur angepasst werden. Jede
Tabelle wird um eine Spalte erweitert, die vom Typ unsigned integer“ ist und den Namen
”
edit date“ tägt. Bei jeder Manipulation der Datensätze (INSERT bzw UPDATE) wird in die”
ser Spalte die aktuelle Unixzeit (siehe auch Kapitel 4.6.3 Unixzeit) eingefügt. Damit bekommt
jeder Datensatz, der sich in der Datenbank befindet, ein Änderungdatum, über welches die
Syncronisierung feststellen kann, ob neue Datensätze hinzugekommen sind oder aktualisiert
wurden.
Jedoch bringt dieses Vorgehen eine Einschräkung mit sich: Es lassen sich keine Datensätze
löschen, da die Syncronisierung gelöschte Elemente nicht erkennen kann. Dieser Umstand stellt
allerdings keine größeren Probleme dar, da seitens der Feuerwehr vorgesehen ist, die Daten
zur Langzeitaufbewahrung zu behalten. Bei Tabellen wo es aber notwendig ist Datensätze zu
löschen bzw. zu wissen dass der Datensatz nicht mehr gültig ist, zum Beispiel bei der server“
”
Tabelle, wurde die Tabelle um eine zusätzliche Spalte erweitert, die vom Typ ENUM(’0’,’1’)“
”
ist und über die feststellbar ist, ob der jeweilige Datensatz noch gültig ist.
Die folgenden Tabellen sind für die Syncronisierung notwendig:
Abbildung 4.6: Server Tabelle
Abbildung 4.7: Server Details Tabelle
Abbildung 4.8: Sync Tabelle
• server: Beherbergt die Grundeinstellungen der Server (Servername, Hostname, IP Adresse, Priorität)
Brandstätter Andreas, Klaffl Christoph
Seite 81von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
• server details: Beinhaltet die wichtigen Einstellungen für die Syncronisation (SSH,
MySQL). Die Konfigurationswerte rsa, db user, db password und db name sind base64 kodiert. Damit wird der leichten Lesbarkeit der sensiblen Daten entgegengewirkt.
(Anmerkung: Dies ist kein Schutz, falls die Daten gestohlen oder kopiert werden. Die
base64 Kodierung dient lediglich dazu, dass die Einstellungen nicht im Klartext gelesen
werden können.)
• sync: Beinhaltet alle Tabellen der Datenbank mit ihren Beziehungsebenen. Zusätzlich noch 2 Spalten (to client und from client), die für die Client-Server Syncronisation
benötigt werden.
Anhand der drei Tabellen sieht man, dass jede von ihnen die Spalte edit date“ besitzt, deren
”
Verwendungszweck im obigen Absatz erläutert wurde. Weiters hat die server“ Tabelle die
”
Spalte deleted“, über welche feststellbar ist ober der Server noch existiert oder entfernt
”
wurde.
4.9.5
Shell
Das verwendete Shell Skript hat die Aufgabe, alle Server, die eine Priorität über 0 besitzen,
aus der Datenbank zu lesen und das PHP Syncronisierungsskript für jeden Server auszuführen.
Dazu extrahiert das Shell Skript aus der Konfigurationsdatei ./conf/config.inc.php“ über das
”
Konsolentool mawk“ die MySQL Verbindungsdaten und ruft damit den MySQL Komman”
dozeilenclient auf. Das SQL Statement, welches ausgeführt wird, liefert die Namen aller Server
aus der Datenbank deren Priorität ungleich 0 ist.
1 #!/bin/sh
2
3 DB_HOST=‘mawk ’/db_host/{split($1,geteilt,"="); print(substr(geteilt ←[2], 2, length(geteilt[2])-3));}’ ./conf/config.inc.php‘
4 DB_USER=‘mawk ’/db_user/{split($1,geteilt,"="); print(substr(geteilt ←[2], 2, length(geteilt[2])-3));}’ ./conf/config.inc.php‘
5 DB_PASSWORD=‘mawk ’/db_password/{split($1,geteilt,"="); print(substr( ←geteilt[2], 2, length(geteilt[2])-3));}’ ./conf/config.inc.php‘
6 DB_NAME=‘mawk ’/db_name/{split($1,geteilt,"="); print(substr(geteilt ←[2], 2, length(geteilt[2])-3));}’ ./conf/config.inc.php‘
7
8 server=‘mysql --host=$DB_HOST --user=$DB_USER --password=$DB_PASSWORD ←$DB_NAME -e "SELECT name FROM server WHERE priority!=0;"‘
9
10 for sync_server in $server
11 do
12
if [ $sync_server != "name" ]
13
then
14
echo "Synchronisiere mit $sync_server"
Brandstätter Andreas, Klaffl Christoph
Seite 82von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
15
php index.php page=sync server=$sync_server
16
fi
17 done
Listing 4.26: Shell Skript für die Syncronisation
Die Liste mit den Servernamen wird dann durch eine for-Schleife abgearbeitet. Die IF-Abfrage
dient dazu, den eigenen Server auszufiltern, damit keine lokale Syncronisation durchgeführt
wird. Dem PHP Skript wird die Option page“ mit dem Wert sync“ übergeben, dies führt
”
”
dazu, dass die Syncronisierung ausgeführt wird. Der zweite Parameter server“ ist der Name
”
des Servers, mit dem syncronisiert werden soll.
4.9.6
CRON
Das Erzeugen eines Eintrags für die Syncronisierung kann über folgenden Befehl erfolgen:
1
www-data@euklid:˜$ crontab -e
Damit öffnet sich ein Editor mit allen Cronjobs, die jeweils in einer Zeile angezeigt werden.
Eine Cron Zeile hat den folgenden Syntax:
<Minute (0-59)> <Stunde (0-23)> <Tag (1-31)> <Monat (1-12)> <Wochentag
(0-7) (Sonntag=0 oder =7)> <auszuführender Befehl> <Kommentar>
Folgende Zeile wird eingetragen:
1 */15 * * * * cd /home/christoph/Projects/php/alfsa/server-www && ./ ←sync.sh>/dev/null
Diese Zeile bewirkt, dass das Shellscript für die Syncronisation alle 15 Minuten ausgeführt
wird. Die Ausgabe wird nach /dev/null“ umgeleitet, eine Gerätedatei unter Linux, die man
”
sich wie ein schwarzes Loch vorstellen kann. Daher geht jegliche Information verloren, die
man an dieses virtuelle Gerät schickt. Wie in diesem Beispiel auch wird diese Gerätedatei
verwendet um nicht erwünschte Ausgaben zu unterdrücken. Falls man die Ausgabe nicht
umleitet, wird die gesamte Ausgabe von Cron per Mail an den Benutzer geschickt. Das PHP
Syncronisierungsskript unterstützt sowohl die normale Ausgabe, als auch die Fehlerausgabe.
Das bedeutet, das im Falle eines Syncronisierungsfehlers eine Meldung über die Fehlerausgabe
angezeigt wird. Da nur die normale Ausgabe des PHP Syncronisierungsskript umgeleitet wird
werden daher nur ihm Fehlerfall E-Mail Nachrichten durch Cron versandt.
Brandstätter Andreas, Klaffl Christoph
Seite 83von 231
ALFSA
4.9.7
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
SSH
Damit die automatische Anmeldung mit Public-Key Verfahren funktioniert, braucht jeder Server ein Schlüsselpaar, bestehend aus privaten und öffentlichem Schlüssel. Um ein Schlüsselpaar
für den aktuell angemeldeten Benutzer zu erstellen, genügt folgender Befehl:
1
www-data@euklid:˜$ ssh-keygen -f ˜/.ssh/id_rsa -t rsa
Listing 4.27: SSH Konfiguration: RSA Schlüsselpaar generieren
Damit werden die Schlüssel im eigenen Verzeichnis des jeweiligen Benutzers gespeichert:
1
2
3
4
5
www-data@euklid:˜$ ls
-rw-r--r-- 1 www-data
authorized_keys
-rw------- 1 www-data
-rw-r--r-- 1 www-data
-rw-r--r-- 1 www-data
known_hosts
-l .ssh/
www-data
www-data
www-data
www-data
0 2008-03-05 14:00
←-
1675 2007-12-30 14:03 id_rsa
404 2007-12-30 14:03 id_rsa.pub
0 2008-05-05 12:10 ←-
Listing 4.28: SSH Konfiguration: Ordnerauflistung .ssh/“
”
Anhand der Dateiberechtigung kann man sofort darauf schließen, dass die Datei id rsa“ den
”
privaten Schlüssel enthält, da sie nur für den eigenen Benutzer les- und schreibbar ist. Folgende
Liste gibt Aufschluss darüber, für welchen Zweck die einzelnen Dateien vorhanden sind:
• authorized keys: Diese Datei beinhaltet die öffentlichen Schlüssel derjenigen Benutzer,
die sich mit dem Public-Key Verfahren anmelden/authentifizieren dürfen (über diese
Methode kann man eine automatische Anmeldung realisieren)
• id rsa: Beinhaltet den privaten Schlüssel
• id rsa.pub: Beinhaltet den öffentlichen Schlüssel
• known hosts: In dieser Datei befinden sich die öffentlichen Schlüssel der SSH Server,
mit denen man sich schon einmal verbunden hat. Damit kann man feststellen ob man
sich wirklich zum richtigen SSH Server verbindet, da bei einer Änderung des Schlüssels
der Benutzer druch den SSH Client über diesen Zustand unterrichtet wird und darauf
hinweist, dass dieser Server möglicherweise manipuliert wurde.
Beachte: Da der Apache2 Webserver unter dem Benutzer www-data“ ausgeführt wird, muss
”
der Schlüssel auch für diesen erstellt werden.
Wenn alle Server ein Schlüsselpaar besitzen, kann die Anmeldung über das Public-Key Verfahren konfiguriert werden. Dazu schreibt man die öffentlichen Schlüssel der Nutzer, die sich
Brandstätter Andreas, Klaffl Christoph
Seite 84von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
mit ihrem Schlüssel anmelden dürfen, mit folgender Schreibweise in die authorized keys“
”
Datei:
<Typ des Schlüssels> <öffentlicher Schlüssel> <Kommentar>
authorized keys“ Datei von einem ALFSA Testserver:
”
1
2
3
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuDr+4 ←s3OCkz0tcurHJLpCxbqc5XQsn1H9V6VsybzDQ4OQO05FUB06tYnm/6 ←ohiNUE3S6hVf53NKRg18HuukB8Tu4HA9fqydL6bw/phxLZjxAtKGbHk/ ←jJJVHwswFeL0atpQz0XosSHkqNOhL1jIIL9rSHmR7LrunB2WilXYWzrubLk/ ←fbCWaDet7WikUCk9FOiotZ4ChY2wd/ZCmujXqpApfSBrKtm8VJ368pGtr0Z3U+ ←ThSaEx3zpQ1ortqFPjIzUmcHIkyTK560LJjUwG4Z1bbuMDqIy+AaTM3+ ←RIP1xLku/diTVXEYhB9AwFvX+pUaZc6k628q0kL/OvYPkd+oRQ== euklid- ←server
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuFoQMhCTiMWZZHmHyD9DlfDoq/ ←uiqDancNNFR6k2ZTUdTIVor8yq6Px7SP4rLrkB6B99uQvqueMOBLx/ ←mnREsj8dbQp8UXCsjRRZukjch4n3eyd/salnkIg2S2A/H7qXwX+ ←Li1cDCEy3hBJCLVdvff2j3fN5yItaMN7jyIjSgiYQb776iNO2rc/ ←qB8H8rpQyPgRezL16jskI6lZQPJGTnvSV7JWnjm/ ←UseJC11SmVUMeHugQ5klLNZ8VlHu9eCl+Jmw7/1vIqPJ9+0GCpBNy79h7/ ←SW36szgGFc5DYukbXDbrrDeVv725j0CTlfTTxDJeMQEYiQU/s6drFXfunM2kQ ←== debian-server
ssh-rsa ←AAAAB3NzaC1yc2EAAAABIwAAAQEAtEjKFuINFDlVBytyQjkd8UQDMilRzH6er/ ←DiqLQIFMWiRkDBVhyqGFjgJvU6tR0y5mxaLhtP4F+S7N/ ←CSkaEeD2j1WipPNCwYBE0Dr7kO9rp6E4prSd7s/e7mRSCjC3Mx6Knn/ ←vtf4sZDZjLHTb1KRgcmA61g10PycwJoZfa2Ausr/1Jo+ ←g8UpFY1zluBlLURArxpZadL6FFPPI0Z9jhYFP/ ←ndeUN2zXo9QWW5PQNv40pyzpwZslluhPvzzcbTuG97yVU8mJnrmCsJPUck2GNV ←/RMwu2qWPnGRmPrTrGneoLUO2FS6Yi+9qhLk6yrkk5drcb884cYR+l5d/3 ←BUbbiNS9w== trinity-server
Listing 4.29: SSH Konfiguration: authorized keys“ Datei
”
Als letzter Schritt muss nur noch die Anmeldung per Public-Key Verfahren in der Konfiguration des SSH Servers erlaubt werden. Dazu fügt man die zwei Direktiven RSAAuthentication“
”
und PubkeyAuthentication yes“ in der Datei /etc/ssh/sshd config“ ein. Ein Auszug:
”
”
1
2
3
4
5
6
7
8
.......
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
<<===
PubkeyAuthentication yes <<===
Brandstätter Andreas, Klaffl Christoph
Seite 85von 231
ALFSA
9
10
11
12
13
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
#AuthorizedKeysFile
%h/.ssh/authorized_keys
# Don’t read the user’s ˜/.rhosts and ˜/.shosts files
IgnoreRhosts yes
.......
Listing 4.30: SSH Konfiguration: Publi-Key Authentifizierung aktivieren
Um die getätigten Einstellungen zu übernehmen, wird der SSH Server neugestartet:
1
2
root@trinity:˜$ /etc/init.d/ssh restart
* Restarting OpenBSD Secure Shell server sshd
[ OK ]
←-
Listing 4.31: SSH Server neustarten
Nun können sich die jeweiligen Benutzer/Server mit ihrem Schlüssel am SSH Server anmelden:
1
2
3
4
www-data@euklid-server:˜$ ssh trinity-server
No mail.
Last login: Mon May 5 19:40:28 2008 from chief.tux.lan
www-data@trinity-server:˜$
Listing 4.32: SSH Testverbindung
Wenn die automatische Anmeldung funktioniert wird als nächstes die Port Weiterletiung
eingerichtet. Dazu muss wiederum die Konfiguration des SSH Server geändert werden. Sie
wird um die Direktive AllowTcpForwarding“ erweitert. Ein Auszug:
”
1
2
3
4
5
6
7
8
9
10
11
12
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
<<===
Listing 4.33: SSH Konfiguration: Portweiterleitung aktivieren
Der SSH Server wird wieder neugestartet, um auch diese Einstellung zu übernehmen:
Brandstätter Andreas, Klaffl Christoph
Seite 86von 231
ALFSA
1
2
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
root@trinity:˜$ /etc/init.d/ssh restart
* Restarting OpenBSD Secure Shell server sshd
[ OK ]
←-
Listing 4.34: SSH Server neustarten
Um die Port Weiterleitung zu nutzen, übergibt man dem SSH Client die Option -L“ mit den
”
Parametern für die Port Weiterleitung. Die Syntax lautet wie folgt:
ssh <hostname> -L <port>:<host>:<hostport>
Erklärung der einzelnen Optionen:
• hostname: Ist der Hostname bzw. die IP Adresse des Servers, zu dem eine Verbindung
aufgebaut werden soll
• port: Ist der lokale Port, auf dem der entfernte Port gebunden wird
• host: Ist vom entfernten Server aus gesehen der Hostname bzw. die IP Adresse des
Rechners, auf dem der Port weitergeleitet werden soll
• hostport: Ist der entfernte Port, zu welchem der lokale Port weitergeleitet werden soll
Ein Beispiel könnte so aussehen:
1
2
3
4
www-data@euklid-server:˜$ ssh trinity-server -L 3000:localhost ←:3306
No mail.
Last login: Mon May 5 19:40:28 2008 from chief.tux.lan
www-data@trinity-server:˜$
Listing 4.35: SSH Porttunnel aufbauen
Damit wird der lokale Port 3000“ am euklid-server“ auf den entfernten Port 3306“ (MySQL
”
”
”
Standardport) des Rechners localhost“ (also trinity-server“) weitergeleitet. Um zu Testen
”
”
ob die Port Weiterleitung funktioniert, kann man den Port mit dem Programm telnet“ über”
prüfen:
1
2
3
4
5
6
www-data@euklid-server:˜$ telnet localhost 3000
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’ˆ]’.
J
5.0.45-Debian_1ubuntu3.3-logw->.iJt-˜,UoNv)c=
Listing 4.36: SSH Porttunnel testen
Brandstätter Andreas, Klaffl Christoph
Seite 87von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Anhand der Ausgabe sieht man, dass sich der MySQL Server des entfernten Servers trinity”
server“ meldet, daher funktioniert der Porttunnel einwandfrei.
Die Konfiguration und Verwaltung der Schlüssel wird vom ALFSA System selbst übernommen
und muss daher nicht manuell erfolgen.
4.9.8
PHP
Das PHP Skript ist so ausgelegt, dass es über die Kommandozeile sowie auch über das Webinterface ausgeführt werden kann. Somit besteht auch die Möglichkeit eine Syncronisierung
über das Webinterface durchführen.
Es werden nun die wichtigsten Codeteile für die Syncronisation erläutert:
Port Tunnel aufbauen
1 function create_tunnel($server,$tunneld_port,$db_host,$ssh_port=22)
2 {
3
$ssh_connection_string="/usr/bin/ssh -C -f -o StrictHostKeyChecking ←=no -o ConnectTimeout=1 -o ConnectionAttempts=1 -o ←PreferredAuthentications=publickey " . $server . " -p " . ←$ssh_port . " -L ". $tunneld_port . ":" . $db_host . ":3306 ←sleep 10 > /dev/null 2> /dev/null; echo \$?";
4
$handle=popen($ssh_connection_string,"r");
5
$read=trim(fread($handle,"3"));
6
pclose($handle);
7
8
if($read=="0")
9
return TRUE;
10
return FALSE;
11 }
Listing 4.37: Funktion zum Erstellen eines Porttunnels
Der Funktion werden folgende Parameter übergeben:
1. $server: Hostname oder IP Adresse des entfernten Servers
2. $tunneld port: Der lokale Port, der für den Tunnel verwendet wird
3. $db host: Hostname oder IP Adresse des Datenbankservers im Netzwerk des entfernten
Servers
4. $ssh port: Der Port auf dem der SSH Server läuft
Brandstätter Andreas, Klaffl Christoph
Seite 88von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Über den Befehl popen()“ wird der SSH Client des Linux System aus PHP heraus gestartet.
”
Die verwendeten Optionen für den SSH Client sind:
• -C: Die Verbindung wird komprimiert
• -f : Bewirkt, dass der SSH Client kurz vor der Befehlausführung am Remotesystem in
den Hintergrund gelegt wird
• -o StrictHostKeyChecking=no: known hosts“ Datei wird ignoriert
”
• -o ConnectTimeout=1: Der Timeout wird auf 1 Sekunde herabgesetzt
• -o ConnectionAttempts=1: Es wird nur ein Verbindungsversuch unternommen
• -o PreferredAuthentications=publickey: Ameldung per Public-Key Verfahren
• -L: Port Weiterleitung
• sleep 10: Befehl der am Remotesystem ausgeführt wird
Die gesamte Ausgabe des Befehls (SSH Client + Optionen) wird auf das Gerät /dev/null“
”
umgeleitet, damit keine Ausgabe erfolgt. Zusätzlich wird auch noch die Fehlerausgabe umgeleitet ( 2> /dev/null“). Der nächste Befehl der ausgeführt wird ist echo $?“, welcher den
”
”
Rückgabewert des SSH Clients ausgibt. Dieser Rückgabewert wird mittels PHP ausgelesen
(siehe Zeile 5 von Listing 4.37). Bei Rückgabewert 0 wurde die SSH Verbindung ohne Probleme hergestellt, bei allen anderen Werten ist ein Fehler aufgetreten und die Funktion gibt
FALSE zurück.
Der sleep 10“ Befehl wird nach erfolgreicher Verbindung am Remotesystem ausgeführt und
”
dient dazu die Verbindung für 10 Sekunden offen zu halten. In dieser Zeit muss der Porttunnel
aufgebaut werden. Falls die 10 Sekunden abgelaufen sind und noch eine Verbindung über den
Porttunnel besteht wird auf Beedigung dieser gewartet und erst danach wird die SSH Sitzung
beendet.
RSA Schlüsselpaar generieren
1 function create_rsa_key()
2 {
3
if(@scandir(HOME_DIR . "/.ssh/")==FALSE)
4
if(mkdir (HOME_DIR . "/.ssh/", 0700)==FALSE)
5
return FALSE;
6
$output=array();
7
exec("ssh-keygen -f " . HOME_DIR . "/.ssh/id_rsa -t rsa",$output);
8
return $output;
9 }
Listing 4.38: Funktion zum Erstellen des RSA Schüsselpaares
Brandstätter Andreas, Klaffl Christoph
Seite 89von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Die Funktion benötigt keine Parameter.
In den Zeilen 3-5 von Listing 4.38 wird überprüft ob der .ssh“ Ordner im Heimverzeichnis
”
des jeweiligen Benutzers existiert und wenn nicht wird er erstellt. Falls bei diesem Vorgang
ein Fehler auftritt wird FALSE zurückgeliefert.
Mit exec()“ wird das SSH Tool ssh-keygen“ von PHP aus aufgerufen. Die verwendete Op”
”
tionen für ssh-keygen“ sind:
”
• -f : Mit dieser Option kann der Dateiname des Schlüssels angegeben werden
• -t: Mit dieser Option kann der Typ des Schlüssels angegeben werden (rsa1,rsa,dsa)
Fehlerbehandlung
1 function sync_error($line, $file, $string, $mysql_error="",$die=TRUE, ←$output=FALSE)
2 {
3
$fehler = "Datei: " . $file . ", Zeile: ". $line . " => " . $string ←;
4
if($mysql_error!="")
5
$fehler .= " - MySQL Fehler: " . $mysql_error;
6
7
$fehler=format_string_for_html_console($fehler);
8
append_to_log(SYNC_ERROR_LOG,$fehler["console"]);
9
10
11
if($output==FALSE && $die==TRUE)
12
{
13
if($argv)
14
{
15
$fp = fopen("php://stderr", ’w’);
16
flock($fp, LOCK_EX );
17
fputs($fp, ’Fehler beim Syncronisieren mit dem Server "’ . ←$_GET["server"] . ’". Weitere Informationen befinden sich ←in der sync-error.log!’);
18
flock($fp, LOCK_UN );
19
fclose($fp);
20
}else
21
{
22
echo ’<br><font color="red" size="3">Syncronisation wurde wegen ←eines Fehlers abgebrochen. Fuer naehere Information sehen ←sie bitte die sync-error.log ein!’;
23
}
24
}elseif($output==TRUE)
25
{
Brandstätter Andreas, Klaffl Christoph
Seite 90von 231
ALFSA
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
$string=format_string_for_html_console($string);
if($argv)
{
$fp = fopen("php://stderr", ’w’);
flock($fp, LOCK_EX );
fputs($fp, $string["console"]);
flock($fccp, LOCK_UN );
fclose($fp);
}else
{
echo $string["html"];
}
}
if($die==TRUE)
{
global $dbhandle;
if(clean_up($dbhandle)==TRUE)
del_lock_file(INCONSISTENT_LOCK_FILE);
wieder als aktiv markieren
45
46
47
48
}
49 }
//Datenbankserver
←-
append_to_log(SYNC_INFO_LOG,"Synchronisation wegen eines Fehlers
abgebrochen, siehe Sync Error Log");
die();
←-
Listing 4.39: Funktion für die Fehlerhandhabung bei der Syncronisation
Der Funktion werden folgende Parameter übergeben:
1. $line: Zeilennummer, in welcher der Fehler auftritt
2. $file: Datei, in welcher der Fehler auftritt
3. $string: Fehlertext
4. $mysql error: Falls es sich um einen Datenbankfehler handelt, wird hier die Fehlermeldung vom Datenbankserver angegeben (Standardwert: leer)
5. $die: Soll das Programm abgebrochen werden (Standardwert: TRUE)
6. $output: Soll der übergebene Fehlertext ausgegeben werden (Standardwert: FALSE)
Falls während der Syncronisation ein Fehler auftritt, wird diese Funktion aufgerufen, welche
entsprechende Log Einträge schreibt und eine Fehlermedlung ausgibt. Sie kann weiters feststellen wie PHP ausgeführt wird, von der Kommandozeile oder über das Webinterface. Dies
Brandstätter Andreas, Klaffl Christoph
Seite 91von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
wird über die Systemvariable $argv“ festgestellt, die nur existiert wenn das PHP Skript von
”
der Kommandozeile ausgeführt wird.
Die verwendete Funktion format string for html console()“ formatiert den übergebenen Text
”
für die Konsole und für HTML. Es liefert diesen als assoziatives Array zurück:
•
console“: HTML Zeilenumbrüche (<br>) und andere (\r, \r\n) werden zu einem
”
UNIX konformen Zeilenumbruch umgewandelt (\n), alle HTML Tags werden entfernt
•
html“: UNIX konforme Zeilenumbrüche (\n) und andere (\r, \r\n) werden in HTML
”
Zeichenumbrüche (<br>) umgewandelt
Freien Port herausfinden
1 $tmp=explode("-",$config_tunnel_port_range);
2 $port=rand($tmp[0],$tmp[1]);
//Zufaelligen Port aus dem ←eigestellten Port Range auswaehlen
3 $retries=20;
4 while(@fsockopen("127.0.0.1",$port,&$errno,&$errstr,2) && $retries--) ←//und ueberpruefen ob der Port frei ist
5
$port=rand($tmp[0],$tmp[1]);
Listing 4.40: PHP Codeteil zum herausfinden ob ein Port frei ist
$config tunnel port range“ ist eine globale Konfigurationsvariable, in welcher der Portbe”
reich, der für die Syncronisation verwendet werden darf, im Format <Startport>-<Endport>“
”
steht. Dieser Portbereich wird mittels der Funktion explode()“ in Start- und Endport auf”
gespalten und der Funktion rand()“ übergeben, welche einen zufälligen Port aus diesem
”
Portbereich zurückgibt. Über die Funktion fsockopen()“ wird der übergeben Port überprüft
”
und falls ein Socket geöffnet werden kann ist der Port offen und die Funktion liefert 0 zurück,
was dazu führt das die while-Schleife verlassen wird. Falls nach 20 Versuchen kein freier Port
gefunden werden konnte, wid die while-Schleife ebenfalls verlassen und über die Variable $re”
tries“ kann festgestellt werden, dass der Vorgang nicht erfolgreich war (sie hat in diesem Fall
den Wert 0). Das @“ Zeichen vor der Funktion fsockopen()“ bewirkt, dass bei einem Fehler
”
”
die Ausgabe der Funktion unterdrückt wird.
Primär Schlüssel auslesen
1 function get_primary_keys($tablename,$dbhandle)
2 {
3
$table_struct=get_table_structure($tablename,$dbhandle);
4
Brandstätter Andreas, Klaffl Christoph
Seite 92von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
5
$ret=array();
6
foreach($table_struct as $collumn)
7
foreach($collumn as $key=>$value)
8
if($key=="Key" && $value=="PRI")
9
array_push($ret,$collumn["Field"]);
10
11
return $ret;
12 }
Listing 4.41: Funktion zum Auslesen der Primärschlüssel einer Tabelle
Der Funktion werden folgende Parameter übergeben:
1. $tablename: Name der Tabelle
2. $dbhandle: Datenbankhandle
Die Funktion liest über die Funktion get table structure()“ die Struktur der Tabelle aus und
”
geht diese mit einer foreach“ Schleife durch. Wenn in der Spalte Key“ der Wert PRI“ steht,
”
”
”
ist diese ein Primärschlüssel und wird in ein Array zwischengespeichert. Dieses Array wird
nach Beendigung der foreach“ Schleife zurückgegeben.
”
Neue Datensätze auslesen
1 function get_new_data($tablename,$dbhandle,$limit_start=0, ←$limit_count=0)
2 {
3
if($limit_count==0)
4
$sql=’SELECT * FROM ’ . mysql_real_escape_string($tablename) . ’ ←WHERE edit_date>’ . $GLOBALS["last_sync_date"] . ’;’;
5
else
6
$sql=’SELECT * FROM ’ . mysql_real_escape_string($tablename) . ’ ←WHERE edit_date>’ . $GLOBALS["last_sync_date"] . ’ LIMIT ’ . ←mysql_real_escape_string($limit_start) . ’,’ . ←mysql_real_escape_string($limit_count) . ’;’;
7
8
$result=mysql_query($sql,$dbhandle) or sync_error(__LINE__, ←__FILE__, $sql, mysql_error($dbhandle));
9
10
$ret=array();
11 while($row = mysql_fetch_assoc($result))
//Process every row
12
array_push($ret, $row);
13 return $ret;
14 }
Brandstätter Andreas, Klaffl Christoph
Seite 93von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Listing 4.42: Funktion zum Auslesen der neuen Datensätze
Der Funktion werden folgende Parameter übergeben:
1. $tablename: Name der Tabelle
2. $dbhandle: Datenbankhandle
3. $limit start: Gibt die Datensätze an, ab denen selektiert wird (Standardwert: 0)
4. $limit count: Gibt an, wieviele Datensaetze maximal zurueckgeliefert werden (Standardwert: 0)
Die Funktion fragt über ein SQL Query alle Datensätze ab, deren Änderungsdatum ( edit date“)
”
größer als das letzte Syncronisatiosdatum ($GLOBALS[ last sync date“]) ist. Falls man den
”
Parameter $limit count“ verwendet, wird über die SQL-Direktive LIMIT“ die zurückgege”
”
benen Datenstätze begrenzt.
Tabellen synchronisieren
1 function sync_table($source_tablename,$target_tablename,$dbhandle, ←$dbhandle2)
2 {
3
$primary=get_primary_keys($source_tablename,$dbhandle2);
4
$limit_start=0;
5
$new_data=get_new_data($source_tablename,$dbhandle2,$limit_start, ←MAX_NEW_DATA);
6
$count_all=count($new_data);
7
8
while($new_data!=NULL)
9
{
10
foreach($new_data as $temp)
11
{
12
$sql=’INSERT INTO ’ . mysql_real_escape_string( ←$target_tablename) . ’ SET ’;
13
$count=0;
14
foreach($temp as $key=>$element)
15
{
16
$count++;
17
if(is_null($element))
18
$sql.= ’‘’ . $key . ’‘=NULL’;
19
else
20
$sql.= ’‘’ . $key . ’‘="’ . $element . ’"’;
Brandstätter Andreas, Klaffl Christoph
Seite 94von 231
ALFSA
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
if($count<count($temp))
$sql.=’,’;
else
$sql.=’;’;
}
$result=mysql_query($sql,$dbhandle);
if(mysql_errno($dbhandle)==1062)
//1062: Duplicate Entry --> ←Daher muss statt ein INSERT Query eine UPDATE Query ←durchgefuehrt werden
{
$sql=’UPDATE ’ . mysql_real_escape_string($target_tablename ←) . ’ SET ’;
$count=0;
$where="";
foreach($temp as $key=>$element)
{
$count++;
$tmp=0;
foreach($primary as $pkey)
if($key==$pkey)
$tmp=1;
if($key=="edit_date")
{
if($where!="")
$where.=’ AND ’;
$where.= ’edit_date<"’ . $element . ’"’;
}
if($tmp)
{
if($where!="")
$where.=’ AND ’;
$where.= ’‘’ . $key . ’‘="’ . $element . ’"’;
}else
{
if(is_null($element))
$sql.= ’‘’ . $key . ’‘=NULL’;
else
$sql.= ’‘’ . $key . ’‘="’ . $element . ’"’;
if($count<count($temp))
$sql.=’,’;
else
$sql.=’ WHERE ’;
}
Brandstätter Andreas, Klaffl Christoph
Seite 95von 231
ALFSA
66
67
68
69
70
71
72
73
74
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
}
$sql.= $where . ’;’;
$result=mysql_query($sql,$dbhandle) or sync_error(__LINE__, ←__FILE__, $sql, mysql_error($dbhandle));
}else
if(mysql_error($dbhandle)!="")
sync_error(__LINE__, __FILE__, $sql, mysql_error($dbhandle) ←);
}
$limit_start+=MAX_NEW_DATA;
$new_data=get_new_data($source_tablename,$dbhandle2,$limit_start, ←MAX_NEW_DATA);
$count_all+=count($new_data);
75
76
77
}
78
79
return $count_all;
80 }
//Hinzugefuegt/aktualisierte Datensaetze
Listing 4.43: Funktion zum Synchronisieren der Tabellen
Der Funktion werden folgende Parameter übergeben:
1. $source tablename: Tabellenname der Quelltabelle
2. $target tablename: Tabellenname der Zieltabelle
3. $dbhandle: Datenbankhandle der Zieldatenbank
4. $dbhandle2: Datenbankhandle der Quelldatenbank
Die Funktion liest die Primärschlüssel der übergebenen Tabelle über die Funktion
get primary keys()“ ein. Weiters werden die neuen Datensätze über die Funktion
”
get new data()“ abgerufen. Durch das Übergeben der definierten Variable
”
MAX NEW DATA“, welche in ./conf/defines.inc.php“ definiert ist, wird die Anzahl der
”
”
Datensätze, die zurückgeliefert werden, limitiert. Diese Limitierung muss stattfinden, da ansonsten das PHP Skript zu viel Speicher beansprucht und vom PHP Interpreter unterbrochen
wird. Die neuen Datensätze werden dann einzeln durchlaufen und daraus werden SQL Queries
gebaut, welche in der Zieldatenbank bzw. Zieltabelle ausgeführt werden. Falls bei diesem Vorgang en Fehler auftritt wird überprüft, ob die MySQL Fehlernummer mit 1062 übereinstimmt.
1062 bedeutet, dass bereits ein Datensatz mit den gleichen Primärschlüsselwerten existiert,
daher muss anstatt eines INSERT Querys ein UPDATE Query durchgeführt werden. Für
das zusammenstellen des UPDATE Querys sind die Primärschlüssel wichtig, da mit diesen
genau der eine Datensatz selektiert wird. Falls ein anderer Fehler auftritt wird die Funktion
sync error()“ für die Fehlerbehandlung aufgerufen. Nachdem alle neuen Datensätze durch”
gelaufen sind und in der Zieltabelle eingefügt bzw. aktualisiert wurden, wird $limit start um
die definierten Variable MAX NEW DATA“ erhöht und über die Funktion get new data()“
”
”
Brandstätter Andreas, Klaffl Christoph
Seite 96von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
die nächsten neuen Datensätze abgerufen. Der gesamte Vorgang wird solange wiederholt, bis
die Funktion get new data()“ keine Datensätze mehr zurückgibt.
”
Genauer Ablauf der Syncronisierung
Das PHP Skript für die Syncronisierung läuft folgendermaßen ab:
1. Überprüfen der Konfigurationsdateien und ob ausreichende Schreibrechte zur Verfügung
stehen
2. Verbindungsaufbau mit dem lokalen Datenbankserver
3. Eigenschaften und Einstellungen des übergebenen Servers aus der lokalen Datenbank
lesen
4. Freien Port herausfinden (Listing 4.40 auf Seite 92) und aufbauen des SSH Porttunnels
zu dem entfernten Server (Listing 4.37 auf Seite 88)
5. Verbindungsaufbau mit dem entfernten Datenbankserver über den SSH Porttunnel
6. Die Tabelle sync“ wird zwischen den zwei Server syncronisiert
”
7. Es werden alle Tabellen des entfernten Servers eingelesen und nach ihren Beziehungsebenen, welche in der sync“ Tabelle stehen, sortiert
”
8. Die Tabellen werden jetzt nacheinander abgearbeitet, begonnen wird mit jenen Tabellen
welche keine Beziehungen zu anderen Tabellen aufweisen:
(a) Es wird überprüft ob die Tabelle am lokalen Datenbankserver existiert, falls nicht
wird sie anhand der Struktur des Quelltabelle erstellt
(b) Überprüfen, ob die Tabellenstruktur gleich ist, falls nicht wird sie eventuell aktualisiert (siehe Kapitel 4.9.9)
(c) Tabelle wird syncronisiert, siehe Listing 4.43 auf Seite 94
9. Syncronisation wird gesäubert (Entfernen von temporären Daten , ...)
10. authorized keys“ für SSH überprüfen und eventuell aktualisieren
”
11. Syncronisation abschließen (Syncronisationsdatum schreiben, Log Eintrag schreiben)
4.9.9
Datenbankstruktur aktualisieren
Da während der Entwicklung die Datenbankstruktur ständig angepasst und verändert wurde, war es erforderlich, dass die Syncronisierung auch mit einer solchen Änderung zurecht
Brandstätter Andreas, Klaffl Christoph
Seite 97von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
kommt und diese auf allen Servern nachvollzieht. Für diesen Zweck wurde ein Server ausgewählt, über welchen die anderen Server im System die Datenbankstruktur übernehmen
können. Der Name dieses Servers wurde in der Datei ./conf/defines.inc.php“ in der Variable
”
MASTER STRUCTURE DB SERVER“ definiert. Falls sich während der Syncronisierung
”
herausstellt, dass sich die Datenbankstruktur der beiden syncronisierenden Server unterscheidet, wird überprüft ob der Server, von welchem syncronisiert wird, derjenige ist, von dem die
Struktur übernommen werden darf. Sollte dies zutreffen wird die Datenbankstruktur von diesem Server übernommen. Während diesen Vorgang wird der Datenbankserver über ein Lockfile als inkonsistent markiert, um Syncronisationsversuche von Clients oder anderen Server zu
verhindern, da sonst ein Datenverlust auftreten kann. Sollte während der Strukturübernahme ein Fehler auftreten, wird der gesamte Prozess rückgängig gemacht und der alte Zustand
wieder hergestellt. Danach wird der inkonsistente Status wieder aufgehoben. Falls es sich bei
dem anderen Server nicht um denjenigen handelt, von dem die Struktur übernommen werden
darf, wird der komplette Syncronisationsvorgang abgebrochen.
Beachte: Für den produktiven Einsatz, sollte sich die Datenbankstruktur im Betrieb nicht
änderen bzw. keine inkompatiblen Datenbankstrukturen geschaffen werden. Durch das Einspielen einer inkompatiblen Datenbankstruktur gehen die neuen Daten der Clients, die sich
noch nicht im verteilten Datenbanksystem befinden, verloren. Daher ist es empfehlenswert
die Aktualisierung der Datenbankstruktur im Produktivbetrieb generell zu unterbinden, dazu muss die Variable MASTER STRUCTURE DB SERVER“ mit einem leeren String also
”
“ definiert werden.
”
4.9.10
Backupserver
Durch den Eintrag eines Servers mit der Priorität 0 wird dieser zu einem Backupserver.
Backupserver können nicht für die Client-Server Syncronisation verwendet werden. Desweiteren verweigern sie auch Verbindungen von den anderen aktiven ALFSA Sytemen. Backupserver bauen lediglich Verbindungen zu den anderen aktiven ALFSA Systemn auf und holen sich
die neuen Daten. Dadurch sind alle Datensätze im ALFSA System auch auf den Backupserver verfügbar. Da die Backupserver jegliche Verbindungen von den anderen ALFSA Systemen
verweigern, können keine direkten Datenmanipulationen seitens der anderen Server auf dem
Backupserver durchgeführt werden. Im Falle einer Übernahme eines ALFSA Servers durch
einen Angreifer ist der Backupserver von diesem geschützt, da keine Verbindungen erlaubt
werden. Dadurch ist es möglich die Sicherheit der Daten noch weiter zu erhöhen.
4.9.11
Fehlerbehandlung
Für eine ordnungsgemäße Syncronisation ist es notwendig, Fehler während des Syncronisationsvorgangs zu erkennen und entsprechende Handlungen für den Umgang mit diesen auszuführen. Nachfolgend werden mögliche Fehlerszenarien angeführt:
Brandstätter Andreas, Klaffl Christoph
Seite 98von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Keine Berechtigung
Syncronisationsversuche von Servern, die im ALFSA System nicht registriert sind bzw. keine
Berechtigung haben, werden schon beim Versuch eine SSH Verbindung herzustellen abgelehnt.
Dadurch kommt es zu keiner Verbindung, wie es auch erwünscht ist. Falls aus irgendwelche
Gründen (Fehler, Manuele Manipulation der Konfiguration, ...) trotzdem eine SSH Verbindung aufgebaut werden kann, muss sich der anfragende weiters am MySQL Datenbankserver
authentifizieren, dazu müssen allerding Benutzername, Passwort, Datenbankname und der
Datenbankhost bekannt sein. Daher muss sich ein Angreifer gegen zwei Sicherheitsstufen behaupten (SSH und MySQL).
Datenmanipulation
Versucht ein Angreifer die Datenübertragung zwischen 2 syncronisierenden Servern zu manipulieren wird dieser Vorgang durch SSH erkannt und die Verbindung wird sofort getrennt.
Dadurch können keine fehlerhaften Daten bzw. manipulierte Daten von Dritten in das System eingeschleußt werden. Der Abbruch der SSH Verbindung verhält sich wie ein Abbruch
der Internetverbindung bzw. eines Timeouts (siehe 4.9.11, Verbindungsabbruch).
Serverausfall
Falls der Versuch unternommen wird, mit einem Server zu syncronisieren, der nicht erreichbar
oder abgesürzt ist, kommt die SSH Verbindung nicht zustande und es werden entpsrechende
Log Meldungen geschrieben.
Ausfall des Datenbankservers
Falls der Datenbankserver am Zielserver ausgefallen ist, kann zwar die SSH Verbindung mit
zugehörigem Porttunnel aufgebaut werden, jedoch ist die Verbindung zum entfernten Datenbankserver nicht möglich und die Syncronisation wird mit entsprechenden Log Eintragungen
abgebrochen.
Verbindungsabbruch
Bricht während der Syncronisation die Verbindung zwischen den 2 Servern ab (Firewall, Netzwerkfehler, Router ausgefallen, ...) wird dieser Umstand durch einen Timeout erkannt und die
SSH Verbindung wird beendet. Dadurch bricht folglicherweise auch die Verbindung mit dem
entfernten Datenbankserver zusammen und die Syncronisation wird daraufhin abgebrochen.
Entsprechende Log Einträge über den Verbindungsabbruch zum Datenbankserver werden im
Brandstätter Andreas, Klaffl Christoph
Seite 99von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Error Log geschrieben. Die Syncronisation wird als nicht erfolgreich markiert und alle neuen
Daten werden bei der nächsten Syncronisation nochmals angefordert.
4.10
Client - Server Syncronisation
4.10.1
Vorgaben
Synchronisation zwischen Client und Server werden grundsätzlich unregelmäßig vom Benutzer
gestartet. Nach jeder Datenmanipulation am Client sollte der Benutzer eine Synchronisation
ausführen. Daher soll die Synchronisation ohne weitere Eingaben und mit einer anschaulichem Fortschrittsdarstellung ablaufen. Der Benutzer muss einfach erkenn können, wann die
Synchronisation fertiggestellt ist.
Weiters ist es möglich, dass der Client durch einen Proxy vom Internet getrennt ist und nur
die Ports für HTTP (80) und HTTPS (443) zur Benutzung freigegeben sind. Daher muss
die Synchronisation auf einem dieser Ports durchgeführt werden und die Verwendung eines
Proxys unterstützen.
4.10.2
Konzept
Basiernd auf diesen Vorgaben wurde ein Konzept für die Client-Server-Synchronisation entwickelt. Dieses Konzept sieht auf Server und Client einen Webserver vor, welche die Daten
aus der Datenbank zur Synchronisierung aufbreiten und über Webtransfer austauschen. Diese
Komplette Übertragung erfolt über HTTPS um einem Manipulation der Daten zu verhindern.
Weiters wird ein Verbindungsschlüssel, der später noch näher erläutert wird, eingesetzt um
die Berechtigung der Datenmaniplation sicherzustellen. Die Kommunkikation erfolt in einzelnen Teilschritten um bei großen Datenmengen Timeouts zu herhindern. Ebenso kann bei
einem Verbindungsabbruch beim letzten Teilschritt fortgesetzt werden. Durch ein verteiltes
Server-Datenbank-Netz muss vom Client ein Server nach verschiedenen Kriterien selbstständig
ausgewählt werden, um einen Single-Point-of-Failure zu vermeiden.
4.10.3
Prinzip
Die einzelnen Teilschritte der Client-Server-Synchronisation erfolgen nach folgendem Prinzip:
• Client sendet HTTPS-Request mit Daten an den Server
• Server verarbeitet Daten vom Client
• Server sendet HTTP-Replay mit Daten an den Client
Brandstätter Andreas, Klaffl Christoph
Seite 100von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
• Client verarbeitet Daten vom Server
Wie im Ablauf ersichtlich, wird jede Kommunikation vom Client initiiert. Dies ist erforderlich, nur der Server öffentlich erreichbar ist. Sobald der erste Teilschritt vom Client gestartet
wurden, überwacht der Server die folgenden Anfragen. Der Server kann, wenn nach einem
Timeout kein weitere Anfragen folgen, einen Fehler feststellen und diesen in die Datenbank
eintragen und gegebenenfalls ein Email an das Supportpersonal senden. Ebenso kann der Client bei Abbruch der Verbindung während der Synchronisation einen Fehler feststellen. Der
Client kann daraufhin den Benutzer nach einem Timeout zum Neustart der Synchronisation
auffordern.
4.10.4
Realisierung
Hauptseite
Die Synchronisierung wird vom Benutzer durch Aufruf einer PHP-Seite in einem neuen Frame
aus der Client-Software gestartet. Diese Seite überprüft, in welchem Zustand sich die Synchronisation befindet. Wurde eine Synchronisation vollständig abgeschlossen, so wird eine neu
Synchronisation gestartet. Befindet sich eine Synchronisation in Arbeit, so wird festgestellt, ob
diese Fortgesetzt werden soll. Falls die laufende Sychronisation in einem anderen Frame oder
Browser läuft, so wird eine Wartemeldung ausgegeben. Entsprechend diesen Entscheidungen
wird bei Bedarf eine Seite des geweiligen Teilschrittes der Synchronisation, genannt Phase
eingebunden. Andernfalls wird eine Entsprechende Fehler- oder Wartemeldung ausgegeben.
Phase 0: Verbindung herstellen
Diese Phase stellt die erste Verbindung zum Server her. Dazu wird zuerst ein Server aus der
Datenbank ausgewählt. Dies erfolgt zu Lastverteilung zufällig gewichtet nach einer Priorität
der Server. Das heißt jedem Server wird vom Supportpersonal eine Priorität von 1 bis 9 zugewiesen. Diese Zahl drückt die Geschwindigkeit der Internetverbindung und die Leistung des
Servers aus. Größere Zahlen entsprechen mehr Leistung. Proportional zu dieser Zahl stigt die
Wahrscheinlichkeit mit der ein Server gewählt wird. Server in der Datenbank, die mit der
Zahl 0 als Backup-Server eingetragen sind, werde nie zur Sychronisation ausgewählt.
Nach der Auswahl eines Server wird versucht mit diesem eine Verbindung herzustellen, indem die Daten “ping“ gesendet werden. Der Server antwortet daruf mit den Daten ”pong“.
Dies stellt einen erfolgreichen Verbindungstest dar, und der Datentransfer kann in der nächsten Phase ausgführt werden. Antwortet der Server nicht, so wird bis zu 5 mal ein anderer
zufälliger Server ausgewählt und der gleiche Verbindungstest durchgeführt. Endet keiner der 5
Verbindungsversuche erfolgreich, so wird dem Benutzer mitgeteilt, dass die Verbindung nicht
hergestellt werden kann und die Synchronisation wird abgebrochen.
Brandstätter Andreas, Klaffl Christoph
Seite 101von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Phase 1: Daten senden
In dieser Phase werden am Client alle Daten aus der Datenbank selektiert, die seit der letzten
vollständigen Synchronisation eingetragen wurden. Die werden in jener Reihenfolge gesendet,
dass keine Foreign-Key-Probleme auftreten. Das heißt es wird mit Daten begonnen, von denen
keine weiteren Daten abhängen. Diese werden an den Server gesendet. Am Server wird für
jeden Datensatz geprüft ob dieser vom Client verändert werden darf. Für jede Tabelle ist
in der Datenbank gespeichert, ob Daten daraus vom Client angenommen werden. Werden
vom Client Datensätze gesendet, die nicht in die Datenbank eingetragen werden dürfen, so
wird eine Fehlermeldung abgespeichert. Dies ist zum Beispiel der Fall wenn Benutzerdaten
gesendet werden, denn diese dürfen am Client nicht verändert werden.
Verläuft diese Prüfung positiv, so werden die Daten in die Datenbank des Servers eingetragen.
Ebenso wird die Änderungszeit auf die aktuelle Zeit gesetzt. Dies ist erforderlich um die
Synchronierung der Datensätze mit den anderen Servern und anderen Clients zu ermöglichen.
Die Zeit würde andernfalls in vor der letzten Synchronisation mit anderen Servern liegen und
diese würden den Datensatz bei den nächsten Synchronisationen nicht erhalten.
Phase 2: Tabellen abgleichen
Beim abgleichen der Tabellen werden am Client die gesamten Tabellenstrukturen zusammengefasst und an den Server übertragen. Der Server verlgleicht die Struktur jeder Tabelle mit der
Struktur Client. Wird ein Unterschied festgestellt, so werden die über Foreign-Keys abhängenden Tabellen rekursiv ermittelt. Dem Client werden daraufhin die Befehle zum löschen all
dieser Tabellen, beginnen mit jenen von denen keine weiteren Tabellen abhängen, übermittelt. Anschließend werden in gleicher Reihenfolge die Befehle zum neu erstellen der Tabellen
übertragen. Als letztes, in ebenfalls gleicher Reihenfolge, die kompletten Daten der Dateien.
Bei dieser Übermittlung wird ebenfalls geprüft, ob der Client berechtigt ist die Struktur bzw.
die Daten der Tabelle zu erhalten. Beispielsweise wird die Tabelle der Verbindungsschlüssel
nicht an die Clients übertragen.
Phase 3: Daten holen
In dieser Phase sendet der Client an den Server die Anfrage, Daten zu holen. Der Server selektiert daraufhin in allen Tabellen die Daten, die neuer als das Datum der letzten vollständigen
Synchronisierung sind. Es wird hierbei ebenfalls geprüft welche Daten gemäß einer Berechtigungstabelle auf den Client übertragen werden. Diese Daten werden anschließend in einer
temporären Datei zwischengespeichert. Danach werden je 100 Datensätze an den Client übertragen. Sind mehr Daten in der temporären Datei vorhanden, so wird der Client aufgefordert
eine erneute Anfrage zu senden. Nach dem Senden der lezten Daten wird die temporäre Datei
am Server gelöscht.
Am Client werden die Daten in die Datenbank eingefügt. Hier ist keine Prüfung der Daten
erforderlich, da Daten die vom Server übertragen werden als Richtig anzusehen sind.
Brandstätter Andreas, Klaffl Christoph
Seite 102von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Phase 4: Synchronisation abschließen
Als letzte Phase wird am Client das Datum der vollständigen Sychronisation abgespeichert.
Dem Benutzer wird die Meldung ausgegeben, dass die Synchronisation abgeschlossen ist. Der
Benutzer wird aufgefordert das Synchronisationsfenster zu schließen.
Phase 5: Synchronisation bereits fertig
Wird die Seite vom Benutzer durch Druck auf F5“ oder durch klicken auf Aktualisieren“
”
”
aktualisiert, so wird die Phase nach der letzten normalen Phase geladen. Dem Benutzer wird
daraufhin die Meldung ausgegeben, dass die Synchronisation bereits abgeschlossen ist. Der
Benutzer wird aufgefordert das Synchronisationsfenster zu schließen.
4.10.5
Umsetzung
cURL-Funktion
Um Anfragen an den Server zu senden und Daten von diesem zu empfangen wird cURL bzw.
libcurl verwendet.
PHP unterstützt libcurl, eine Bibiothek entwickelt von Daniel Stenberg, die es erlaubt sich
”
mit Servern zu verbinden und über diverse Protokolle zu kommunizieren.“ [4]
Eine eigene Funktion übernimmt die Einstellung aller Parameter für cURL sowie die Behandlung von Fehlern bei der Übertragung. Da diese Funktion einen fundamentalen Bestandteil
der Client-Server-Synchronisation darstellt wird diese hier aufgeführt. Die Funktion sendet
die Daten an den Server und empfängt die Daten, welche der Server zurücksendet.
1
2
3
4
5
6
/**
* Fragt eine Server-Seite ueber CURL ab.
*
* @param array $post Daten, die per POST uebergeben werden.
* @param int $phase Arbeitsschritt, der aktuell abgearbeitet wird.
* @param string $server Servername, auf den die Anfrage ausgefuehrt
wird.
@return
array Inhalt der Seite und eventuell aufgetretene Fehler.
*
*/
←-
7
8
9
10 function get_server_page($post = array(), $phase, $server = "euklid- ←server")
11 {
12 // Synchronisationsdaten laden
13
$this_sync_vorgang = get_this_sync_vorgang();
14
Brandstätter Andreas, Klaffl Christoph
Seite 103von 231
ALFSA
15 //
16
17
18
19
20
21
22 //
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
//
//
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Daten des Servers aus der Datenbank holen
$server = get_server($server);
echo "Verbunden mit Server: ".$server["name"]."(".$server[" ←hostname"].")<br />";
flush();
$server = $server["hostname"];
flush();
Die Session mit URL initialisieren
$ch = curl_init("https://".$server."/aaron/server-www/client-sync ←/");
Session Optionen setzen
Wenn ein Proxy in Konfigurationsdatei vorhanden, Proxy setzen
if(PROXY_STRING != "")
curl_setopt($ch, CURLOPT_PROXY, PROXY_STRING);
//
Header nicht in die Ausgabe aufnehmen
curl_setopt($ch, CURLOPT_HEADER, 0);
// User-Agent-Feld (Browserkennung) im HTTP Header
curl_setopt($ch, CURLOPT_USERAGENT, "ALFSA sync agent");
// gibt Transfer zurueck, anstatt Ausgabe vorzunehmen
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// Peerueberpruefung von HTTPS setzen
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
// Hostueberpruefung von HTTPS setzen
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
// Timeout der Verbindung
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
//
POST-Parameter setzen
$postValues = "";
// Datum der letzen vollstaendigen Synchronisation
$posts = array( "last_date" => read_end_date(),
// Datum der aktuellen Synchronisation
"this_date" => $this_sync_vorgang["start_date"],
// aktuelles Datum
"current_date" => time(),
// Feuerwehrnummer der Fuellstelle
"fwnr" => FUELLSTELLE,
// Laufnummer des Clients
"client" => CLIENT,
// aktuelle Phase (Arbeitsschritt)
"phase" => intval($phase),
// Pruefsumme der Daten und Verbindungskennung
"chksum" => md5($post["data"]."|".CONNECTION),
// Zufallsdaten um Caching zu vermeiden
Brandstätter Andreas, Klaffl Christoph
Seite 104von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
61
"rand" => md5(rand(0,1000)."|".time()));
62
$posts = array_merge($posts, $post);
63
// POST-Daten urlencodieren
64
foreach($posts AS $name => $value)
65
if(!empty($value) || $name == "phase")
66
$postValues .= urlencode($name)."=".urlencode($value).’&’;
67
$postValues = substr($postValues, 0, -1);
68
// POST-Daten setzen
69
curl_setopt($ch, CURLOPT_POSTFIELDS, $postValues);
70
71 // Ausfuehren der CURL-Aktion
72
$result = curl_exec($ch);
73
74 // Ergebnis als globale Variable fuer Debugzwecken zur Verfuegung ←stellen
75
global $raw_result;
76
$raw_result = $result;
77
78 // Fehlercodes als globale Variable importieren
79
global $error_codes;
80
$this_error = FALSE;
81
$codes = "";
82 // Auftreten von Fehlercodes pruefen
83
foreach($error_codes as $error)
84
if(strstr($result, $error["code"]))
85
{
86
$result = str_replace($error["code"], "", $result);
87
$codes .= $error["code"];
88
89
if($error["error"])
90
$this_error = $error["code"];
91
echo $error["text"]."<br />";
92
}
93
94 // wenn Debug aktiviert ist, Ergebnis ausgebe
95
if(SYNC_DEBUG)
96
echo "<pre>### html-rueckgabe ###\r\n".$result."\r\n</pre>";
97
98 // wenn Ergebnis leer ist, auf CURL-Fehler pruefen und ggf ausgeben
99
if(empty($result))
100
{
101
if(strlen(curl_error($ch)) > 5)
102
echo "<b>CURL-Fehler: ".curl_error($ch)."</b><br />";
103
104
$codes .= "[=curl]";
105
$this_error = "[=curl]";
106
}
107
Brandstätter Andreas, Klaffl Christoph
Seite 105von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
108 // CURL-Session beenden
109
curl_close($ch);
110
111 // Ergebnis der Anfrage und ggf Fehler zurueckgeben
112
return array("result" => $result, "error" => $this_error, "codes"
=> $codes);
113 }
←-
Listing 4.44: PHP Funktion zum Senden von Daten an der Server und Empfangen von Daten
Verbindungsschlüssel
Zur Überprüfung der Authentizität des Clients wird ein Verbindungschlüssel eingesetzt. Dieser Schlüssel wird einmalig vom Supportpersonal zufällig generiert und an den Verwalter des
Clients schriftlich übermittelt. Dieser trägt den Schlüssel in die Grundkonfiguration des Clients ein. Dieser Schlüssel wird bei jeder Übertragung verwendet um eine Checksumme mit
den Daten zu bilden.
Beispiel für einen Verbindungsschlüssel (aus Sicherheitsgründen wurde dieser verändert):
1
N5D40-FOEBA-MRCIX-VR95O-UQKP1
Listing 4.45: Beispiel für einen Verbindungschlüssel
Einem möglichen Angreifer, der Daten in das System einschleusen will, ist der Schlüssel nicht
bekannt und es ist ihm so nicht möglich eine korrekte Checksumme zu erzeugen. Dieser Fehler
wird vom Client erkannt und die Daten, die der Angreifer in das System einschleusen wollte
werden nicht in die Datenbank eingetragen. Es ist dem Angreifer durch Abfangen von korrekten Daten von Clients auch nicht möglich den Verbindunsschlüssel zu berechnen.
Der Verbindungschlüssel stellt somit sicher, dass nur Authentische Daten am Server engegengenommen und in die Datenbank eingetragen werden.
Folgender Codeteil erstellt die Checksumme am Client (die Variable $post[“data“] enthält die
Daten, die Konstante CONNECTION enthält den Verbindungschlüssel):
1
md5($post["data"]."|".CONNECTION);
Listing 4.46: PHP Code zur Erstellung der Checksumme mit Verbindungschlüssel
Folgender Codeteil Prüft die Checksumme am Server (die Variable $ POST[“chksum“] enthält
die Cecksumme, die vom Client übermittelt wurde, die Variable $ POST[“data“] enthält die
Daten vom Client, die Variable $row[“kennung“] enthält den Verbindungschlüssel aus der
Datenbank):
Brandstätter Andreas, Klaffl Christoph
Seite 106von 231
ALFSA
1
2
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
if($_POST["chksum"] != md5($_POST["data"]."|".$row["kennung"]))
die("[=chkerr]");
Listing 4.47: PHP Code zur Prüfung der Checksumme mit Verbindungschlüssel
Browser-Abfrage
Die Daten vom Client zum Server und vom Server zum Client werden über normalen Webtransfer übertragen. Der URL, der hiezu verwendet wird, könnt auch in einem normalen
Browser geöffnet werden. Um dies zu verhindern wird in PHP der User-Agent überprüft. Der
User-Agent-Wert ist die Kennung des Browsers und wird bei der HTML-Anfrage übertragen.
Durch Abfragen dieses Wertes kann weitestgehend verhindert werden, dass normale Browser
auf diese Seite zugreifen. Vom Client wird eine spezielle Kennung als User-Agent gesendet:
ALFSA sync agent“.
”
Folgender Codeteil weist CURL an den speziellen User-Agent zu senden:
1
curl_setopt($ch, CURLOPT_USERAGENT, "ALFSA sync agent");
Listing 4.48: PHP Code zur Übertragung des User-Agent
Folgender Codeteil überprüft am Server den User-Agent:
1
2
3
4
5
6
7
8
if($_SERVER["HTTP_USER_AGENT"] != "ALFSA sync agent")
{
append_to_log("user agent", "wrong user agent dedected: ".$_SERVER[ ←"HTTP_USER_AGENT"], "critic");
die( ’You are not allowed to show this page directly!<br />’."\n".
’go to: <a href="http://www.bfkdo-tulln.at/alfsa/">ALFSA - ←webpage</a><br />’."\n".
’<br />’."\n".
’[=agerr]’);
}
Listing 4.49: PHP Code zur Prüfung des User-Agent
4.10.6
Sequenzdiagramm
Dieses Sequenzdiagramm stellt den Ablauf der Client - Server Synchronisation dar.
Brandstätter Andreas, Klaffl Christoph
Seite 107von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Abbildung 4.9: Sequenzdiagramm
4.10.7
Fehlerbehandlung
Um eine einwandfreie Funktion der Sychronisation sowie fehlerhafte Daten zu vermeiden
müssen eine vielzahl an möglicher Fehler erkannt und entsprechend behandelt werden. Nachfolgend soll ein kleiner Teil der möglichen Fehler dargestellt und erläutert werden.
Brandstätter Andreas, Klaffl Christoph
Seite 108von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Falscher Verbindungsschlüssel
Ein falscher Verbindungs Verbindungsschlüssel kann entweder vorliegen, wenn ein Client nicht
berechtigt ist Daten beim Server einzutragen und daher dem Benutzer des Clients kein gültiger Verbindungsschlüssel bekannt ist, oder wenn der Verbindungsschlüssel falsch eingegeben
wurde.
In beiden Fällen verhindert der Server das Eintragen der Daten in die verteilte Datenbank.
Diese funktioniert nach folgendem Prinzip. Der Client berechnet eine Checksumme der Daten:
checksum-client = checksumme(Daten + Verbindungsschlüssel)
Auch der Server berechnet die Checksumme der Daten:
checksum-server = checksumme(Daten + Verbindungsschlüssel)
Somit sind checksum-client und checksum-server gleich, und die Daten des Clients werden
angenommen und eingetragen.
Wurde jedoch am Client ein falscher Verbindungschlüssel eingetragen, so wird dies wie folgt
erkannt.
Der Client berechnet eine Checksumme der Daten:
checksum-client = checksumme(Daten + falscher Verbindungsschlüssel)
Auch der Server berechnet die Checksumme der Daten:
checksum-server = checksumme(Daten + Verbindungsschlüssel)
Somit sind checksum-client und checksum-server ungleich und der Server erkennt den Fehler
und verweigert die weitere Verbindung.
Datenmanipulation
Werden durch einen Dritten während der Synchronisation Daten manipuliert, wird dies ebenfalls durch die Checksumme des Verbindungsschlüssels erkannt. Der Server erkennt diese Manipulation wie einen falschen Verbindungsschlüssel und verweigert ebenfalls die eingabe der
Daten. Diese funktioniert nach folgendem Prinzip.
Der Client berechnet eine Checksumme der Daten:
checksum-client = checksumme(Daten + Verbindungsschlüssel)
Ein Dritter ersetzt die Daten durch manipulierte Daten.
Auch der Server berechnet die Checksumme der Daten:
checksum-server = checksumme(manipulierte Daten + Verbindungsschlüssel)
Somit sind checksum-client und checksum-server ungleich und der Server erkennt den Fehler
und verweigert die weitere Verbindung.
Serverausfall
Fällt ein Server der verteilten Datenbank aus, so muss der Client dies erkennen und einen anderen Server für die Synchronisation wählen. Dies wird dadruch sichergestellt, dass der Client
zuerst einen zufälligen Server auswählt. Danach wird im Arbeitsschritt 1 der Synchronisation
eine Verbindung herzustellen. Schlägt dies nach einem Timeout fehl, wird ein anderer zufälliBrandstätter Andreas, Klaffl Christoph
Seite 109von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
ger Server ausgewählt.
Nach fünf erfolglosen Verbindungsversuchen wird davon ausgegangen, dass die Internetverbindung des Clients fehlerhaft ist und dem Benutzer wird eine Fehlermeldung ausgegeben.
Verbindungsabbruch
Bricht während der Synchronisation die Verbindung zum Server ab, wird dies durch einen
Timeout erkannt. Es kann davon ausgegangen werden, dass es sich um einen kurzzeitigen
Ausfall handelt, und die Verbindung innerhalb einiger Zeit wieder verfügbar ist. Daher wird
versucht durch erneutes Abragen der Serverseite die Synchronisation weiterzuführen. Der Benutzer hat die möglichkeit dies abzubrechen und eine neue Synchronisation mit gegebenenfalls
einem anderen Server zu starten.
Abbruch durch Benutzer
Bricht der Benutzer die Synchronisation ab, so wird dies bei einem Neustart erkannt. Es
wird versucht die abgebrochene Synchronisation fortzusetzen. Ist dies aufgrund verschiedener
Umstände (z.b. gleicher Server nicht erreichbar) nicht möglich, so wird eine neue Synchronisation gestartet und vollständig durchgeführt.
4.11
Webinterface
4.11.1
Übersicht
Die Struktur des Webinterfaces wird durch folgende Dateiübersicht veranschaulicht:
Brandstätter Andreas, Klaffl Christoph
Seite 110von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Abbildung 4.10: Dateiübersicht
Da die Dateiliste zu umfangreich ausfällt sind in der Abbildung 4.10 nicht alle Dateien angeführt, deshalb wird hier auf den Anhang verwiesen, der eine komplette Dateiliste mit der
Beschreibung enthält, Kapitel 9.3 auf Seite 213.
4.11.2
index.php
Jeglicher Zugriff auf einzelne Komponenten, wie zum Beispiel der Benutzerverwaltung, wird
durch die index.php“ Datei geregelt. Über den GET Parameter page“ wird der index.php“
”
”
”
Datei mitgeteilt welche Seite gewünscht wird. Falls keine Seite angegeben wird, kommt man
zu der Hauptseite, wo grundlegende Systeminformationen angezeigt werden. Weiters überBrandstätter Andreas, Klaffl Christoph
Seite 111von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
prüft sie ob der Benutzer eingeloggt ist oder nicht, bei letzteres wird der Zugriff auf jegliche
Seiten verweigert und die Login Maske angezeigt. Darüberhinaus ist sie für folgende Aufgaben
zuständig:
• Überprüfen ob die das PHP Skript von der Konsole oder über den Apache Web Server
ausgeführt wird
• Überprüfen ob ausreichende Berechtigungen für die Konfigurationsordner bestehen
• Überprüfen der Konfigurationsdateien
• Aufbauen und einstellen der lokalen Datenbankverbindung
• Laden der benötigten Libraries
4.11.3
Template Engine
Eine Template-Engine ist eine Software, die Templates (Vorlagen) mit Platzhaltern verarbeitet und mit Inhalt füllt. So ist es möglich die Daten und das Layout mit Design komplett
zu trennen. Außerdem können Templates leicht ausgetauscht werden und somit das Layout komplett geändert werden ohne die Funktion, Sicherheit oder das Programm ändern zu
müssen. Templates können außerdem von versierten Benutzern selbst verändert werden, um
das Programm persönlichen Bedürfnissen anzupassen.
Grundlegende Verwendung
Die Verwendung der Template-Engine ist denkbar einfach. Mit dem Konstruktor wird das
Template aus der Template-Datei geladen und erstellt. Die Funktion set“ wird verwendet
”
um Werte zu setzen. Mit der Funktion display“ wird das Ergebnis ausgegeben.
”
1
2
3
4
$test = new Template("template_name");
$test->set("variable", "gesetzter wert");
// hier diverse Ersetzungen eintragen...
$test->display();
Listing 4.50: Grundlegende Verwendung - PHP-Datei
1 Hello world
2 {variable}
Listing 4.51: Grundlegende Verwendung - Template-Datei
Dieses Beispiel ergibt folgendes Resultat:
Brandstätter Andreas, Klaffl Christoph
Seite 112von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
1 Hello world
2 gesetzter wert
Listing 4.52: Grundlegende Verwendung - HTML-Ergebnis
4.12
Tests
Zur Gewährleistung der Funktion der Software wurden verschiedene Tests ausgeführt. Im Wesentlichen waren dies Funktionstests während der Entwicklung. Spezielle Tests wurden nur in
Bezug auf kritische Programmteile ausgeführt.
Im Allgemeinen soll gesagt werden, dass vor einem Einsatz der Software durch die Feuerwehren im Bezirk Tulln ein Probebetrieb in einigen Feuerwehren stattfinden wird. Imzugedessen
wären erst Tests in realistischem Umfeld möglich. Die der Start des Probebetriebs wird jedoch
erst nach Abschluss dieser Diplomarbeit durchgeführt. Daher wurden keine so umfangreichen
Tests durchgeführt, wie es vor einem Produktiveinsatz von jeglicher Software erforderlich
wäre.
4.12.1
Test des Webinterfaces
Da das Webinterface den weniger komplexen Teil der Diplomarbeit darstellt, gestalteten sich
die Tests desselben relativ einfach. Daten wurden in verschiednenen Browsern eingegeben, modifiziert und abgefragt. Dabei konnte festgestellt werden, dass die Darstellung in den verschiedenen Browsern trotz intensivster Bemühungen nicht komplett gleich ist. Trotzdem konnte
einen einwandfreie Funktion in den häufigsten Browsern festgestellt werden.
4.12.2
Test der Server - Server Synchronisation
Die Server - Server Synchronisation wurde großteils in der laufenden Entwicklung getestet.
Es wurden laufen Daten durch die Clients auf verschiedenen Servern eingefügt. Die Server
mussten daher diese Daten untereinander Synchronisieren. Diese Tests verliefen unter sehr
realistischen Umständen, da die Internetverbindung teilweise durch den Proxy der Schule
unterbrochen war, oder andere Störungen vorlagen. Weiters wurde auch die übernahme von
verschiedenen Tabellenstrukturen ausgiebig getestet, denn die Struktur der Datenbank wurde
oftmals modifiziert. Bei diesen Tests konnte eine gute und zuverlässige Funktion der Synchronisation nachgewiesen werden.
Brandstätter Andreas, Klaffl Christoph
Seite 113von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Langzeittest
Da sich die wesentlichen Kernelemente der Sychronisation während der Entwicklung seit etwa Dezember nicht verändert haben, kann ein Langzeittest der Sychronisationskomponenten
aufgewiesen werden. Denn die 3 Entwicklungsserver an den geografisch getrennten Orten
waren seit beginn der Entwicklungsarbeiten durchgehend in Betrieb und führten stetig Syhcronisationen durch. Während dieser Zeit traten natürliche Ereignisse wie Internetausfälle,
Stromausfälle o. ä. auf und sorgten für realistische Testbedingungen. Während der gesamten
Zeitdauer konnte festgestellt werden, dass die Sychronisationsalgorithmen durchaus stabil und
zuverlässig arbeiten.
4.12.3
Test der Client - Server Synchronisation
Wesentliche Tests der Client - Server Synchronisation wurden durch Einfügen von Daten
auf einem Client, sychronisieren, und Auswerten der Daten auf einem anderen Client durchgeführt. Dabei konnte bei Abschließenden Tests festgestellt werden, dass die Synchronisation zuverlässig funktioniert. Weiters wurden Verbindungsabbrüche, Serverausfälle und Netzwerkstörungen simuliert. Dabei konnte großteils ein erwartungsgemäßes Verhalten festgestellt
werden. Weiters wurden am in der Server-Datenbank um Zuge der Entwicklung mehrmals die
Datenbankstruktur verändert. Die Synchronisation dieser Änderung funktionierte ebenfalls
wie erwartet.
4.12.4
Pre-Alpha Development-Test
Im Zuge einer Atemschutzübung meherer Feuerwehren in Sieghartskirchen konnte das komplette System im Produktivbetrieb getestet werden. Hierbei wurde bei einem Atemschutzkompressor ein zur Verfügung gestelltes Notebook mit der Software platziert. Damit wurden
die Füllungen erfasst und mehere Sychronisationsvorgänge über UMTS durchgeführt. Alle
beteiligten Feuerwehren waren von der Funktion des Systems begeistert. Seitens des Entwicklunsteams konnte festgestellt werden, dass keine Fehler auftraten.
4.13
Verwendete Hilfsmittel
4.13.1
Verwendete Software
Zur Entwicklung wurde folgende Software als Arbeitswerkzeuge verwendet:
• Debian (http://www.debian.org/)
Brandstätter Andreas, Klaffl Christoph
Seite 114von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
• Ubuntu (http://www.ubuntu.com/)
TM
• Microsoft
Windows (http://www.microsoft.com/windows/)
• Eclipse (http://www.eclipse.org/)
• Kile (http://kile.sourceforge.net/)
• LATEX(PDFLaTeX) (http://www.pdftex.org/)
• Firefox (http://www.mozilla-europe.org/de/products/firefox/)
• Opera (http://de.opera.com/)
• Konqueror (http://konqueror.kde.org/)
• Iceweasel (http://www.geticeweasel.org/)
• Internet Explorer (http://www.microsoft.com/windows/)
• Corel Draw / Corel PhotoPaint (http://www.corel.com/)
TM
• Microsoft
Visio (http://office.microsoft.com/)
• Dia (http://www.gnome.org/projects/dia/)
• OpenOffice (http://de.openoffice.org/)
• Evolution (http://www.gnome.org/projects/evolution/)
• Thunderbird (http://www.mozilla-europe.org/de/products/thunderbird/)
• evince (http://www.gnome.org/projects/evince/)
• KPDF (http://kpdf.kde.org/)
• Pidgin (http://pidgin.im/)
• Skype (http://www.skype.com/intl/de/)
• medit (http://mooedit.sourceforge.net/)
• gedit (http://www.gedit.org)
• mcedit (http://www.gnome.org/mc/)
• PuTTY (http://www.putty.org/)
• MySQL GUI Tools (http://dev.mysql.com/downloads/gui-tools/5.0.html)
• LeechFTP (http://www.leechftp.de/)
• OpenSSH Client (http://www.openssh.com/)
• MySQL Kommandozeilenclient (http://www.mysql.de/)
Brandstätter Andreas, Klaffl Christoph
Seite 115von 231
ALFSA
KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG
Der Großteil dieser aufgelisteten Software ist OpenSource. Jene Programme, die nicht frei
verfügbar (wie zum Beispiel Corel Draw) sind, wurden auf Computersystemen der Schule mit
zugehöriger Schullizenz verwendet.
4.13.2
Allgemeine Quellen
Neben den gesondert zitierten Quellen wurden folgende Nachschlagewerke und Referenzen
zur Informationsbeschaffung verwendet:
• MySQL Referenzhandbuch
http://www.mysql.de/
• PHP Funktionsreferenz
http://at.php.net/
• Freie Enzyklopedia
http://de.wikipedia.org/
• Apache Referenz
http://www.apache.org/
• Bibliothek mit vielen freien Handbüchern
http://www.galileocomputing.de/
Brandstätter Andreas, Klaffl Christoph
Seite 116von 231
ALFSA
Teil III
Wirtschaftlicher Teil
Brandstätter Andreas, Klaffl Christoph
Seite 117von 231
ALFSA
KAPITEL 5. ALLGEMEINES
Kapitel 5
Allgemeines
Zur wirtschaftlichen Betrachtung der Diplomarbeit wird die Scheinfirma FRED Softwareentwicklung herangezogen.
5.1
Die Firma FRED
FRED Softwareentwicklung sieht sich als dynamisches Unternehmen auf dem Sektor der
Entwicklung von innovativer Software. Die Schwerpunkte liegen im Bereich vernetzer Softwarelösungen, Webapplikationen und Datenbankanwendungen. Die Firma FRED entwickelt
kundenspezifische Programme und Software verschiedenster Branchen und Anwendungsgebiete.
5.2
Das Produkt ALFSA
ALFSA stellt das Kern- und Referenzprodukt von FRED dar. Diese Softwarelösung stellt eine
Verwaltungsumgebung für Altemluftflaschen und Geräte dar. Es bietet alle Funktionen von
einfacher Verwaltung der Füllungen und Mängel über die Erfassung Prüfungen und Wartungen bis hin zu einem Update- und Nachrichtensystem.
Das Programm ist in einer Netzwerkstruktur aufgebaut und stellt so für eine Vielzahl von Anwendern die gleichen Daten austauschbar zur Verfügung. Gleichzeitig ist durch diese Struktur
eine maximale Sicherheit der Daten gegen Verlust und Manipulation gegeben. Die Software
wird primär von Feuerwehren eingesetzt, ist aber daurchaus auch für Taucher oder ähnliche
Anwender geeignet. Im Umgang mit Pressluftflaschen gelten strenge gesetzliche Vorschriften
in Bezug auf Dokumentation und Kontrolle. ALFSA kann im Feuerwehrdienst langwierige
und umständliche Auszeichnungen, die bisher in Papierform geführt wurden ablösen.
Brandstätter Andreas, Klaffl Christoph
Seite 118von 231
ALFSA
KAPITEL 5. ALLGEMEINES
Die Software wurde als Open Source - Projekt entwickelt und wird auch als solches verbreitet.
Das heißt, dass jedermann das Programm unter Einhaltung der GPL (General Public License)
frei beziehen, verwenden und weitergegeben darf. Ferner ist es jedem gestattet das Programm
selbst zu modifizieren und weiter zu entwickeln.
5.3
General Public Liecense GPL
Die General Public Liecense ist eine Lizenz, für freie Software. Sie gewährt jedermann im vier
Freiheiten als Bestandteile der Lizenz:
1. Das Programm darf ohne jede Einschränkung für jeden Zweck genutzt werden. Kommer”
zielle Nutzung ist hierbei ausdrücklich erlaubt.
2. Kopien des Programms dürfen kostenlos oder auch gegen Geld verteilt werden, wobei der
Quellcode mitverteilt oder dem Empfänger des Programms auf Anfrage zum Selbstkostenpreis
zur Verfügung gestellt werden muss. Dem Empfänger müssen dieselben Freiheiten gewährt
werden – wer z. B. eine Kopie gegen Geld empfängt, hat weiterhin das Recht, diese dann
kommerziell oder auch kostenlos zu verbreiten. Lizenzgebühren sind nicht erlaubt. (...)
3. Die Arbeitsweise eines Programms darf studiert und den eigenen Bedürfnissen angepasst
werden.
4. Es dürfen auch die gemäß Freiheit 3 veränderten Versionen des Programms unter den Regeln
von Freiheit 2 vertrieben werden, wobei dem Empfänger des Programms der Quellcode der
veränderten Version verfügbar gemacht werden muss. (...)“ [6]
Aus diesen Grundprinzipien der Lizenz wird deutlich, dass das Programm nicht verkauft wird.
Vielmehr ist es üblich, dass Firmen, die Software entwickeln und nach der GPL veröffentlichen, kostenpflichtigen Support anbieten. Auch FRED Softwareentwicklung bietet Support
von ALFSA an.
Brandstätter Andreas, Klaffl Christoph
Seite 119von 231
ALFSA
KAPITEL 6. KOSTENRECHNUNG
Kapitel 6
Kostenrechnung
6.1
Kalkulation
Nachfolgend werden die Kosten der Firma FRED Softwareentwicklung kalkuliert.
6.1.1
Kalkulation der Fixkosten
Die Fixkosten gliedern sich wie folgt:
Kosten für Hardware:
Anzahl
2
4
2
3
3
Bezeichnung
Einzelpreis
Notebook 17 Zoll
4.000 e
Bildschirm TFT 30 Zoll
4.000 e
Desktop-Computer
2.000 e
Server IBM oder Sun (4HE)
10.000 e
USV für Server 5kVA (5HE)
3.000 e
Hardware-Gesamt
Gesamtpreis
8.000 e
16.000 e
4.000 e
30.000 e
9.000 e
67.000 e
Tabelle 6.1: Hardware
Kosten für Miete und Diverses:
Brandstätter Andreas, Klaffl Christoph
Seite 120von 231
ALFSA
Anzahl
1
1
3
1
KAPITEL 6. KOSTENRECHNUNG
Bezeichnung
Internetzugang für 1 Jahr
div. Kommunikationskosten
Server-Housing incl. Internet für 1 Jahr (10HE)
Bürofläche für 1 Jahr (150qm)
Miete und Diverses-Gesamt
Einzelpreis Gesamtpreis
1.000 e
1.000 e
2.000 e
2.000 e
6.000 e
18.000 e
25.000 e
25.000 e
46.000 e
Tabelle 6.2: Miete und Diverses
Kosten für Arbeitszeit der Entwickler:
Anzahl Bezeichnung
Einzelpreis Gesamtpreis
550 Arbeitszeit pro Stunde
120 e
66.000 e
Arbeitszeit-Gesamt
66.000 e
Tabelle 6.3: Arbeitszeit
Gesamten Fixkosten:
Bezeichnung
Hardware
Miete und Diverses
Arbeitszeit
Fixkosten-Gesamt
Kosten
67.000 e
46.000 e
66.000 e
179.000 e
Tabelle 6.4: Fixkosten
Die gesamten Fixkosten der Firma FRED belaufen sich somit auf 179.000 Euro.
6.1.2
Kalkulation der variablen Kosten
Die Software wird gemäß der GPL im Internet veröffentlicht. Das Projekt wird so einer weltweiten Community zugänglich gemacht und zur Verfügung gestellt. Daraus ergibt sich andererseits, dass unabhängig von der Anzahl der verbreiteten Kopien keine Kosten für die Firma
FRED auftreten.
Brandstätter Andreas, Klaffl Christoph
Seite 121von 231
ALFSA
6.2
KAPITEL 6. KOSTENRECHNUNG
Support
Da die Verbreitung der Software keine Finanzmittel zur Deckung der Kosten einbringen
können, müssen durch die Firma FRED Softwareentwicklung andere Dienstleistungen erbracht werden, um die Fixkosten zu Decken. Daher wird von der Firma FRED Softwareentwicklung als Entwickler von ALFSA Support desselben Produktes angeboten. Dies hat
für den Kunden den Vorteil, dass der Support durch diejenigen Techniker geleistet wird, die
aktiv das Programm entwickeln. Daher können Aufgaben und Lösungen von Problemen in
kürzester Zeit abgeschlossen werden.
Der Support von FRED Softwareentwicklung kann flexibel in Tageseinheiten angefordert
werden. Eine Tageseinheit umfasst 5 Arbeitsstunden um dem kundeneigenen EDV-Personal
genügend Zeit zu geben eventuell parallele Aufgaben zu bearbeiten.
6.2.1
Kalkulation der variablen Kosten
Die Support-Aufgaben verursachen außer der Arbeitszeit des Technikers keine weiteren Kosten. Daher beläuft sich eine Tageseinheit auf:
5 * 120 Euro = 600 Euro
6.2.2
Preiskalkulation
Aufgrund des hohen Ausbildungsstandes und der Spezialisierung auf dem Sektor der Datenbankentwicklung der Mitarbeiter der Firma FRED Softwareentwicklung kann für eine Tageseinheit Softwaresupport ein Preis von 2100 Euro angesetzt werden.
6.2.3
Break-Even-Point
Um die Fixkosten der Entwicklung von ALFSA zu decken müss eine bestimmte Mindestmenge
an Support geleistet werden. Diese wird folgend berechnet:
179.000 Euro / ((2.100 – 600) Euro / Tageseinheit) = ∼ 120 Tageseinheiten
Brandstätter Andreas, Klaffl Christoph
Seite 122von 231
ALFSA
KAPITEL 6. KOSTENRECHNUNG
Abbildung 6.1: Break-Even-Point
Das heißt, dass mehr als 120 Tageseinheiten Support geleistet werden müssen um einen Gewinn zu verzeichnen.
Brandstätter Andreas, Klaffl Christoph
Seite 123von 231
ALFSA
KAPITEL 7. MARKETING
Kapitel 7
Marketing
7.1
Marktanalyse
ALFSA wurde primär für die Verwendung in Niederösterreich entwickelt. Der Einsatz ist
jedoch nach Adaptierung in weiteren Gebieten möglich. Es werden folgender Zeitaufwand für
eine Modifikation geschätzt:
Österreich (je Bundesland) 150 Arbeitsstunden
Deutschland (Gundaufwand) 200 Arbeitsstunden
Deutschland (je Bundesland) 150 Arbeitsstunden
anderes Land (Sprachportierung) 200 Arbeitsstunden
anderes Land (Grundaufwand) 200 Arbeitsstunden
anderes Land (je Verwaltungseinheit) 150 Arbeitsstunden
Der Markt ist somit primär auf Niederösterreich beschränkt, jedoch nach entsprechender
Portierung nahezu weltweit.
7.1.1
Primäre Zielgruppe
Klare Zielgruppe des Produktes sind Feuerwehren. Es wird primär durch Feuerwehren bei der
Verwaltung von Atemluftgeräten eingesetzt. Insbesondere ist das Produkt für große Feuerwehren mit einer größeren Anzahl an Atemschutzgeräten interressant, da bei diesen Feuerwehren
ein hoher Verwaltungaufwand der Geräte anfällt. Auch für Feuerwehren mit überregionalen Füllstellen ist das Produkt bestens geeignet. Diese Feuerwehren sind zuständig für das
Befüllen von Atemschutzgeräten mehrerer Feuerwehren im Umkreis. Daher fällt auch bei diesen Feuerweheren ein hoher Verwaltungaufwand an und das Produkt ALFSA bringt erhebliche
Vorteile.
Brandstätter Andreas, Klaffl Christoph
Seite 124von 231
ALFSA
KAPITEL 7. MARKETING
In Österreich sind Feuerwehren je Bundesland organisiert. Daher stellen die einzelnen Landesfeuerwehrverbände die obersten Verwaltungebenen der Feuerwehren dar. Diese sind hinsichtlich einer landesweiten Verbreitung des Produktes ein erheblicher Teil der Zielgruppe.
Analog dazu stellen Feuerwehr-Verwaltungseinheiten anderer Länder auch mögliche Kunden
dar.
7.1.2
Sekundäre Zielgruppe
Neben Feuerwehren können diese Software auch Taucher oder andere Personen, die Pressluftflaschen verwenden benützen. Diese stellen somit eine sekundäre Zielgruppe dar. Insbesondere
seien hier Tauchvereine oder Tauchclubs genannt, die Anlagen zur Füllung von Pressluftflaschen betreiben.
7.2
Konkurrenzanalyse
Im deutschsprachigen Raum bietet eine nicht namentlich genannte Firma ein Produkt zur
Atemschutzgeräteverwaltung an.
Das Produkt dieser auf einer Microsoft-Datenbank und bietet die Möglichkeit zur Verwaltung
und Prüfung von Preßluftatmern, Masken und Lungenautomaten. Der Betrieb ist auf Einzelplätze beschränkt und die Arbeitsplätze können nicht wie bei ALFSA vernetzt werden. Somit
erfüllt dieses Konkurenzprodukt nicht die Spezifikation des Auftraggebers von ALFSA. Ein
weiterer Unterschied liegt darin, dass das Produkt dieser Firma nicht Open Source ist.
7.3
7.3.1
Marketing
Der Firmenname
Der Firmenname FRED wurde als Kunstname kreiert. Der Name lässt sich im deutsch- und
englischsprachigen Raum leicht aussprechen. Ferner beinhaltet er keine Umlaute und Sonderzeichen, um im Falle einer möglichen internationalen Expansion von FRED weltweit verwendet
werden zu können. Im Falle einer grafischen Darstellung des Firmennamens wird das R“ in
”
70% der Höhe der restlichen Buchstaben dargestellt. In rein textlichen Darstellungen entfällt
dieses Gestaltungsmerkmal.
Brandstätter Andreas, Klaffl Christoph
Seite 125von 231
ALFSA
7.3.2
KAPITEL 7. MARKETING
Das Firmenlogo
Als Firmenlogo wird der stilisierte Kopf eines Frosches verwendet. Darunter befindet sich der
Firmenname in grafischer Darstellung.
Abbildung 7.1: Das Firmenlogo
Das Logo soll die Dynamik und den Ideenreichtum der Firma FRED verdeutlichen. Das Logo
ist in den Grundfarben Rot, Grün und Blau gehalten. Wobei die Farbe grün dominiert und
die Frische und Lebendigkeit darstellt.
7.3.3
Das Produktlogo
Das Logo des Produktes zeigt eine Pressluftflasche in gelber Farbe mit einer Schwarz-Weißen
Flaschenschulter. Die Flasche gleicht dem typischen Aussehen der Pressluftflaschen, die in niederösterreichischen Feuerwehren eingesetzt werden. Auf der Flasche befindet sich der Striftzug
ALFSA - atemluftfüllstellenapplikation“.
”
Abbildung 7.2: Das Produktlogo
Auf der folgenden Seite wird das Logo in größerer Auflösung dargestellt.
Brandstätter Andreas, Klaffl Christoph
Seite 126von 231
ALFSA
7.3.4
KAPITEL 7. MARKETING
Logos - Corporate Design
Zur Wahrung des Corporate Design darf kein Logo nicht-proportional verzerrt werden. Weiters
darf es nicht beschnitten oder gedreht werden. Eine Veränderung der Farben (ausgenommen
in Graustufen für den Druck) ist nicht erlaubt. Bei jeder Abbildung des Logos gemeinsam
mit Text muss mindestens ein Zehntel der Diagonale des Logos als Rahmen um das Logo
frei bleiben, kein Text darf in diesen Bereich geschrieben werden. Die Logos dürfen nie in zu
kleiner Auflösung ( pixelig“) abgebildet oder gedruckt werden.
”
7.4
Werbung
Für ALFSA wird nur in seriösen und fachlich relevanten Medien geworben. Grundsätzlich
wird in den Werbebotschaften auf fachlich kompetente und seriöse Inhalte geachtet. Das kostenlose Produkt wird ebenso beworben wie der kostenplichtige Support desselben. Primär werden Werbauftritte auf Feuerwehrfachmessen, Feuerwehrzeitschriften und Feuerwehrwebseiten
platziert. Zur Abdeckung der sekundären Zielgruppe werden Anzeigen in Taucherzeitschriften
geschaltet.
7.4.1
Messen
Interschutz
Die Interschutz ist die größte Feuerwehrfachmesse im Deutschsprachigen Raum mit hohem
internationalem Ansehen. Diese Messe findet alle 5 Jahre in Leipzig statt. Im Jahr 2005 waren
1.385 Aussteller vertreten und 140.000 Menschen besuchten die Messe [10].
Stetiges Wachstum, Aussteller und Innovatioen aus der ganzen Welt sowie ein großes und
”
internationales Publikum - dies sind die Eigenschaften, die die INTERSCHUTZ auszeichnen.
Bereits seit vielen Jahren ist sie deshalb die weltweite Leitmesse für Rettung, Brand- / Katastrophenschutz und Sicherheit.“ [10]
Preis für Einen Messestand auf der Interschutz: 115 Euro/Quadratmeter (Eckstand, 2-seitig
offen)
Homepage der Messe: http://www.interschutz.de/
RETTER
Die Retter findet alle zwei Jahre in Wels statt und ist die größte Feuerwehrfachmesse österreichs. Im Jahr 2006 besuchten rund 14.000 Besucher diese Fachmesse.
Besucher aus Österreich und den benachbarten Ausland vor allem den neuen EU-Beitrittsländern
”
nutzen die Retter alle zwei Jahre diese hochwertige Fachmesse zum Erfahrungsaustausch, zur
Brandstätter Andreas, Klaffl Christoph
Seite 127von 231
ALFSA
KAPITEL 7. MARKETING
Informationsgewinnung und –entscheidung, aber auch als Treffpunkt. Entscheidungsträger aller Einsatz- und Rettungsorganisationen, Sicherheitsfachkräfte, Unternehmer und Arbeitsmediziner informieren sich alle zwei Jahre in Wels über Neuheiten, branchenspezifische Lösungen
und Services.“ [11].
Preis für Einen Messestand auf der Retter: 96 Euro/Quadratmeter (Eckstand, 2-seitig offen)
Homepage der Messe: http://www.rettermesse.at/
7.4.2
Feuer-Zeitschriften
BRANDAUS
Das Fachmagazin des Niederösterreichischen Landesfeuerwehrverbandes widmet sich Berichten um fachliche Neuerungen im Feuerwehrwesen, besonderen Einsätzen und verschiednen
Reportagen aus dem Feuerwehrwesen. Das Magazin erscheint monatlich mit einer Auflage
von 15.000 Exemplaren [12] und erreicht einen hohen Anteil größerer Feuerwehren in Niederösterreich.
Homepage der Zeitschrift: http://www.brandaus.at/
Feuerwehr Objektiv
Feuerwehr Objektiv ist ein unabhängige Feuerwehr-Fachmagazin mit 8 Exemplaren pro Jahr.
Schwerpunkte des Magazins sind Fachreportagen und technische Berichte von Neuerungen im
Feuerwehrwesen.
Homepage der Zeitschrift: http://www.feuerwehrobjektiv.at/
Die österreichische Feuerwehr
Die Zeitschrift Die österreichische Feuerwehr“ richtet sich an führende Mitglieder der öster”
reichischen Feuerwehren.
Das Magazin erscheint zwölf Mal jährlich mit einer Druckauflage von 5.000 Exemplaren.[13]
7.4.3
Feuer-Webseiten
www.wax.at
Die Webseite www.wax.at versteht sich als Portal für Feuerwehr und Rettungsdienst. Mit über
4300 registrierten Mitglieder ist es eines der größten österreichischen Foren für Feuerwehren
Brandstätter Andreas, Klaffl Christoph
Seite 128von 231
ALFSA
KAPITEL 7. MARKETING
und den Rettungsdienst.
Private Plattform mit aktuellen Berichten aus den Blaulichtorganisationen zur Information
”
der Mitarbeiter der Organisationen, der Bevölkerung und anderer Medien.“ [14]
Homepage: http://www.wax.at/
www.fireworld.at
Die Webseite www.fireworld.at stellt ebenfalls ein Portal für Feuerwehmitglieder mit Informationen, Diskussionen uvm. dar.
Diese Webseiten dienen also Informations- und Kommunikationsplattform für Feuerweh”
ren und deren Mitglieder. Vorwiegend zur Berichterstattung über das aktuelle Übungs- und
Einsatzgeschehen, neue Innovationen im Feuerwehrwesen und zur Kommunikation der Feuerwehren und derer Mitglieder untereinander.“[15]
Homepage: http://www.fireworld.at/
7.4.4
Taucher-Zeitschriften
Tauchen
Tauchen erscheint monatlich und ist Europas größte Taucherzeitschrift. Es beinhaltet Berichte
über Tauchziele, allgemeine Informationen über Neuerungen und Technische Innovationen.
Homepage der Zeitschrift: http://www.tauchen.de/
Divemaster
Divemaster ist ein Fachmagazin des Tauchsports. Es widmet sich im Wesentlichen der Tauchtechnik, Tauchmedizin und Tauchausbildung.
Homepage der Zeitschrift: http://www.divemaster.de/
Unterwasser
Das monatlich erscheindende Magazin Unterwasser widmet sich ebenfalls der Zielgruppe
der Taucher. Es beinhaltet hauptsächlich Reiseinformation, Reportagen über Tauchorte und
Tauchtechnik sowie Fotos vom Tauchen.
Homepage der Zeitschrift: http://www.unterwasser.de/
Brandstätter Andreas, Klaffl Christoph
Seite 129von 231
ALFSA
7.5
KAPITEL 7. MARKETING
Promotionswebseite
Zur allgemeinen Promotion und Präsentation das Produktes wurde eine Webseite im Internet eingerichtet. Diese Webseite bietet dem Kunden eine allgemeine Information über die
Software, einige Screenshots und Kontaktadressen der Entwickler. Das Design der Seite wurde bewusst schlicht und professionell in den Farben des Logos gewählt um Kompetenz und
Seriosität zu zeigen.
Die Weseite ist erreichbar unter der Adresse: http://alfsa.bfkdo-tulln.at/
Brandstätter Andreas, Klaffl Christoph
Seite 130von 231
ALFSA
Teil IV
Handbuch
Brandstätter Andreas, Klaffl Christoph
Seite 131von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Kapitel 8
Administratorhandbuch
8.1
Willkommen
Willkommen bei ALFSA (Atemluftfüllstellenapplikation). Dieses Handbuch wird Sie mit der
Einrichtung des ALFSA Systems vertraut machen und bietet ihnen eine schnelle Einführung
in die Bedienung.
8.2
8.2.1
Voraussetzungen
Hardware
Die folgenden Vorausetzungen sind als Minimalwerte anzusehen.
• 450 MHZ Prozessor
• 256 MB Ram
• 10/100 MBit Netzwerkkarte
• 1 GB freier Festplattenspeicher
Anmerkung: Der Ram- und Festplattenspeicherverbauch steigt porpertional mit der Datenbankgröße.
Brandstätter Andreas, Klaffl Christoph
Seite 132von 231
ALFSA
8.2.2
KAPITEL 8. ADMINISTRATORHANDBUCH
Software
• GNU/Linux Debian 4.0 Etch“ (Andere Linux Systeme sind auch möglich, für diese
”
werden aber keine Supportleistungen erbracht)
• Apache2 Web Server (Ältere Versionen möglich, jedoch werden keine Supportleistungen
übernommen)
• PHP5 (mit php-mysql Erweiterung) und PHP Modul für Apache2
• OpenSSH 4.3 oder höher (mit OpenSSL 0.9.7 oder höher)
• MySQL 5.0.32 oder höher
• NTP (ntpdate, ntpd)
• CRON
8.3
8.3.1
Installation
Programmdateien kopieren
Der gesamte Verzeichnisbaum der Programmdateien von der mitgelieferten CD wird in den
Webspace kopiert. Bei Debian Systemen ist das /var/www/“.
”
Beachte: Auch die versteckten Dateien (.htaccess) müssen mitkopiert werden.
8.3.2
Rechte anpassen
Folgende Verzeichnisse und darunterliegende Dateien brauchen Schreibrechte:
1. ./conf/
2. ./images/tables
Alle anderen Verzeichnisse kommen mit Leserechten aus.
Desweiteren muss das Ausführungsrecht für die Datei ./sync.sh“ vergeben werden, damit die
”
automatische Syncronisierung funktioniert.
Brandstätter Andreas, Klaffl Christoph
Seite 133von 231
ALFSA
8.3.3
KAPITEL 8. ADMINISTRATORHANDBUCH
Einmalige Einstellungen
In der Datei ./libs/defines.inc.php“ müssen 2 Werte für ihre Installation angepasst werden,
”
die da wären:
• HOME DIR: Hier müssen Sie das Heimverzeichnis des Benuters angeben, unter welchem der PHP Interpreter ausgeführt wird (bei einem Debian System ist das üblicherweise www-data“ mit dem Verzeichnis /var/www/“)
”
”
• MASTER STRUCTURE DB SERVER: Hier wird derjenige Servername eingetragen, von welchem Datenbankstrukturänderungen akzeptiert werden (Beachte: Es wird
ausdrücklichst empfohlen diese Option leer zu lassen, damit diese Funktion deaktiviert
bleibt)
8.3.4
Erster ALFSA Server
Falls es sich bei diesem Rechner um den ersten Server für die verteilte Datenbank handelt,
muss zusätzlich folgender Schritt durchgeführt werden:
Auf der mitgelieferten CD befindet sich eine SQL-Datei, welche die gesamte Datenbankstruktur enthält. Diese muss auf die gewählte Datenbank ausgeführt werden.
8.3.5
Konfiguration
Wenn das Web-Interface zum ersten Mal durch einen Browser aufgerufen wird, meldet sich
die Konfigurationsseite auf welcher alle nötigen Einstellungen eingetragen werden:
Brandstätter Andreas, Klaffl Christoph
Seite 134von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Abbildung 8.1: ALFSA Erste Synchronisierung
Nach Ausfüllen der verlangten Einstellungen kann die erste Syncronisierung gestartet werden.
Dadurch wird die Datenbankstruktur automatisch erstellt und alle verfügbaren Datensätze
werden in den lokalen Datenbankserver eingefügt. Nach erfolgreicher Syncronisierung erfolgt
eine Weiterleitung zur Anmeldung und das System ist für die Nutzung bereit.
8.3.6
Fehlerbehandlung
Falls folgende Fehlermeldung beim Aufrufen der Server Oberfläche erscheint, wurden die Dateirechte nicht richtig gesetzt (siehe Kapitel 8.3.2):
Abbildung 8.2: ALFSA Keine Berechtigung
Brandstätter Andreas, Klaffl Christoph
Seite 135von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Falls der Server im ALFSA System nicht registriert ist, funktioniert die erste Syncronisation
nicht:
Abbildung 8.3: ALFSA Nicht registriert
Daher muss dieser bei einem laufenden ALFSA Server registriert werden (siehe Kapitel 8.4.7
auf Seite 151)
8.4
Bedienung
Um Administrative Tätigkeiten auszuführen, muss zunächst eine Anmeldung am gewünschten
ALFSA Server durchgeführt werden:
Abbildung 8.4: ALFSA Hauptseite
Brandstätter Andreas, Klaffl Christoph
Seite 136von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Nach ordnungsgemäßer Anmeldung folgt eine Weiterleitung auf die Hauptseite, welche grundlegende Server Informationen anzeigt. Somit ist feststellbar ob der Speicher knapp wird oder
andere Ressourcen nicht ausreichen bzw. nicht verfügbar sind:
Abbildung 8.5: ALFSA Hauptseite
Die einzelnen Verwaltungskomponenten können über die linke Menüleiste erreicht werden. Sie
sind in 3 Hauptgruppen eingeteilt:
• ALFSA-Verwaltung
– Benutzerverwaltung
– Feuerwehrverwaltung
– Fuellstellenverwaltung
– Clientverwaltung
– Kompressorverwaltung
• Server-Verwaltung
Brandstätter Andreas, Klaffl Christoph
Seite 137von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
– Serverliste
– Serververwaltung
– Konfiguration
• Anderes
– Synchronisieren
– Logs
– Tabellenansicht
Diese werden im Folgenden erläutert.
Anmerkung: Die Hauptgruppen sind einklappbar
8.4.1
Benutzerverwaltung
Abbildung 8.6: ALFSA Benutzerverwaltung
Brandstätter Andreas, Klaffl Christoph
Seite 138von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
In der linken Spalte der Benutzerliste findet man verschiedene Filter, über die die Anzahl der
Benutzer, die in der Liste angeziegt werden, limitiert werden kann:
• Bezirk auswählen: Es werden nur Benutzer aus gewähltem Bezirk angezeigt
• Abschnitt auswählen: Es werden nur Benutzer aus gewähltem Abschnitt angezeigt
• Feuerwehr auswählen: Es werden nur Benutzer aus gewählter Feuerwehr angezeigt
• aktive Benutzer: Es werden nur Benutzer angezeigt, die aktiv sind
• gelöschte Benutzer: Es werden nur Benutzer angezeigt, die nicht mehr Mitglieder der
Feuerwehr sind
• alle Benutzer: Es werden alle Benutzer angezeigt, unabhängig davon, ob Sie noch im
Dienst sind oder nicht
Durch Anpassung der Filter wird die Seite mit den neuen Optionen automatisch neu geladen.
Über 2 Buttons über und unter der Liste, die die Benutzer auflistet, können die nächsten 10
bzw. die vorigen 10 Benutzer abgerufen werden. (Diese werden natürlich nur eingeblendet,
falls die Anzahl der verfügbaren Benutzer 10 übersteigt)
In der rechten Spalte der Benutzerliste können bestimmte Aktionen ausgeführt werden, die
sich selbst erklären:
• Benutzer hinzufügen
• Benutzer ändern
• Benutzer Rechte ändern
• Benutzer löschen
• Benutzer anzeigen
• Standard Rechte ändern
Es werden aber nicht immer alle Aktionen angezeigt, sondern nur jene die verwendet werden
können. Wurde zum Beispiel kein Benutzer aus der Liste ausgewählt und ist keine Feuerwehr
ausgewählt wird nur der Menüpunkt Standard Rechte ändern“. Falls ein Benutzer ausgewählt
”
wurde, werden die Menüpunkte zum Anzeigen, Löschen und Ändern angezeigt.
In der Abbildung 8.6 werden die Details eines Benutzer geändert. Die einzelnen Einträge sind
wiederum selbst erklärend und es besteht daher kein Bedarf diese zu erklären.
Brandstätter Andreas, Klaffl Christoph
Seite 139von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Abbildung 8.7: ALFSA Benutzerverwaltung2
In der Abbildung 8.7 werden die Rechte für einen Benutzer geändert. Diese sind wiederum
selbsterklärend. Die Standardrechte, die bei den einzelnen Benutzern standardmäßig eingestellt, können über den Menüpunkt Benutzer Standard Rechte ändern“ eingestellt werden.
”
Weiters ist aus der Abbildung 8.7 zu entnehmen, dass es Berechtigungsbereiche gibt (die TABs
am unteren Rand):
• global: Diese Rechte sind für alle Füllstellen gültig
• local: Diese Rechte sind nur für die eigene Füllstelle gültig
• server: Diese Berechtigungen sind beim Client-Terminal gültig
Brandstätter Andreas, Klaffl Christoph
Seite 140von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Abbildung 8.8: ALFSA Benutzerverwaltung3
In der Abbildung 8.8 wird ein neuer Benutzer angelegt. Dazu muss zunächst eine Feuerwehr im
Filter ausgewählt werden, danach erscheint der Menüknop Benutzer hinzufügen“, mit dessen
”
Betätigung wird dann das Formular für den neuen Benutzer geladen. Durch das Ausfüllen und
Abschicken des Formulars wird der Benutzer erstellt.
Brandstätter Andreas, Klaffl Christoph
Seite 141von 231
ALFSA
8.4.2
KAPITEL 8. ADMINISTRATORHANDBUCH
Feuerwehrverwaltung
Abbildung 8.9: ALFSA Feuerwehrverwaltung
In der linken Spalte von der Feuerwehrliste kann die Feuerwehr über die Angabe von Bezirk
und Abschnitt ausgewählt werden. Weiters besteht die Möglichkeit die Feuerwehrnummer
direkt einzugeben.
Durch Anpassung der Filter wird die Seite mit den neuen Optionen automatisch neu geladen.
Es stehen folgende Aktionen zur Verfügung, die sich in Abhängigkeit der Angaben aktivieren
lassen oder nicht:
• Feuerwehr hinzufügen
• Feuerwehr ändern
• Feuerwehr anzeigen
Brandstätter Andreas, Klaffl Christoph
Seite 142von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Falls eine Feuerwehr hinzugefügt werden soll, müssen Bezirk und Abschnitt ausgewählt werden.
Abbildung 8.10: ALFSA Feuerwehrverwaltung2
Abbildung 8.10 zeigt das Hinzufügen einer Feuerwehr.
Brandstätter Andreas, Klaffl Christoph
Seite 143von 231
ALFSA
8.4.3
KAPITEL 8. ADMINISTRATORHANDBUCH
Fuellstellenverwaltung
Abbildung 8.11: ALFSA Fuellstellenverwaltung
Die Bedienung der Fuellstellenverwaltung ist mit der Feuerwehrverwaltung ident und kann
deshalb anhand dieser erlernt werden.
Brandstätter Andreas, Klaffl Christoph
Seite 144von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Abbildung 8.12: ALFSA Fuellstellenverwaltung2
Abbildung 8.11 und 8.12 illustrieren jeweils das Anzeigen und Bearbeiten von Fuellstellendetails.
Brandstätter Andreas, Klaffl Christoph
Seite 145von 231
ALFSA
8.4.4
KAPITEL 8. ADMINISTRATORHANDBUCH
Clientverwaltung
Abbildung 8.13: ALFSA Clientverwaltung
In der linken Spalte der Clientliste findet man verschiedene Filter, über die die Anzahl der
Clients, die in der Liste angezeigt werden, limitiert werden kann:
• Bezirk auswählen: Es werden nur Clients aus gewähltem Bezirk angezeigt
• Abschnitt auswählen: Es werden nur Clients aus gewähltem Abschnitt angezeigt
• Füllstelle auswählen: Es werden nur Clients aus gewählter Füllstelle angezeigt
Durch Anpassung der Filter wird die Seite mit den neuen Optionen automatisch neu geladen.
Über 2 Buttons über und unter der Liste, die die Clients auflistet, können die nächsten 10
bzw. die vorigen 10 Clients abgerufen werden. (Diese werden natürlich nur eingeblendet, falls
die Anzahl der verfügbaren Clients 10 übersteigt)
Brandstätter Andreas, Klaffl Christoph
Seite 146von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
In der rechten Spalte der Benutzerliste können bestimmte Aktionen ausgeführt werden, die
sich selbst erklären:
• Client hinzufügen
• Client ändern
• Client löschen
• Client anzeigen
Es werden aber nicht immer alle Aktionen angezeigt, sondern nur jene die verwendet werden
können. Wurde zum Beispiel kein Client aus der Liste ausgewählt und ist keine Füllstelle
ausgewählt wird kein Menüpunkt angezeigt. Falls ein Client ausgewählt wurde, werden die
Menüpunkte zum Anzeigen, Löschen und Ändern angezeigt.
Abbildung 8.13 und 8.14 zeigen jeweils die Details eines Clients und das Hinzufügen eine
Clients.
Abbildung 8.14: ALFSA Clientverwaltung2
Brandstätter Andreas, Klaffl Christoph
Seite 147von 231
ALFSA
8.4.5
KAPITEL 8. ADMINISTRATORHANDBUCH
Kompressorverwaltung
Abbildung 8.15: ALFSA Kompressorverwaltung
Die Bedienung der Kompressorverwaltung ist mit der Benutzerverwaltung ident und kann
deshalb anhand dieser erlernt werden.
Brandstätter Andreas, Klaffl Christoph
Seite 148von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Abbildung 8.16: ALFSA Kompressorverwaltung2
Abbildung 8.15 und 8.16 illustrieren jeweils das Anzeigen Kompressordetails und das Hinzufügen eines Kompressors.
Brandstätter Andreas, Klaffl Christoph
Seite 149von 231
ALFSA
8.4.6
KAPITEL 8. ADMINISTRATORHANDBUCH
Serverliste
Abbildung 8.17: ALFSA Serverliste
Die Serverliste zeigt im wesentlichen alle Server mit ihren Eigenschaften an (bis auf Backup
Server, Abbildung 8.17). Weiters wird getestet ob die Server erreichbar sind und ob auf die
entfernten Datenbank zugegriffen werden kann.
Brandstätter Andreas, Klaffl Christoph
Seite 150von 231
ALFSA
8.4.7
KAPITEL 8. ADMINISTRATORHANDBUCH
Serververwaltung
Abbildung 8.18: ALFSA Serververwaltung
In der Liste sind alle Server mit ihren Namen aufgeführt und können ausgewählt werden.
Folgende Aktionen sind möglich:
• Server hinzufügen
• Server ändern
• Server löschen
• Server anzeigen
Anhand der Abbildung 8.19 ist eine Aktualisierung der Serverdetails zu sehen. Hier ist anzumerken, dass ein Server mit der Priorität 0 einen Backup server darstellt. Für diesen sind
nur Servernamen und RSA Key auszufüllen. Der Backupserver wird von der Client-Server
Brandstätter Andreas, Klaffl Christoph
Seite 151von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Synchronisation und der Server-Server Synchronisation ausgeschlossen. Er führt nur Syncronisationen mit anderen Servern durch und hält deshalb stets ein Backup aller Daten. Keiner
der anderen Server ist der Zugriff auf einen Backupserver erlaubt, dadurch ist sichergestellt,
dass bei einer Übernahme eines anderen Server im ALFSA System durch einen Angreifer,
dieser keinen Zugriff auf den Backupserver und die Backupdaten erhält.
Abbildung 8.19: ALFSA Serververwaltung2
Brandstätter Andreas, Klaffl Christoph
Seite 152von 231
ALFSA
8.4.8
KAPITEL 8. ADMINISTRATORHANDBUCH
Konfiguration
Abbildung 8.20: ALFSA Konfiguration
Folgende Einstellungen werden in der Konfiguration getätigt:
• Datenbank Host: Hostname oder IP Adresse des Datenbankservers
• Datenbank Benutzer: Benutzername für die Datenbank
• Datenbank Passwort: Passwort für die Datenbank
• Datenbankname: Name der Datenbank
• Kommunikationsmethode: Gibt an, ob die Verbindung zu anderen Server über den
Hostnamen oder der IP Adresse erfolgen soll
• Synchronisierungsintervall: Zeitintervall, in dem die Syncronisierung ausgeführt wird
• Maximale Ausführungszeit der Synchronisierung: Gibt die maximale Zeit an, die
eine Syncronisierung beanspruchen darf
Brandstätter Andreas, Klaffl Christoph
Seite 153von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
• Portrange für das Tunneln: Gibt einen Port bereich an, welcher für den Porttunnel
verwendet werden darf
• Sync Log Level: Gibt an, wie detailiert die Logdateien ausfallen
8.4.9
Synchronisieren
Abbildung 8.21: ALFSA Synchronisieren
Abbildung 8.21 zeigt die Liste mit den Namen aller aktiven Server an (nicht die Backupserver).
Um eine manuelle Synchronisation zu starten, wird ein Server aus der Liste ausgewählt und
der Button Synchronisieren“ betätigt. Dadurch wird der Synchronisationsvorgang gestartet
”
und kann, wie in Abbildung 8.22 zu sehen ist, mitverfolgt werden.
Brandstätter Andreas, Klaffl Christoph
Seite 154von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
Abbildung 8.22: ALFSA Synchronisieren2
Brandstätter Andreas, Klaffl Christoph
Seite 155von 231
ALFSA
8.4.10
KAPITEL 8. ADMINISTRATORHANDBUCH
LOGViewer
Abbildung 8.23: ALFSA LOGViewer
Mittels des Log Viewers wird die Betrachtung der Log Meldungen vereinfacht. Sie werden
nach Datum sortiert und können nach diesem auch eingeklappt werden um für eine bessere
Übersicht zu sorgen.
Es können 3 Log Dateien ausgewählt werden:
• sync-info.log: Beinhaltet Informationen über die Synchronisationsvorgänge
• sync-error.log: Beinhaltet Informationen über Fehler bei dem Synchronisationsvorgängen
• error.log: Beinhaltet Informationen über Fehler, die eventuell bei der Benützung der
Administrationsoberfläche auftreten
Die weiteren Optionen sind:
Brandstätter Andreas, Klaffl Christoph
Seite 156von 231
ALFSA
KAPITEL 8. ADMINISTRATORHANDBUCH
1. Alles laden: Bei diesem Modus, müssen die Log Meldungen für ein anderes Datum
nicht nachgeladen werden, da sie bereits im vorhinein geladen wurden
2. Nachladen: Bei diesem Modus, werden durch drücken der Datumsüberschriften die
betreffenden Log Meldungen nachgeladen
3. Zeilenanzahl: Gib die Anzahl der Log Meldungen an, die geladen werden sollen
Durch drücken auf eine der Log Dateien, wird sie im Hauptfenster geladen. Siehe Abbildung
8.24.
Abbildung 8.24: ALFSA LOGViewer2
Brandstätter Andreas, Klaffl Christoph
Seite 157von 231
ALFSA
8.4.11
KAPITEL 8. ADMINISTRATORHANDBUCH
Tabellenansicht
Abbildung 8.25: ALFSA Tabellenansicht
Die Tabellenansicht stellt alle Tabellen der Datenbank grafisch mit ihren Beziehungen da.
Brandstätter Andreas, Klaffl Christoph
Seite 158von 231
ALFSA
8.4.12
KAPITEL 8. ADMINISTRATORHANDBUCH
Fehlerhafte Eingabe
Eingabe.png
Abbildung 8.26: ALFSA Fehlerhafte Eingabe
Bei allen Formulardaten der Administrationsoberfläche wird eine serverseitige Überprüfung
auf Gültigkeit der eingegebenen Daten durchgeführt. In der Abbildung 8.26 kann man eine
resultierende Fehlermedlung mit den Details betrachten.
Brandstätter Andreas, Klaffl Christoph
Seite 159von 231
ALFSA
Teil V
Anhang
Brandstätter Andreas, Klaffl Christoph
Seite 160von 231
ALFSA
KAPITEL 9. ANHANG
Kapitel 9
Anhang
9.1
9.1.1
Funktionen und Klassen
Teil Client-Server-Sync am Client
function add new sync vorgang
1 int function add_new_sync_vorgang(\$server, [\$time = 0])
in Datei /client-www/sync/sync functions.inc.php (Zeile 69)
Returnwert: int Zeit zur der die Synchronisierung initiiert wurde.
Funktionsparameter:
• string $server: Server, zu dem die Verbindung hergestellt werden soll.
• int $time: Zeit, zu der die Synchronisierung gestartet wird.
Speichert einen neuen Synchronisationsvorgang in der Datenbank und in der Datei.
function close sync vorgang
1 void function close_sync_vorgang(\$time_start, [\$time_end = 0])
in Datei /client-www/sync/sync functions.inc.php (Zeile 139)
Funktionsparameter:
• int $time start: Zeit, zu der die Synchronisierung gestartet wurde.
• int $time end: Zeit, zu der die Synchronisierung beendet wurde.
Beendet den Synchronisationsvorgang in der Datenbank und loescht die Datei.
function error
1 void function error(\$line, \$file, \$string, [\$error = ""], \$sql)
in Datei /client-www/sync/sync functions.inc.php (Zeile 493)
Funktionsparameter:
• int $line: Zeile, in der die Fehlermeldung ausgloest wurde.
• int $file: Datei, in der die Fehlermeldung ausgloest wurde.
• string $string: Beschreibung des Fehlers.
Brandstätter Andreas, Klaffl Christoph
Seite 161von 231
ALFSA
KAPITEL 9. ANHANG
• string $error: Fehlermeldung, die von MySQL zurueckgegeben wird.
• string $sql: MySQL-String, der den Fehler verursachte.
Gibt eine formatierte MySQL-Fehlermeldung aus.
function get db summary
1 string function get_db_summary()
in Datei /client-www/sync/sync functions.inc.php (Zeile 266)
Returnwert: string Datenbankzusammenfassung.
Liefert eine Zusammenfassung der Tabellenstrukturen der Datenbank.
function get rand server
1 array function get_rand_server()
in Datei /client-www/sync/sync functions.inc.php (Zeile 238)
Returnwert: array Server aus der Datenbank.
Liefert einen zufälligen Server aus der Datenbank.
function get server
1 array function get_server(\$name)
in Datei /client-www/sync/sync functions.inc.php (Zeile 216)
Returnwert: array Server aus der Datenbank.
Funktionsparameter:
• string $name: Servername des zu selektierenden Servers.
Liefert einen Server aus der Datenbank.
function get servers
1 array function get_servers()
in Datei /client-www/sync/sync functions.inc.php (Zeile 190)
Returnwert: array Alle Server aus der Datenbank.
Liefert eine Auflistung aller Server aus der Datenbank inklusive Hardcode-Server.
function get server page
1 array function get_server_page([\$post = array()], \$phase, [\$server ←= "euklid-server"])
in Datei /client-www/sync/sync functions.inc.php (Zeile 292)
Returnwert: array Inhalt der Seite und eventuell aufgetretene Fehler.
Funktionsparameter:
• array $post: Daten, die per POST uebergeben werden.
• int $phase: Arbeitsschritt, der aktuell abgearbeitet wird.
• string $server: Servername, auf den die Anfrage ausgefuehrt wird.
Brandstätter Andreas, Klaffl Christoph
Seite 162von 231
ALFSA
KAPITEL 9. ANHANG
Fragt eine Server-Seite ueber CURL ab.
function get tables
1 array function get_tables()
in Datei /client-www/sync/sync functions.inc.php (Zeile 161)
Returnwert: array Tabellen der Datenbank mit Level.
Liefert eine Auflistung aller Tabellen der Datenbank. Liest zusaetzlich das Level aus der
Tabelle sync aus.
function get this sync vorgang
1 array function get_this_sync_vorgang()
in Datei /client-www/sync/sync functions.inc.php (Zeile 97)
Returnwert: array Daten des Synchronisationsvorganges aus der Datei.
Liest den aktuellen Synchronisationsvorgang aus der Datei aus.
function lock
1 void function lock()
in Datei /client-www/sync/sync functions.inc.php (Zeile 378)
Sperrt die Synchronisierung, damit nur ein Vorgang gleichzeitig ausgefuehrt wird.
function locked
1 int function locked()
in Datei /client-www/sync/sync functions.inc.php (Zeile 408)
Returnwert: int Zeit, wann die Synchronisierung gesperrt wurde.
Prueft, ob die Synchronisierung gesperrt ist.
function my mysql exceute
1 void function my_mysql_exceute(\$dl)
in Datei /client-www/sync/sync functions.inc.php (Zeile 512)
Funktionsparameter:
• string $dl: SQL-Anweisungen vom Server.
Fuehrt mehrere SQL-Anweisungen vom Server in der Datenbank aus.
function print reload
1 void function print_reload([\$sec = 2])
in Datei /client-www/sync/sync functions.inc.php (Zeile 535)
Funktionsparameter:
• string $sec: Zeit bis zum Neuladen in Sekunden.
Brandstätter Andreas, Klaffl Christoph
Seite 163von 231
ALFSA
KAPITEL 9. ANHANG
Gibt den die JavaScript-Befehle fuer ein Neuladen der Seite aus.
function read end date
1 int function read_end_date()
in Datei /client-www/sync/sync functions.inc.php (Zeile 475)
Returnwert: int Datum der letzten vollstaendigen Synchronisation.
Liest das Datum der letzten vollstaendigen Synchronisation aus.
function read phase
1 int function read_phase()
in Datei /client-www/sync/sync functions.inc.php (Zeile 440)
Returnwert: int Aktueller Arbeitsschritt.
Liest den aktuellen Arbeitsschritt aus.
function unlock
1 void function unlock()
in Datei /client-www/sync/sync functions.inc.php (Zeile 394)
Entsperrt die Synchronisierung.
function write end date
1 void function write_end_date([\$time = -1])
in Datei /client-www/sync/sync functions.inc.php (Zeile 454)
Funktionsparameter:
• int $time: Datum der letzten vollstaendigen Synchronisation.
Speichert das Datum der letzten vollstaendigen Synchronisation.
function write phase
1 void function write_phase([\$phase = 0])
in Datei /client-www/sync/sync functions.inc.php (Zeile 422)
Funktionsparameter:
• int $phase: Aktueller Arbeitsschritt.
Speichert den aktuellen Arbeitsschritt.
9.1.2
Teil Server
function add client
1 void function add_client(\$fuellstelle, \$laufnummer, \$name, \$os, \ ←$verbindungskennung)
Brandstätter Andreas, Klaffl Christoph
Seite 164von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/client.inc.php (Zeile 123)
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
• string $name: Name
• string $os: OS Bezeichnung
• string $verbindungskennung: Verbindungskennung/Verbindungsschlüssel
Fügt einen neuen Client in die Datenbank ein
function change client
1 void function change_client(\$fuellstelle, \$laufnummer, \$name, \$os ←, \$verbindungskennung)
in Datei /server-www/libs/client.inc.php (Zeile 75)
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
• string $name: Neuer Name
• string $os: Neue OS Bezeichnung
• string $verbindungskennung: Neue Verbindungskennung/Verbindungsschlüssel
Ändert die Eigenschaften/Details eines Clients
function get clients
1 array function get_clients([\$bezirk = 0], [\$abschnitt = 0], [\ ←$fuellstelle = 0], [\$limit_start = 0], [\$limit_count = 0])
in Datei /server-www/libs/client.inc.php (Zeile 19)
Returnwert: array Clients
Funktionsparameter:
• integer $bezirk: Berzirksnummer
• integer $abschnitt: Abschnittsnummer
• integer $fuellstelle: Füllstellennummer
• integer $limit start: Datensätze, ab denen selektiert wird
• integer $limit count: Gibt an, wie viele Clients zurückgeliefert werden sollen
Liefert Clients aus der Datenbank
function get client details
1 array function get_client_details(\$fuellstelle, \$laufnummer)
in Datei /server-www/libs/client.inc.php (Zeile 57)
Returnwert: array Clientdetails
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
Brandstätter Andreas, Klaffl Christoph
Seite 165von 231
ALFSA
KAPITEL 9. ANHANG
Liefert Details über einen Client aus der Datenbank
function get next laufnummer
1 integer function get_next_laufnummer(\$fuellstelle)
in Datei /server-www/libs/client.inc.php (Zeile 170)
Returnwert: integer Nächste freie Laufnummer
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
Liefert die nächste freie Laufnummer für einen neuen Client in einer Füllstelle
function add compressor
1 void function add_compressor(\$fuellstelle, \$laufnummer, \ ←$funkrufname, \$hersteller, \$seriennummer,
2 \$fuellanschl_200, \$fuellanschl_300, \$fuellanschl_nieder, \ ←$enddruck, \$hochdruck_eingang,
3 \$hochdruck_ausgang, \$wartungsintervall, \$pruefintervall, \ ←$quickfill, \$mobil)
in Datei /server-www/libs/compressor.inc.php (Zeile 157)
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
• string $funkrufname: Funkrufname
• string $hersteller: Hersteller
• string $seriennummer: Seriennummer
• integer $fuellanschl 200: Anzahl der 200bar Füllanschlüsse
• integer $fuellanschl 300: Anzahl der 300bar Füllanschlüsse
• integer $fuellanschl nieder: Anzahl der Niederdruck Füllanschlüsse
• integer $enddruck: Enddruck
• integer $hochdruck eingang: Anzahl der Hochdruckeingänge
• integer $hochdruck ausgang: Anzahl der Hochdruckausgänge
• integer $wartungsintervall: Wartungsintervall
• integer $pruefintervall: Prüfintervall
• integer $quickfill: Quikfillausgänge
• string/enum $mobil: Mobil oder stationär
Fügt einen neuen Kompressor in die Datenbank ein
function change compressor
1 void function change_compressor(\$fuellstelle, \$laufnummer, \ ←$funkrufname, \$hersteller, \$seriennummer,
2 \$fuellanschl_200, \$fuellanschl_300, \$fuellanschl_nieder, \ ←$enddruck, \$hochdruck_eingang,
3 \$hochdruck_ausgang, \$wartungsintervall, \$pruefintervall, \ ←$quickfill, \$mobil)
Brandstätter Andreas, Klaffl Christoph
Seite 166von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/compressor.inc.php (Zeile 111)
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
• string $funkrufname: Neuer Funkrufname
• string $hersteller: Neuer Hersteller
• string $seriennummer: Neue Seriennummer
• integer $fuellanschl 200: Anzahl der 200bar Füllanschlüsse
• integer $fuellanschl 300: Anzahl der 300bar Füllanschlüsse
• integer $fuellanschl nieder: Anzahl der Niederdruck Füllanschlüsse
• integer $enddruck: Enddruck
• integer $hochdruck eingang: Anzahl der Hochdruckeingänge
• integer $hochdruck ausgang: Anzahl der Hochdruckausgänge
• integer $wartungsintervall: Wartungsintervall
• integer $pruefintervall: Prüfintervall
• integer $quickfill: Quikfillausgänge
• string/enum $mobil: Mobil oder stationär
Ändert die Eigenschaften/Details eines Kompressors
function del compressor
1 boolean function del_compressor(\$fuellstelle, \$laufnummer)
in Datei /server-www/libs/compressor.inc.php (Zeile 195)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
Löscht einen Kompressor aus der Datenbank
function get compressors
1 array function get_compressors([\$bezirk = 0], [\$abschnitt = 0], [\ ←$fuellstelle = 0], [\$limit_start = 0], [\$limit_count =
2 0], [\$show_deleted = 2])
in Datei /server-www/libs/compressor.inc.php (Zeile 20)
Returnwert: array Kompressoren
Funktionsparameter:
• integer $bezirk: Berzirksnummer
• integer $abschnitt: Abschnittsnummer
• integer $fuellstelle: Füllstellennummer
• integer $limit start: Datensätze, ab denen selektiert wird
• integer $limit count: Gibt an, wie viele Kompressoren zurückgeliefert werden sollen
• integer $show deleted: Gibt an, welche Kompressoren zurückgegeben werden (0 = nur
aktive, 1 = nur gelöschte/abgeschlossene, 2 = aktive und gelöschte/abgeschlossene)
Brandstätter Andreas, Klaffl Christoph
Seite 167von 231
ALFSA
KAPITEL 9. ANHANG
Liefert Kompressoren aus der Datenbank
function get compressor details
1 array function get_compressor_details(\$fuellstelle, \$laufnummer)
in Datei /server-www/libs/compressor.inc.php (Zeile 83)
Returnwert: array Kompressordetails
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
• integer $laufnummer: Laufnummer
Liefert Details über einen Kompressor aus der Datenbank
function get next compressor laufnummer
1 integer function get_next_compressor_laufnummer(\$fuellstelle)
in Datei /server-www/libs/compressor.inc.php (Zeile 219)
Returnwert: integer Nächste freie Laufnummer
Funktionsparameter:
• integer $fuellstelle: Füllstellennummer
Liefert die nächste freie Laufnummer für einen neuen Kompressor in einer Füllstelle
function del cronjob
1 void function del_cronjob(\$command, [\$comment = "0"])
in Datei /server-www/libs/cron.inc.php (Zeile 110)
Funktionsparameter:
• string $command: Befehl, über den der Cronjob gesucht wird
• string $comment: Kommentar, über den der Cronjob gesucht wird
Löscht einen Cronjob
function new cronjob
1 void function new_cronjob(\$command, [\$comment = " ←auto_generated_by_ALFSA"], [\$min =
2 "*"], [\$std = "*"], [\$day = "*"], [\$month = "*"], [\$wd = "*"])
in Datei /server-www/libs/cron.inc.php (Zeile 70)
Funktionsparameter:
• string $command: Befehl, der von Cron ausgeführt werden soll
• string $comment: Kommentar, der zum Cronjob hinzugefügt wird
• string $min: Minuten
• string $std: Stunden
• string $day: Tage
• string $month: Monate
• string $wd: Wochentage
Brandstätter Andreas, Klaffl Christoph
Seite 168von 231
ALFSA
KAPITEL 9. ANHANG
Generiert einen neuen Cronjob und registriert ihn
function read crontab
1 array/string function read_crontab([\$comment = ""])
in Datei /server-www/libs/cron.inc.php (Zeile 15)
Returnwert: array/string Liste der Cronjobs/ Bei Angabe eines Kommentars den Minutenintervall
Funktionsparameter:
• string $comment: Kommentar des Cronjobs
Lifert alle Cronjobs oder einen bestimmten zurück
function write crontab
1 void function write_crontab(\$file)
in Datei /server-www/libs/cron.inc.php (Zeile 51)
Funktionsparameter:
• string $file: Die Liste mit Cronjobs
Schreibt Cronjobs für den aktuellen Benutzer
function add fuellstelle
1 void function add_fuellstelle(\$fwnr, \$tpa_nr)
in Datei /server-www/libs/fuellstelle.inc.php (Zeile 71)
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $tpa nr: Neue TPA Nummer
Fügt eine neue Füllstelle in die Datenbank ein
function change fuellstelle
1 void function change_fuellstelle(\$fwnr, \$tpa_nr)
in Datei /server-www/libs/fuellstelle.inc.php (Zeile 49)
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $tpa nr: Neue TPA Nummer
Ändert die Details einer Füllstelle
function get fuellstellen
1 array function get_fuellstellen([\$bezirk = 0], [\$abschnitt = 0], [\ ←$fwnr = 0])
Brandstätter Andreas, Klaffl Christoph
Seite 169von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/fuellstelle.inc.php (Zeile 17)
Returnwert: array Füllstellen
Funktionsparameter:
• integer $bezirk: Berzirksnummer
• integer $abschnitt: Abschnittsnummer
• integer $fwnr: Feuerwehrnummer
Liefert Füllstellen aus der Datenbank
function add fw
1 void function add_fw(\$fwnr, \$name, \$bezirk, \$abschnitt, \$plz, \ ←$ortschaft, \$gemeinde, \$strasze,
2 \$hausnummer, \$typ, \$fuellstelle)
in Datei /server-www/libs/fw.inc.php (Zeile 106)
Funktionsparameter:
• integer $fwnr: Füllstellennummer
• string $name: Feuerwehrname
• integer $bezirk: Berzirksnummer
• integer $abschnitt: Abschnittsnummer
• integer $plz: Postleitzahl
• string $ortschaft: Ortschaft
• string $gemeinde: Gemeinde
• string $strasze: Straße
• integer $hausnummer: Hausnummer
• string/enum $typ: Typ der Feuerwehr (Freiwillige Feuerwehr/Betriebsfeuerwehr)
• integer $fuellstelle: Füllstellennummer
Fügt eine neue Feuerwehr in die Datenbank ein
function change fw
1 void function change_fw(\$fwnr, \$name, \$plz, \$ortschaft, \ ←$gemeinde, \$strasze, \$hausnummer, \$typ,
2 \$fuellstelle)
in Datei /server-www/libs/fw.inc.php (Zeile 68)
Funktionsparameter:
• integer $fwnr: Füllstellennummer
• string $name: Feuerwehrname
• integer $plz: Postleitzahl
• string $ortschaft: Ortschaft
• string $gemeinde: Gemeinde
• string $strasze: Straße
• integer $hausnummer: Hausnummer
• string/enum $typ: Typ der Feuerwehr (Freiwillige Feuerwehr/Betriebsfeuerwehr)
• integer $fuellstelle: Füllstellennummer
Ändert die Eigenschaften/Details einer Feuerwehr
Brandstätter Andreas, Klaffl Christoph
Seite 170von 231
ALFSA
KAPITEL 9. ANHANG
function get feuerwehren
1 array function get_feuerwehren([\$bezirk = 0], [\$abschnitt = 0], [\ ←$fwnr = 0], [\$fuellstelle = 1])
in Datei /server-www/libs/fw.inc.php (Zeile 18)
Returnwert: array Feuerwehren
Funktionsparameter:
• integer $bezirk: Berzirksnummer
• integer $abschnitt: Abschnittsnummer
• integer $fwnr: Feuerwehnummer
• integer $fuellstelle: Gibt an ob auch Feuerwehren angezeigt werden, die als Stationierungsfeuerwehr einer Füllstelle verwendet werden
Liefert Feuerwehren aus der Datenbank
function append to log
1 void function append_to_log(\$logfile, \$line)
in Datei /server-www/libs/misc.inc.php (Zeile 197)
Funktionsparameter:
• string $logfile: Pfad zu der Logdatei
• string $line: Logzeile
Einen Eintrag mit Zeitstempel zur einer Logdatei hinzufügen
function array insert
1 void function array_insert(\$array, \$pos, \$value)
in Datei /server-www/libs/misc.inc.php (Zeile 38)
Funktionsparameter:
• array $array: Array, in welches ein Wert hinzugfügt werden soll
• integer $pos: Position, in welcher der Wert eingefügt wird
• * $value: Wert der eingefügt wird
Fügt einen bestimmten Wert an einer bestimmten Stelle eines Arrays ein
function check config
1 void function check_config(\$config_file)
in Datei /server-www/libs/misc.inc.php (Zeile 398)
Funktionsparameter:
• string $config file: Pfad zur Konfigurationsdatei
Funktion zur Überpüfung der Konfigurationsdatei
function check form data
Brandstätter Andreas, Klaffl Christoph
Seite 171von 231
ALFSA
KAPITEL 9. ANHANG
1 void function check_form_data(\$check, [\$check_verbindungskennung =
false])
←-
in Datei /server-www/libs/misc.inc.php (Zeile 307)
Funktionsparameter:
• array $check: Enthält die Kürzel, Namen, .. der Formulare die üerprüft werden sollen
• boolean $check verbindungskennung: Gibt an, ob auf eien gültige Verbindungskennung
geprüft werden soll
Funktion, die zur serverseitigen Validierung der Formulardaten dient
function contains only letters
1 boolean function contains_only_letters(\$string)
in Datei /server-www/libs/misc.inc.php (Zeile 229)
Returnwert: boolean TRUE wenn der String nur Buchstaben enthält, sonst FALSE
Funktionsparameter:
• string $string: String der überprüft werden soll
Funktion um zu überprüfen ob ein String nur Buchstaben enthält
function convert spaces to one space
1 string function convert_spaces_to_one_space(\$value)
in Datei /server-www/libs/misc.inc.php (Zeile 149)
Returnwert: string Konvertierter Text
Funktionsparameter:
• string $value: Text, der konvertiert werden soll
Konvertiert mehrere Leerzeichen zu einem
function error
1 void function error(\$line, \$file, \$string, [\$mysql_error = ""])
in Datei /server-www/libs/misc.inc.php (Zeile 215)
Funktionsparameter:
• integer $line: Zeilennummer, in der der Fehler auftritt
• string $file: Datei, in der der Fehler auftritt
• string $string: Fehlermeldung
• string $mysql error: Falls ein Fehler im Zusammenhang mit der Datenbank auftritt,
wird er hier übergeben
Fügt eine Meldung über einen Fehler in die Fehler Logdatei ein
function format data type
1 string function format_data_type(\$value, [\$decimal_places = 1], [\ ←$add_data_type = true], [\$max_format =
Brandstätter Andreas, Klaffl Christoph
Seite 172von 231
ALFSA
KAPITEL 9. ANHANG
2 ""])
in Datei /server-www/libs/misc.inc.php (Zeile 169)
Returnwert: string Umgewandelte Größe
Funktionsparameter:
• integer $value: Größe in Bytes
• integer $decimal places: Anzahl der dezimal Stellen
• boolean $add data type: Gibt an, ob die Speichereinheit angegeben werden soll
• string $max format: die maximale Speichereinheit in der der Wert umgewandelt wird
Wandelt Dateigrößen von Byte in größere Speichereinheiten um
function get abschnitte
1 array function get_abschnitte([\$bezirk = 0], [\$abschnitt = 0])
in Datei /server-www/libs/misc.inc.php (Zeile 109)
Returnwert: array Abschnitte/Abschnitt
Funktionsparameter:
• integer $bezirk: Bezirksnummer
• integer $abschnitt: Abschnittsnummer
Liefert die Abschnitte aus der Datenbank
function get bezirke
1 array function get_bezirke([\$bezirk = 0])
in Datei /server-www/libs/misc.inc.php (Zeile 81)
Returnwert: array Bezirke/Bezirk
Funktionsparameter:
• integer $bezirk: Bezirksnummer
Lifert die Bezirke aus der Datenbank
function get current dir
1 string function get_current_dir()
in Datei /server-www/libs/misc.inc.php (Zeile 25)
Returnwert: string Verzeichnis
Lifert das aktuelle Verzeichnis zurück
function get homedir
1 string function get_homedir()
in Datei /server-www/libs/misc.inc.php (Zeile 14)
Returnwert: string Heimverzeichnis
Liefert das Heimverzeichnis des Benutzers zurück unter dem PHP ausgeführt wird
Brandstätter Andreas, Klaffl Christoph
Seite 173von 231
ALFSA
KAPITEL 9. ANHANG
function get svn revision
1 string function get_svn_revision()
in Datei /server-www/libs/misc.inc.php (Zeile 137)
Returnwert: string Versionsnummer
Liefert die Subversion Versionsnummer zurück
function is ip
1 boolean function is_ip(\$string)
in Datei /server-www/libs/misc.inc.php (Zeile 271)
Returnwert: boolean TRUE wenn der String eine gültige IP Addresse enthält, sonst FALSE
Funktionsparameter:
• string $string: String der überprüft werden soll
Funktion um zu überprüfen ob ein String eine gültige IP Addresse beinhaltet
function is port
1 boolean function is_port(\$string)
in Datei /server-www/libs/misc.inc.php (Zeile 292)
Returnwert: boolean TRUE wenn der Wert eine gültige Portnummer ist, sonst FALSE
Funktionsparameter:
• string $string: Wert der überprüft werden soll
Funktion um zu überprüfen ob der übergebene Wert eine gültige Portnummer ist
function remove cr lf
1 string function remove_cr_lf(\$string)
in Datei /server-www/libs/misc.inc.php (Zeile 62)
Returnwert: string String ohne LF und CR
Funktionsparameter:
• string $string: String, aus welchem die Zeichen entfernt werden sollen
Entfernt LineFeed und CarriageReturn aus einem Text
function ping
1 array/boolean function ping(\$host, [\$n = 3])
in Datei /server-www/libs/net.inc.php (Zeile 16)
Returnwert: array/boolean minimale, durschnittliche, maximale PING Zeiten / bei Nichtereichabrkeit des Servers FALSE
Funktionsparameter:
• string $host: Hostname oder IP Addresse des zu überprüfenden Rechners
• integer $n: Anzahl der PING Versuche
Funktion zur Überprüfung eines Server durch pingen
Brandstätter Andreas, Klaffl Christoph
Seite 174von 231
ALFSA
KAPITEL 9. ANHANG
function test mysql
1 boolean function test_mysql(\$host, \$tunneld_port, \$db_host, \ ←$db_user, \$db_password, [\$ssh_port = 22])
in Datei /server-www/libs/net.inc.php (Zeile 65)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $host: Hostname oder IP Addresse des zu überprüfenden Rechners
• integer $tunneld port: Lokaler Port der zum Tunneln verwendet wird
• string $db host: Datenbankhost
• string $db user: Datenbankbenutzer
• string $db password: Datenbankbenutzer
• integer $ssh port: Port auf dem der SSH Server läuft
Funktion zur Überprüfung der MySQL Verbindung zu einem entfernten Server über SSH
function test ssh
1 boolean function test_ssh(\$host, [\$ssh_port = 22])
in Datei /server-www/libs/net.inc.php (Zeile 43)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $host: Hostname oder IP Addresse des zu überprüfenden Rechners
• integer $ssh port: Port auf dem der SSH Server läuft
Funktion zur Überprüfung der SSH Vebrindung zu einem Server
function check permissions
1 boolean function check_permissions()
in Datei /server-www/libs/setup.inc.php (Zeile 14)
Returnwert: boolean Wenn die Berechtigungen stimmen TRUE, sonst FALSE
Funktion zur Überprüfung ob die Berechtigungen für die Asuführung von ALFSA passen
function is assoc
1 boolean function is_assoc(\$array)
in Datei /server-www/libs/setup.inc.php (Zeile 107)
Returnwert: boolean Wenn das Array assoziativ ist TRUE, sonst FALSE
Funktionsparameter:
• array $array: Das zu überprüfende Array
Funktion zum Überprüfen ob ein Array assoziativ ist
function update config
1 void function update_config(\$settings, [\$config_file = "settings. ←inc.php"])
Brandstätter Andreas, Klaffl Christoph
Seite 175von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/setup.inc.php (Zeile 46)
Funktionsparameter:
• array $settings: Enthält die Einstellungen mit ihren Werte, die gesetzt werden sollen
• string $config file: Name der Konfigurationsdatei
Funktion zum ändern/erstellen von Konfigurationsdateien
function add authorized key
1 boolean function add_authorized_key(\$type, \$rsa, [\$comments = ""], ←[\$allowed_host = 0], \$typ)
in Datei /server-www/libs/ssh functions.inc.php (Zeile 154)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $typ: Typ des Eintrages
• string $rsa: RSA Schlüssel
• string $comments: Kommentar
• string $allowed host: IP oder Hostname des Rechners, dem es erlaubt ist sich mit dem
RSA KEy zu verbinden
• $type:
Fügt einen “authorized keys“ hinzu
function add known host
1 boolean function add_known_host(\$name, \$hostname, \$ip, \$type, \ ←$rsa, \$typ)
in Datei /server-www/libs/ssh functions.inc.php (Zeile 63)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $name: Name des Hosts
• string $hostname: Hostname des Rechners
• string $ip: IP des Rechners
• string $typ: Typ des Eintrages
• string $rsa: RSA Schlüssel
• $type:
Fügt einen “known Host“ hinzu
function add server
1 boolean function add_server(\$server_name, \$hostname, \$ip, \ ←$ssh_port, \$priority, \$rsa, \$db_host, \$db_user,
2 \$db_password, \$db_name)
in Datei /server-www/libs/ssh functions.inc.php (Zeile 333)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Brandstätter Andreas, Klaffl Christoph
Seite 176von 231
ALFSA
KAPITEL 9. ANHANG
Funktionsparameter:
• string $server name: Servername
• string $hostname: Hostname
• string $ip: IP Addresse
• string $ssh port: SSH Port
• string $priority: Priorität (0-9)
• string $rsa: RSA Schlüssel
• string $db host: Datenbankhost
• string $db user: Datenbankbenutzer
• string $db password: Datenbankpasswort
• string $db name: Datenbankname
Fügt einen neuen Server in das System ein
function check authorized key
1 boolean function check_authorized_key(\$rsa)
in Datei /server-www/libs/ssh functions.inc.php (Zeile 126)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $rsa: RSA Schlüssel
Überprüft ob ein “authorized keys“ Eintrag existiert
function check known host
1 boolean function check_known_host(\$rsa)
in Datei /server-www/libs/ssh functions.inc.php (Zeile 89)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $rsa: RSA Schlüssel
Überprüft ob ein “known Host“ Eintrag existiert
function create rsa key
1 TRUE function create_rsa_key()
in Datei /server-www/libs/ssh functions.inc.php (Zeile 29)
Returnwert: TRUE bei Erfolg, sonst FALSE
Erstellt ein RSA Schlüsselpaar
function create tunnel
1 void function create_tunnel(\$server, \$tunneld_port, \$db_host, [\ ←$ssh_port = 22])
in Datei /server-www/libs/ssh functions.inc.php (Zeile 506)
Funktionsparameter:
Brandstätter Andreas, Klaffl Christoph
Seite 177von 231
ALFSA
KAPITEL 9. ANHANG
• string $server: IP oder Hostname des Servers
• integer $tunneld port: Lokaler Port der zum Tunneln verwendet wird
• string $db host: Datenbankhost
• integer $ssh port: SSH Port
Erstellt einen SSH Porttunnel zu einem anderen Server
function del authorized key
1 void function del_authorized_key(\$rsa, [\$comment = 0])
in Datei /server-www/libs/ssh functions.inc.php (Zeile 182)
Funktionsparameter:
• string $rsa: RSA Schlüssel
• string $comment: Kommentar
Löscht einen “authorized key“ Eintrag
function del server
1 boolean function del_server(\$name)
in Datei /server-www/libs/ssh functions.inc.php (Zeile 303)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $name: Servername
Löscht einen Server aus der Datenbank
function get rsa key
1 string function get_rsa_key()
in Datei /server-www/libs/ssh functions.inc.php (Zeile 14)
Returnwert: string Öffentlichen RSA Schlüssel
Liest den öffentlichen Schlüssel des Benutzers aus, unter dem PHP ausgeführt wird
function get server
1 array function get_server([\$name = ""], [\$rsa_key = ""], [\ ←$show_backup_server = FALSE])
in Datei /server-www/libs/ssh functions.inc.php (Zeile 251)
Returnwert: array Servers/Server
Funktionsparameter:
• string $name: Servername
• string $rsa key: RSA Schlüssel
• boolean $show backup server: Gibt an ob auch Backup Server, also jene mit einer Priorität 0, ausgelesen werden sollen
Liest die verfügbaren Server aus der Datenbank aus
Brandstätter Andreas, Klaffl Christoph
Seite 178von 231
ALFSA
KAPITEL 9. ANHANG
function read authorized keys
1 array function read_authorized_keys()
in Datei /server-www/libs/ssh functions.inc.php (Zeile 113)
Returnwert: array authorized keys
Auslesem der “authorized keys“
function read known hosts
1 array function read_known_hosts()
in Datei /server-www/libs/ssh functions.inc.php (Zeile 46)
Returnwert: array Known Hosts
Auslesem der “known Hosts“
function setup authorized keys
1 boolean function setup_authorized_keys()
in Datei /server-www/libs/ssh functions.inc.php (Zeile 234)
Returnwert: boolean TRUE bei Erfolg, sonst FALSE
Schreibt für alle aktiven Server die “authorized key“ Einträge
function update server
1 boolean function update_server(\$server_name_old, \$hostname, \$ip, \ ←$ssh_port, \$priority, \$rsa, \$db_host,
2 \$db_user, \$db_password, \$db_name, [\$server_name_new = 0])
in Datei /server-www/libs/ssh functions.inc.php (Zeile 445)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $server name old: Alter Servername
• string $hostname: Hostname
• string $ip: IP Addresse
• string $ssh port: SSH Port
• string $priority: Priorität (0-9)
• string $rsa: RSA Schlüssel
• string $db host: Datenbankhost
• string $db user: Datenbankbenutzer
• string $db password: Datenbankpasswort
• string $db name: Datenbankname
• string $server name new: Neuer Servername
Ändert die Details/Eigenschaften eines Servers im System
function update server config
1 boolean function update_server_config(\$server)
Brandstätter Andreas, Klaffl Christoph
Seite 179von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/ssh functions.inc.php (Zeile 524)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• array $server: Serverdetails
Aktualisiert die Serverkonfiguration und übernimmt diese ALFSA weit. Das bedeutet, das bei
Änderungen der Datenbankeinstellungen Kontakt mit den anderen Server aufgenommen wird
und mindestens bei einem die Einstellungen für diesen Server eingetragen werden (damit sich
die Server untereinander die Einstellungen austauschen können)
function calc level
1 integer function calc_level(\$table, \$parents)
in Datei /server-www/libs/sync functions.inc.php (Zeile 404)
Returnwert: integer Beziehungsebene
Funktionsparameter:
• string $table: Tabellenname
• array $parents: Tabellenbaum
Berechnet die Beziehungen der Tabellen untereinander
function check if inkonsistent
1 Falls function check_if_inkonsistent(\$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 812)
Returnwert: Falls inkonsistent TRUE, sonst FALSE
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
Prüft ob die Datenbank inkonsistent ist
function check if table exists
1 boolean function check_if_table_exists(\$tablename, \$dbhandle, \ ←$db_name)
in Datei /server-www/libs/sync functions.inc.php (Zeile 296)
Returnwert: boolean Falls die Tabelle existiert TRUE, sonst FALSE, im Fehlerfall NULL
Funktionsparameter:
• string $tablename: Tabellenname
• ressource $dbhandle: Datenbankhandle
• string $db name: Datenbankname
Überprüft ob eine Tabelle existiert oder nicht
function check lock file
1 boolean function check_lock_file(\$lock_file)
Brandstätter Andreas, Klaffl Christoph
Seite 180von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/sync functions.inc.php (Zeile 797)
Returnwert: boolean Falls die Lock Datei existiert TRUE, sonst FALSE
Funktionsparameter:
• string $lock file: Pfad zur Lock Datei, die überprüft werden soll
Überprüft, ob die Lock Datei existiert
function clean up
1 boolean function clean_up(\$dbhandle, [\$error_recovery = TRUE])
in Datei /server-www/libs/sync functions.inc.php (Zeile 655)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
• $error recovery:
Säubert die Datenbank (löscht temporäre Syncronisationsdaten, aktiviert die Beziehungen
der Datenbank wieder, ...)
function create table
1 void function create_table(\$tablename, \$dbhandle, \$dbhandle2)
in Datei /server-www/libs/sync functions.inc.php (Zeile 323)
Funktionsparameter:
• string $tablename: Tabellenname
• ressource $dbhandle: Datenbankhandle der Zieldatenbank
• ressource $dbhandle2: Datenbankhandle der Quelldatenbank
Erstellt eine Tabelle anhand einer Tabelle aus einer anderen Datenbank mit gleichem Namen
function create table extended
1 void function create_table_extended(\$source_tablename, \ ←$target_tablename, \$dbhandle, \$dbhandle2)
in Datei /server-www/libs/sync functions.inc.php (Zeile 349)
Funktionsparameter:
• string $source tablename: Tabellenname der Quelltabelle
• string $target tablename: Tabellenname der Zieltabelle
• ressource $dbhandle: Datenbankhandle der Zieldatenbank
• ressource $dbhandle2: Datenbankhandle der Quelldatenbank
Erstellt eine Tabelle anhand der Struktur einer anderen Tabelle aus einer anderen Datenbank
function del lock file
1 boolean function del_lock_file(\$lock_file)
in Datei /server-www/libs/sync functions.inc.php (Zeile 782)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Brandstätter Andreas, Klaffl Christoph
Seite 181von 231
ALFSA
KAPITEL 9. ANHANG
Funktionsparameter:
• string $lock file: Pfad zur Lock Datei, die gelöscht werden soll
Löscht eine Lock Datei
function del sync
1 boolean function del_sync()
in Datei /server-www/libs/sync functions.inc.php (Zeile 389)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Setzt die gesamte Syncronisierung zurück
function first sync
1 Falls function first_sync()
in Datei /server-www/libs/sync functions.inc.php (Zeile 376)
Returnwert: Falls es sich um die erste Syncronisierung handelt TRUE, sonst FALSE
Überprüft, ob es sich um die erste Syncronisierung handelt
function format string for html console
1 array function format_string_for_html_console(\$message)
in Datei /server-www/libs/sync functions.inc.php (Zeile 549)
Returnwert: array die verschiedenen Ausgabetexte
Funktionsparameter:
• string $message: Text
Formatiert einen String für verschiedene Ausgabeformate
function get all tables
1 array function get_all_tables(\$dbhandle, [\$show_sync_tables = FALSE ←])
in Datei /server-www/libs/sync functions.inc.php (Zeile 18)
Returnwert: array Tabellen
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
• boolean $show sync tables: Gibt an, ob auch die Tabellen mit dem Suffix “ sync“ angezeigt werden sollen
Liest alle Tabellen aus der Datenbank aus
function get new data
1 array function get_new_data(\$tablename, \$dbhandle, [\$limit_start = ←0], [\$limit_count = 0])
Brandstätter Andreas, Klaffl Christoph
Seite 182von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/sync functions.inc.php (Zeile 179)
Returnwert: array Neue Datensätze
Funktionsparameter:
• string $tablename: Tabellenname
• ressource $dbhandle: Datenbankhandle
• integer $limit start: Datensätze, ab denen selektiert wird
• integer $limit count: Gibt an, wieviele Datensätze maximal zurückgeliefert werden
Liest die neuen Datensätze einer Tabelle ein
function get primary keys
1 array function get_primary_keys(\$tablename, \$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 154)
Returnwert: array Primärschlüssel
Funktionsparameter:
• string $tablename: Tabellenname
• ressource $dbhandle: Datenbankhandle
Liest die primären Schlüssel einer Tabelle aus
function get table levels
1 array function get_table_levels(\$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 467)
Returnwert: array Beziehungsebenen der Tabellen
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
Liest die Beziehungen der Tabellen aus der Datenbank aus
function get table structure
1 array function get_table_structure(\$tablename, \$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 41)
Returnwert: array Tabellenstruktur
Funktionsparameter:
• string $tablename: Tabellenname
• ressource $dbhandle: Datenbankhandle
Liest die Tabellenstruktur einer Tabelle aus der Datenbank aus
function get temporary sync tables
1 array/bollean function get_temporary_sync_tables(\$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 825)
Returnwert: array/bollean temporären Syncronisationstabellen/Bei Fehler FALSE
Funktionsparameter:
Brandstätter Andreas, Klaffl Christoph
Seite 183von 231
ALFSA
KAPITEL 9. ANHANG
• ressource $dbhandle: Datenbankhandle
Liest die temporären Syncronisationstabellen aus der Datenbanka aus
function output
1 void function output(\$string, [\$die = FALSE])
in Datei /server-www/libs/sync functions.inc.php (Zeile 612)
Funktionsparameter:
• string $string: Text, der formatiert und ausgegeben werden soll
• boolean $die: Gibt an, ob abgebrochen werden soll oder nicht
Gibt den Text formatiert für die jeweilige Ausgabe aus (Konsole, Webinterface)
function read sync date
1 integer function read_sync_date(\$server_name)
in Datei /server-www/libs/sync functions.inc.php (Zeile 200)
Returnwert: integer UNIX timestamp
Funktionsparameter:
• string $server name: Servername
Liest das Datum der letzten Syncronisation ein
function set fk off
1 boolean function set_fk_off(\$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 510)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
Schaltet die Beziehungskontrolle der Datenbank aus
function set fk on
1 boolean function set_fk_on(\$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 530)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
Schaltet die Beziehungskontrolle der Datenbank ein
function set lock file
1 boolean function set_lock_file(\$lock_file)
Brandstätter Andreas, Klaffl Christoph
Seite 184von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/sync functions.inc.php (Zeile 767)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• string $lock file: Pfad zur Lock Datei, die gesetzt werden soll
Setzt eine Lock Datei
function sort tables after levels
1 array function sort_tables_after_levels(\$dbhandle, \$array)
in Datei /server-www/libs/sync functions.inc.php (Zeile 486)
Returnwert: array sortierte Tabellen
Funktionsparameter:
• ressource $dbhandle: Datenbankhandle
• array $array: Tabellen
Sortiert die Tabellen nach ihren Beziehungen
function sync error
1 void function sync_error(\$line, \$file, \$string, [\$mysql_error = " ←"], [\$die = TRUE], [\$output = FALSE])
in Datei /server-www/libs/sync functions.inc.php (Zeile 239)
Funktionsparameter:
• integer $line: Zeilennummer, in der der Fehler auftritt
• string $file: Datei, in der der Fehler auftritt
• string $string: Fehlermeldung
• string $mysql error: Falls ein Fehler im Zusammenhang mit der Datenbank auftritt,
wird er hier übergeben
• boolean $die: Gibt an, ob abgebrochen werden soll oder nicht
• boolean $output: Gibt an, ob der Fehler ausgegeben werden soll oder nur ein Verweis
auf die Error Log erfolgt
Fehlerbehandlung und Logging im Falle eines Fehlers
function sync table
1 integer function sync_table(\$source_tablename, \$target_tablename, \ ←$dbhandle, \$dbhandle2)
in Datei /server-www/libs/sync functions.inc.php (Zeile 66)
Returnwert: integer Anzahl der aktualisierten/hinzugefügten Datensätze
Funktionsparameter:
• string $source tablename: Tabellenname der Quelltabelle
• string $target tablename: Tabellenname der Zieltabelle
• ressource $dbhandle: Datenbankhandle der Zieldatenbank
• ressource $dbhandle2: Datenbankhandle der Quelldatenbank
Syncronisiert die Datensätze von einer Tabelle in die andere
Brandstätter Andreas, Klaffl Christoph
Seite 185von 231
ALFSA
KAPITEL 9. ANHANG
function update sync date
1 void function update_sync_date(\$server_name, [\$date = 0])
in Datei /server-www/libs/sync functions.inc.php (Zeile 216)
Funktionsparameter:
• string $server name: Servername
• integer $date: UNIX timestamp
Neues Syncronisationsdatum schreiben
function update table levels
1 void function update_table_levels(\$db_name, \$dbhandle)
in Datei /server-www/libs/sync functions.inc.php (Zeile 420)
Funktionsparameter:
• string $db name: Datenbankname
• ressource $dbhandle: Datenbankhandle
Aktualisiert die Beziehungen der Tabellen
function update table structure
1 void function update_table_structure(\$tablename, \$dbhandle, \ ←$dbhandle2)
in Datei /server-www/libs/sync functions.inc.php (Zeile 635)
Funktionsparameter:
• string $tablename: Tabellenname
• ressource $dbhandle: Datenbankhandle der Zieldatenbank
• ressource $dbhandle2: Datenbankhandle der Quelldatenbank
Temporäre Tabelle mit dem Suffix “ sync“ erstellen und die Tabellestruktur einer gleichnamigen Tabelle aus einer anderen Datenbank übernehmen
function get cpuclock
1 string function get_cpuclock()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 46)
Returnwert: string Taktrate
Liest die aktuelle Taktrate des Prozessors ein
function get cpupercent
1 integer function get_cpupercent()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 15)
Returnwert: integer CPU Auslastung in Prozent
Liest die aktuelle CPU Auslastung aus (Achtung: wartet 1 Sekunde)
Brandstätter Andreas, Klaffl Christoph
Seite 186von 231
ALFSA
KAPITEL 9. ANHANG
function get date
1 string function get_date()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 197)
Returnwert: string Datum - Uhrzeit
Ruft das aktuelle Datum und die Uhrzeit ab
function get diskspace
1 array function get_diskspace([\$disk = "./"])
in Datei /server-www/libs/sysinfo.inc.php (Zeile 184)
Returnwert: array Partitionsbelegung
Funktionsparameter:
• $disk:
Ermittelt die Partitionsbelegung
function get distri
1 string/boolean function get_distri([\$use_lsb = false])
in Datei /server-www/libs/sysinfo.inc.php (Zeile 70)
Returnwert: string/boolean Distributionsbezeichnung / im Fehlerfall FALSE
Funktionsparameter:
• boolean $use lsb: Gibt an, ob die LSB Methode zur Ermittlung der Distribution verwendet werden soll
Ermittelt die eingesetzte Distribution
function get ip
1 string function get_ip()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 283)
Returnwert: string IP Addresse
Ermittelt die eigene IP
function get netstats
1 array/boolean function get_netstats([\$device = "eth0"])
in Datei /server-www/libs/sysinfo.inc.php (Zeile 240)
Returnwert: array/boolean Netzwerkstatistik/Im Fehlerfall FALSE
Funktionsparameter:
• $device:
Fragt den Status eines Netzwerkgeräts ab
function get ram
Brandstätter Andreas, Klaffl Christoph
Seite 187von 231
ALFSA
KAPITEL 9. ANHANG
1 array function get_ram()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 120)
Returnwert: array RAM Belegung
Ermittelt die RAM Belegung
function get server status
1 boolean function get_server_status(\$service)
in Datei /server-www/libs/sysinfo.inc.php (Zeile 270)
Returnwert: boolean Falls der Dienst läuft TRUE, sonst FALSE
Funktionsparameter:
• $service:
Überprüft ob ein Dienst läuft oder nicht
function get swap
1 array function get_swap()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 142)
Returnwert: array SWAP Belegung
Ermittelt die SWAP Belegung
function get temperature
1 integer/bollean function get_temperature()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 166)
Returnwert: integer/bollean Temperatur / Im Fehlerfall FALSE
Ermittelt die Temperatur
function get uptime
1 string function get_uptime()
in Datei /server-www/libs/sysinfo.inc.php (Zeile 207)
Returnwert: string uptime
Fragt die aktuelle uptime ab
function add user
1 boolean function add_user(\$fwnr, \$stbnr, \$fuellstelle, \$vorname,
\$nachname, \$password, \$stadt, \$plz,
2 \$strasze, \$hausnummer, \$dienstgrad, \$admin)
←-
in Datei /server-www/libs/user.inc.php (Zeile 208)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
Brandstätter Andreas, Klaffl Christoph
Seite 188von 231
ALFSA
•
•
•
•
•
•
•
•
•
•
•
•
Fügt
KAPITEL 9. ANHANG
integer $fwnr: Feuerwehrnummer
integer $stbnr: Standesbuchnummer
integer $fuellstelle: Füllstellennummer
string $vorname: Vorname
string $nachname: Nachname
string $password: Passwort
string $stadt: Stadt
string $strasze: Straße
integer $hausnummer: Hausnummer
string $dienstgrad: Dienstgrad
integer/enum $admin: Gibt an, ob der Benutzer Admin ist (Wert=1) oder nicht (Wert=0)
$plz:
einen neuen Benutzer in die Datenbank ein
function change user
1 boolean function change_user(\$fwnr, \$stbnr, \$fuellstelle, \ ←$vorname, \$nachname, \$password, \$stadt, \$plz,
2 \$strasze, \$hausnummer, \$dienstgrad, \$admin)
in Datei /server-www/libs/user.inc.php (Zeile 135)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
• integer $fuellstelle: Füllstellennummer
• string $vorname: Vorname
• string $nachname: Nachname
• string $password: Passwort
• string $stadt: Stadt
• string $strasze: Straße
• integer $hausnummer: Hausnummer
• string $dienstgrad: Dienstgrad
• integer/enum $admin: Gibt an, ob der Benutzer Admin ist (Wert=1) oder nicht (Wert=0)
• $plz:
Ändert die Eigenschaften/Details eines Benutzers
function check cookie passwd hash
1 bollean function check_cookie_passwd_hash()
in Datei /server-www/libs/user.inc.php (Zeile 569)
Returnwert: bollean Falls das Cookie gültig ist TRUE, sonst FALSE
Überprüft ob das Passwort im Cookie stimmt
function del user
Brandstätter Andreas, Klaffl Christoph
Seite 189von 231
ALFSA
KAPITEL 9. ANHANG
1 boolean function del_user(\$fwnr, \$stbnr)
in Datei /server-www/libs/user.inc.php (Zeile 102)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
Löscht einen Kompressor aus der Datenbank
function get alias for permission
1 string function get_alias_for_permission(\$permission)
in Datei /server-www/libs/user.inc.php (Zeile 540)
Returnwert: string Berechtigung in lesbarer Form; falls keine Übersetzung vorhanden ist, das
Berechtigungskürzel
Funktionsparameter:
• string $permission: Berechtigungskürzel
Übersetzt die Berechtigungskürzel in eine für den Benutzer lesbare Form
function get available areas
1 array function get_available_areas()
in Datei /server-www/libs/user.inc.php (Zeile 328)
Returnwert: array verfügbare Berechtigungsbereiche
Liest die verfügbaren Berechtigungsbereiche aus einem ENUM Feld der Datenbankstruktur
aus
function get available permissions
1 array function get_available_permissions()
in Datei /server-www/libs/user.inc.php (Zeile 295)
Returnwert: array verfügbare Berechtigungen
Liest die verfügbaren Berechtigungen aus einem ENUM Feld der Datanbankstruktur aus
function get dienstgrade
1 array function get_dienstgrade([\$nr = 0])
in Datei /server-www/libs/user.inc.php (Zeile 270)
Returnwert: array Dienstgrade/Dienstgrad
Funktionsparameter:
• integer $nr: Dienstgradnummer
Liest die verfügabren Dienstgrade/einen Dienstgrad aus der Datenbank aus
Brandstätter Andreas, Klaffl Christoph
Seite 190von 231
ALFSA
KAPITEL 9. ANHANG
function get fwnr and stbnr
1 string function get_fwnr_and_stbnr()
in Datei /server-www/libs/user.inc.php (Zeile 527)
Returnwert: string Feuerwehrnummer und Standesbuchnummer im Format Feuerwehrnummer/Standesbuchnummer
Liest die Feuerwehrnummer und die Standesbuchnummer des angemeldeten Benutzers aus
function get permissions
1 array function get_permissions(\$fwnr, \$stbnr)
in Datei /server-www/libs/user.inc.php (Zeile 363)
Returnwert: array Berechtigungen des angegebenen Benutzers
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
Fragt die Berechtigungen eines Benutzers ab
function get username
1 string/boolean function get_username()
in Datei /server-www/libs/user.inc.php (Zeile 515)
Returnwert: string/boolean Benutzernamen/Falls kein Benutzer angemeldet ist FALSE
Liest den Benutzernamen des angemeldeten Benutzers aus
function get users
1 array function get_users([\$bezirk = 0], [\$abschnitt = 0], [\$fwnr = ←0], [\$limit_start = 0], [\$limit_count = 0],
2 [\$show_deleted = 2])
in Datei /server-www/libs/user.inc.php (Zeile 20)
Returnwert: array Benutzer
Funktionsparameter:
• integer $bezirk: Berzirksnummer
• integer $abschnitt: Abschnittsnummer
• integer $fwnr: Feuerwehrnummer
• integer $limit start: Datensätze, ab denen selektiert wird
• integer $limit count: Gibt an, wie viele Benutzer zurückgeliefert werden sollen
• integer $show deleted: Gibt an, welche Benutzer zurückgegeben werden (0 = nur aktive,
1 = nur gelöschte/abgeschlossene, 2 = aktive und gelöschte/abgeschlossene)
Liefert Benutzer aus der Datenbank
function get user details
1 array function get_user_details(\$fwnr, \$stbnr)
Brandstätter Andreas, Klaffl Christoph
Seite 191von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/libs/user.inc.php (Zeile 82)
Returnwert: array Benutzerdetails
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
Liefert Details über einen Benutzer aus der Datenbank
function isloggedon
1 boolean function isloggedon()
in Datei /server-www/libs/user.inc.php (Zeile 440)
Returnwert: boolean Falls ein Benutzer angemeldet ist TRUE, sonst FALSE
Überprüft ob ein Benutzer eingeloggt ist
function is admin
1 boolean function is_admin(\$fwnr, \$stbnr)
in Datei /server-www/libs/user.inc.php (Zeile 382)
Returnwert: boolean TRUE falls der Benutzer ein Administrator ist, sonst FALSE (auch im
Fehlerfall)
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
Überprüft ob ein Benutzer ein Administrator ist
function login
1 boolean function login(\$fwnr, \$stbnr, \$passwd, [\$use_cookies =
FALSE])
←-
in Datei /server-www/libs/user.inc.php (Zeile 458)
Returnwert: boolean Bei Erfolg TRUE, sonst FALSE
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
• string $passwd: Passwort
• boolean $use cookies: Gibt an, ob Cookies angelegt werden sollen (TRUE) oder nicht
(FALSE)
Meldet einen Benutzer an
function logout
1 boolean function logout()
in Datei /server-www/libs/user.inc.php (Zeile 490)
Returnwert: boolean Bei Abmeldung TRUE, wenn kein Benutzer angemeldet ist FALSE
Brandstätter Andreas, Klaffl Christoph
Seite 192von 231
ALFSA
KAPITEL 9. ANHANG
Meldet den angemeldeten Benutzer ab
function set permissions
1 void function set_permissions(\$fwnr, \$stbnr, \$settings)
in Datei /server-www/libs/user.inc.php (Zeile 401)
Funktionsparameter:
• integer $fwnr: Feuerwehrnummer
• integer $stbnr: Standesbuchnummer
• array $settings: Enthält die Berechtigungen mit ihren Werte, die gesetzt werden sollen
Setzt Berechtugungen für einen Benutzer
function new draw table
1 void function new_draw_table(\$name, \$fields, [\$wfk = TRUE])
in Datei /server-www/pages/draw tables.inc.php (Zeile 51)
Funktionsparameter:
• string $name: Tabellenname
• array $fields: Spalten der Tabelle
• boolean $wfk: Darstellung mit oder ohne Foreign keys
Funktion zum Zeichnen von Tabellen
9.1.3
Teil Client-Server-Sync am Server
function append to log
1 void function append_to_log(\$title, \$data, [\$type = "standard"])
in Datei /server-www/client-sync/functions.inc.php (Zeile 310)
Funktionsparameter:
• string $title: Titel des Logeintrages.
• string $data: Daten des Logeintrages.
• string $type: Art des Logeintrages.
Speichert Log-Eintraege in die Logdatei.
function error
1 void function error(\$line, \$file, \$string, [\$error = ""], \$sql)
in Datei /server-www/client-sync/functions.inc.php (Zeile 21)
Funktionsparameter:
• int $line: Zeile, in der die Fehlermeldung ausgloest wurde.
• int $file: Datei, in der die Fehlermeldung ausgloest wurde.
• string $string: Beschreibung des Fehlers.
• string $error: Fehlermeldung, die von MySQL zurueckgegeben wird.
• string $sql: MySQL-String, der den Fehler verursachte.
Brandstätter Andreas, Klaffl Christoph
Seite 193von 231
ALFSA
KAPITEL 9. ANHANG
Gibt eine formatierte MySQL-Fehlermeldung aus.
function get filename of cache file
1 string function get_filename_of_cache_file([\$phase = -1])
in Datei /server-www/client-sync/functions.inc.php (Zeile 145)
Returnwert: string Dateiname fuer die Datei.
Funktionsparameter:
• int $phase: Aktueller Arbeitsschritt.
Liefert den Dateinamen fuer die Datei zur zwischenspeicherung von SQL-Befehlen.
function get primary keys
1 array function get_primary_keys(\$table)
in Datei /server-www/client-sync/functions.inc.php (Zeile 160)
Returnwert: array Primaerschluessel der Tabelle.
Funktionsparameter:
• string $table: Name der Tabelle.
Liefert die Primaerschluessel einer Tabelle aus der Datenbank.
function get referenced tables
1 array function get_referenced_tables(\$table)
in Datei /server-www/client-sync/functions.inc.php (Zeile 95)
Returnwert: array Tabellen, die von der gegebenen Tabelle abhaengen.
Funktionsparameter:
• string $table: Name der Tabelle
Liefert eine Auflistung aller Tabellen, die von einer gegebenen Tabelle ueber Foreign-Keys
abhaengen.
function get referenced tables recursive
1 array function get_referenced_tables_recursive(\$table)
in Datei /server-www/client-sync/functions.inc.php (Zeile 125)
Returnwert: array Tabellen, die rekursiv von der gegebenen Tabelle abhaengen.
Funktionsparameter:
• string $table: Name der Tabelle
Liefert eine Auflistung aller Tabellen, die von einer gegebenen Tabelle ueber Foreign-Keys
abhaengen. Abhaengende Tabellen werden rekursiv analysiert.
function get right client
1 string function get_right_client(\$table, [\$type = "from_client"])
Brandstätter Andreas, Klaffl Christoph
Seite 194von 231
ALFSA
KAPITEL 9. ANHANG
in Datei /server-www/client-sync/functions.inc.php (Zeile 185)
Returnwert: string Berechtigung fuer die Tabelle und Art der Berechtigung.
Funktionsparameter:
• string $table: Name der Tabelle.
• string $type: Art der Berechtigung.
Liefert die Client-Berechtigungen einer Tabelle aus der Datenbank.
function get tables
1 array function get_tables()
in Datei /server-www/client-sync/functions.inc.php (Zeile 65)
Returnwert: array Tabellen der Datenbank mit Level.
Liefert eine Auflistung aller Tabellen der Datenbank. Lest zusaetzlich das Level aus der Tabelle
sync aus.
function my extract
1 void function my_extract(\$post_data, [\$decode = TRUE])
in Datei /server-www/client-sync/functions.inc.php (Zeile 38)
Funktionsparameter:
• string $post data: POST-Daten der Client-Anfrage.
• bool $decode: Gibt an, ob die Daten des Clients URL-Codiert sind.
Extrahiert die Datensaetze aus den POST-Daten der Client-Anfragen.
function read cache data
1 void function read_cache_data()
in Datei /server-www/client-sync/functions.inc.php (Zeile 267)
Gibt temporaere SQL-Anfragen aus der Datei zur Zwischenspeicherung aus.
function write cache data
1 void function write_cache_data(\$tables, \$last_sync_date)
in Datei /server-www/client-sync/functions.inc.php (Zeile 208)
Funktionsparameter:
• string $tables: Namen der Tabellen.
• int $last sync date: Datum der letzen Synchronisierung.
Speichert temporaere SQL-Anfragen in die Datei zur Zwischenspeicherung. Maximale Ausfuehrungszeit in Sekunden, bis ein Fehler in der Logdatei eingetragen wird. Maximaler Zeitversatz in Minuten zum Client. Prozessdatei fuer Arbeitsschritt 2 fuer Client-Server-Synchronisation.
Prozessdatei fuer Arbeitsschritt 3 fuer Client-Server-Synchronisation.
Brandstätter Andreas, Klaffl Christoph
Seite 195von 231
ALFSA
9.1.4
KAPITEL 9. ANHANG
Teil Mehrfach genutzt
class Template in Datei /server-www/libs/template.inc.php (Zeile 12) Klasse für TemplateEnginge. Klassenvariable Template::$inhalt Template::$inhalt = in Datei /server-www/libs/template.inc
(Zeile 17) Klassenvariable Template::$replace Template::$replace = in Datei /server-www/libs/template.
(Zeile 21) Klassenvariable Template::$start Template::$start = in Datei /server-www/libs/template.inc.p
(Zeile 25)
Constructor function Template::Template
1 Constructor void function Template::Template(\$name, [\$local_start = ←0])
in Datei /server-www/libs/template.inc.php (Zeile 150)
Funktionsparameter:
• string $name: Dateiname des Templates.
• int $local start: Startzeit der Seite.
Initialisiert das Template. Lädt die Template-Datei.
function Template::display
1 void function Template::display()
in Datei /server-www/libs/template.inc.php (Zeile 106)
Gibt das Ergebnis an den Browser aus.
function Template::get html
1 string function Template::get_html()
in Datei /server-www/libs/template.inc.php (Zeile 117)
Liefert das Ergebnis als Return-Wert.
function Template::process
1 void function Template::process()
in Datei /server-www/libs/template.inc.php (Zeile 30)
Führt die Ersetzung der Werte und erweiterten Funktioenen durch.
function Template::read diff page
1 void function Template::read_diff_page(\$filename)
in Datei /server-www/libs/template.inc.php (Zeile 186)
Funktionsparameter:
• string $filename: Dateiname des differentialen Templates.
Initialisiert das Template mit einer differentialen Template-Datei.
Brandstätter Andreas, Klaffl Christoph
Seite 196von 231
ALFSA
KAPITEL 9. ANHANG
function Template::set
1 void function Template::set(\$key, \$value)
in Datei /server-www/libs/template.inc.php (Zeile 139)
Funktionsparameter:
• string $key: Schlüssel zu Identifikation im Template.
• string/array $value: Wert der Ersetzung.
Setzt einen Wert zur Ersetzung.
function Template::set html
1 void function Template::set_html(\$set_html)
in Datei /server-www/libs/template.inc.php (Zeile 128)
Funktionsparameter:
• string $set html: HTML-Text zum Schreiben in das Template.
Setzt den Inhalt des Templates.
9.2
Tabellen
9.2.1
Tabelle abschnitte
9.2.2
Tabelle atemluftflaschen fuellung
Brandstätter Andreas, Klaffl Christoph
Seite 197von 231
ALFSA
KAPITEL 9. ANHANG
9.2.3
Tabelle atemluftflaschen maengel
9.2.4
Tabelle atemluftflaschen
Brandstätter Andreas, Klaffl Christoph
Seite 198von 231
ALFSA
KAPITEL 9. ANHANG
9.2.5
Tabelle atemluftflaschen pruefung
9.2.6
Tabelle atemschutzgeraete maengel
Brandstätter Andreas, Klaffl Christoph
Seite 199von 231
ALFSA
KAPITEL 9. ANHANG
9.2.7
Tabelle atemschutzgeraete
9.2.8
Tabelle atemschutzgeraete pruefung
Brandstätter Andreas, Klaffl Christoph
Seite 200von 231
ALFSA
9.2.9
KAPITEL 9. ANHANG
Tabelle atemschutzgeraete wartung
9.2.10
Tabelle atemschutzmasken maengel
9.2.11
Tabelle atemschutzmasken
Brandstätter Andreas, Klaffl Christoph
Seite 201von 231
ALFSA
KAPITEL 9. ANHANG
9.2.12
Tabelle atemschutzmasken wartung
9.2.13
Tabelle benutzer anmeldung
Brandstätter Andreas, Klaffl Christoph
Seite 202von 231
ALFSA
9.2.14
KAPITEL 9. ANHANG
Tabelle benutzer
Brandstätter Andreas, Klaffl Christoph
Seite 203von 231
ALFSA
KAPITEL 9. ANHANG
9.2.15
Tabelle benutzer schulung
9.2.16
Tabelle bezirke
9.2.17
Tabelle client
9.2.18
Tabelle dienstgrade
Brandstätter Andreas, Klaffl Christoph
Seite 204von 231
ALFSA
KAPITEL 9. ANHANG
9.2.19
Tabelle einsatz
9.2.20
Tabelle feuerwehren
9.2.21
Tabelle fremdflaschen fuellung
Brandstätter Andreas, Klaffl Christoph
Seite 205von 231
ALFSA
KAPITEL 9. ANHANG
9.2.22
Tabelle fremdflaschen
9.2.23
Tabelle fuell sitzung
9.2.24
Tabelle fuellstelle
9.2.25
Tabelle geraetetraeger
Brandstätter Andreas, Klaffl Christoph
Seite 206von 231
ALFSA
KAPITEL 9. ANHANG
9.2.26
Tabelle geraetetraeger untersuchung
9.2.27
Tabelle gruppen
9.2.28
Tabelle gruppen user
Brandstätter Andreas, Klaffl Christoph
Seite 207von 231
ALFSA
KAPITEL 9. ANHANG
9.2.29
Tabelle kompressoren maengel
9.2.30
Tabelle kompressoren
Brandstätter Andreas, Klaffl Christoph
Seite 208von 231
ALFSA
KAPITEL 9. ANHANG
9.2.31
Tabelle kompressoren pruefung
9.2.32
Tabelle kompressoren wartung
9.2.33
Tabelle nachrichten gelesen
Brandstätter Andreas, Klaffl Christoph
Seite 209von 231
ALFSA
KAPITEL 9. ANHANG
9.2.34
Tabelle nachrichten
9.2.35
Tabelle permission
9.2.36
Tabelle person kontakt
Brandstätter Andreas, Klaffl Christoph
Seite 210von 231
ALFSA
KAPITEL 9. ANHANG
9.2.37
Tabelle person
9.2.38
Tabelle person telefon
9.2.39
Tabelle schulung
Brandstätter Andreas, Klaffl Christoph
Seite 211von 231
ALFSA
KAPITEL 9. ANHANG
9.2.40
Tabelle server details
9.2.41
Tabelle server
9.2.42
Tabelle sync
9.2.43
Tabelle sync server log
Brandstätter Andreas, Klaffl Christoph
Seite 212von 231
ALFSA
KAPITEL 9. ANHANG
9.2.44
Tabelle sync vorgang
9.2.45
Tabelle verbindungskennung
9.3
Dateiliste
Folgende Auflistung beinhaltet alle relevanten Dateien der Diplomarbeit des Clients und des
Servers.
• ./server-www
Verzeichnis aller Dateien das Servers
• ./server-www/templates
Verzeichnis für Templates des Servers
• ./server-www/templates/header.html
Template für den HTML-Header
• ./server-www/templates/list server.html
Template für die Darstellung der Serverliste
• ./server-www/templates/infoline.html
Template für die Darstellung der allgemeinen Infoleiste
• ./server-www/templates/add server.html
Template für das Einfügen eines Servers
• ./server-www/templates/list fuellstelle.html
Template für die Darstellung der Füllstellenliste
Brandstätter Andreas, Klaffl Christoph
Seite 213von 231
ALFSA
KAPITEL 9. ANHANG
• ./server-www/templates/add fw.html
Template für das Einfügen einer Feuerwehr
• ./server-www/templates/add user.html
Template für die Einfügen eines Benutzers
• ./server-www/templates/menu.html
Template für die Darstellung der Navigationsmenü
• ./server-www/templates/add client.html
Template für das Einfügen eines Clients
• ./server-www/templates/change user details.html
Template für das Bearbeiten eines Benutzers
• ./server-www/templates/change server details.html
Template für die Darstellung der Serverdaten
• ./server-www/templates/list fw details.html
Template für die Darstellung der Feuerwehrdaten
• ./server-www/templates/change fuellstelle details.html
Template für die Darstellung der Füllstellendaten
• ./server-www/templates/list fw.html
Template für die Darstellung der Feuerwehrenliste
• ./server-www/templates/.htaccess
Datei um den direkten Zugriff auf die Datein zu unterbinden
• ./server-www/templates/add fuellstelle.html
Template für das Erstellen einer Füllstelle
• ./server-www/templates/list servers.html
Template für die Darstellung der Serverliste
• ./server-www/templates/add compressor.html
Template für das Einfügen eines Kompressors
• ./server-www/templates/login.html
Template für die Darstellung der Loginmaske
• ./server-www/templates/list clients.html
Template für die Darstellung der Clientliste
• ./server-www/templates/list compressors.html
Template für die Darstellung der Kompressorliste
• ./server-www/templates/change fw details.html
Template für das Bearbeiten von Feuerwehren
Brandstätter Andreas, Klaffl Christoph
Seite 214von 231
ALFSA
KAPITEL 9. ANHANG
• ./server-www/templates/first sync.html
Template für die erste Synchronisation
• ./server-www/templates/list compressor details.html
Template für die Darstellung der Kompressordaten
• ./server-www/templates/sync server.html
Template für die Synchronisation
• ./server-www/templates/list client details.html
Template für die Darstellung der Clientdaten
• ./server-www/templates/log.html
Template für die Logansicht
• ./server-www/templates/foother.html
Template für den Seitenfuß
• ./server-www/templates/list user details.html
Template für die Darstellung der Benutzerdaten
• ./server-www/templates/list fuellstelle details.html
Template für die Darstellung der Füllstellendaten
• ./server-www/templates/main.html
Template für die Darstellung der Haupseite
• ./server-www/templates/list server details.html
Template für die Darstellung der Serverdate
• ./server-www/templates/list users.html
Template für die Darstellung der Benutzerliste
• ./server-www/templates/change client details.html
Template für das Bearbeiten von Clientdaten
• ./server-www/templates/setup.html
Template für die Konfiguration
• ./server-www/templates/change compressor details.html
Template für das Bearbeiten von Kompressordaten
• ./server-www/templates/change permissions.html
Template für das Bearbeiten von Berechtigungen
• ./server-www/templates/meldung.html
Template für die Darstellung von Meldungen
• ./server-www/pages
Verzeichnis aller Darstellungsseiten am Server
Brandstätter Andreas, Klaffl Christoph
Seite 215von 231
ALFSA
KAPITEL 9. ANHANG
• ./server-www/pages/main.inc.php
Haupseite
• ./server-www/pages/setup.inc.php
Seite der Konfiguration
• ./server-www/pages/sync.inc.php
Seite der Synchronisation
• ./server-www/pages/list users.inc.php
Seite der Benutzerliste
• ./server-www/pages/.htaccess
Datei um den direkten Zugriff auf die Datein zu unterbinden
• ./server-www/pages/list server.inc.php
Seite der Serverliste
• ./server-www/pages/logs.inc.php
Seite der Logdateien
• ./server-www/pages/list servers.inc.php
Seite der Serverliste
• ./server-www/pages/draw tables.inc.php
Seite zum Zeichnen von Tabellen
• ./server-www/pages/list compressors.inc.php
Seite der Kompressorliste
• ./server-www/pages/list clients.inc.php
Seite der Clientliste
• ./server-www/pages/server test.inc.php
Seite der Servertests
• ./server-www/pages/list fw.inc.php
Seite der Feuerwehren
• ./server-www/pages/list fuellstelle.inc.php
Seite der Füllstelle
• ./server-www/pages/login.inc.php
Seite zum Einloggen
• ./server-www/dhtml.js
Javascript-Funktionen
• ./server-www/images
Verzeichnis aller Bilder am Server
Brandstätter Andreas, Klaffl Christoph
Seite 216von 231
ALFSA
KAPITEL 9. ANHANG
• ./server-www/images/¡verschiedene Bilder¿
verschiedene Bilder
• ./server-www/libs
Verzeichnis aller Libraries am Server
• ./server-www/libs/misc.inc.php
verschiedene Funktionen
• ./server-www/libs/net.inc.php
Netzwerk-Funktionen
• ./server-www/libs/sysinfo.inc.php
Funktionen zum Auslesen von Systeminformationen
• ./server-www/libs/ssh functions.inc.php
SSH-Funktionen
• ./server-www/libs/user.inc.php
Benutzer-Funktionen
• ./server-www/libs/client.inc.php
Client-Funktionen
• ./server-www/libs/setup.inc.php
Konfigurations-Funktionen
• ./server-www/libs/sync functions.inc.php
Sychronisations-Funktionen
• ./server-www/libs/.htaccess
Datei um den direkten Zugriff auf die Datein zu unterbinden
• ./server-www/libs/template.inc.php
Template-Funktionen
• ./server-www/libs/defines.inc.php
Definition von Konstanten
• ./server-www/libs/fw.inc.php
Feuerwehr-Funktionen
• ./server-www/libs/cron.inc.php
cron-Funktionen
• ./server-www/libs/fuellstelle.inc.php
Füllstellen-Funktionen
• ./server-www/libs/compressor.inc.php
Kompressor-Funktionen
Brandstätter Andreas, Klaffl Christoph
Seite 217von 231
ALFSA
KAPITEL 9. ANHANG
• ./server-www/style.css
CSS-Datei für das Design
• ./server-www/conf
Konfigurationsordner
• ./server-www/index.php
Hauptdatei
• ./server-www/client-sync
Verzeichnis für Client-Synchronisation
• ./server-www/client-sync/config.inc.php
Konfiguration für Client-Synchronisation
• ./server-www/client-sync/functions.inc.php
Funktionen für Client-Synchronisation
• ./server-www/client-sync/phase 3.inc.php
Datei von Arbeitsschritt 3 für Client-Synchronisation
• ./server-www/client-sync/phase 2.inc.php
Datei von Arbeitsschritt 2 für Client-Synchronisation
• ./server-www/client-sync/phase 0.inc.php
Datei von Arbeitsschritt 0 für Client-Synchronisation
• ./server-www/client-sync/index.php
Hauptdatei für Client-Synchronisation
• ./server-www/client-sync/phase 1.inc.php
Datei von Arbeitsschritt 1 für Client-Synchronisation
• ./client-www
Verzeichnis aller Dateien das Clients
• ./client-www/sync
Verzeichnis aller Dateien der Client-Synchronisation
• ./client-www/sync/new phase 1.inc.php
Datei von Arbeitsschritt 0 für Client-Synchronisation
• ./client-www/sync/new phase 5.inc.php
Datei von Arbeitsschritt 0 für Client-Synchronisation
• ./client-www/sync/config.inc.php
Konfiguration für Client-Synchronisation
• ./client-www/sync/new phase 0.inc.php
Datei von Arbeitsschritt 0 für Client-Synchronisation
Brandstätter Andreas, Klaffl Christoph
Seite 218von 231
ALFSA
KAPITEL 9. ANHANG
• ./client-www/sync/new phase 4.inc.php
Datei von Arbeitsschritt 4 für Client-Synchronisation
• ./client-www/sync/sync functions.inc.php
Funktionen für Client-Synchronisation
• ./client-www/sync/new phase 3.inc.php
Datei von Arbeitsschritt 3 für Client-Synchronisation
• ./client-www/sync/index.php
Haupdatei für Client-Synchronisation
• ./client-www/sync/new phase 2.inc.php
Datei von Arbeitsschritt 2 für Client-Synchronisation
• ./client-www/conf
Datei von Arbeitsschritt 0 für Client-Synchronisation
• ./client-www/conf/end.date
Datei für Datum der letzen vollständigen Synchronisation
• ./client-www/conf/rev.log
Datei für Nummer der Revision
• ./client-www/conf/settings.inc.php
Datei für Client-Einstellungen
• ./client-www/conf/sync.phase
Datei für Arbeitsschritt der aktuellen Synchronisation
Brandstätter Andreas, Klaffl Christoph
Seite 219von 231
ALFSA
ABBILDUNGSVERZEICHNIS
Abbildungsverzeichnis
1.1
1.2
1.3
Struktur der verteilten Datenbank . . . . . . . . . . . . . . . . . . . . . . . . .
Strukturplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Korpsabzeichen der Feuerwehren in Österreich . . . . . . . . . . . . . . . . . .
9
11
25
2.1
2.2
2.3
2.4
2.5
Das Filesharing Problem . . . .
Das Lock-Modify-Unlock Model
Das Copy-Modify-Merge Model
SSL Sitzungsaufbau . . . . . . .
PHP Funktionsprinzip . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
39
41
46
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
Abhängigkeiten Linear, Ring . . . . . . . .
Grundlegende Datenbankstruktur . . . . .
wichtige Beziehungen von Atemluftflaschen
Grundlegende Struktur von Füllungen . .
Tabelle einsatz . . . . . . . . . . . . . . .
Server Tabelle . . . . . . . . . . . . . . . .
Server Details Tabelle . . . . . . . . . . .
Sync Tabelle . . . . . . . . . . . . . . . . .
Sequenzdiagramm . . . . . . . . . . . . . .
Dateiübersicht . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 73
. 74
. 74
. 75
. 77
. 81
. 81
. 81
. 108
. 111
6.1
Break-Even-Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.1
7.2
Das Firmenlogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Das Produktlogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.1
8.2
8.3
8.4
8.5
8.6
8.7
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
Erste Synchronisierung
Keine Berechtigung . .
Nicht registriert . . . .
Hauptseite . . . . . . .
Hauptseite . . . . . . .
Benutzerverwaltung . .
Benutzerverwaltung2 .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
135
135
136
136
137
138
140
Seite 220von 231
ALFSA
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.22
8.23
8.24
8.25
8.26
ABBILDUNGSVERZEICHNIS
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
ALFSA
Benutzerverwaltung3 .
Feuerwehrverwaltung .
Feuerwehrverwaltung2 .
Fuellstellenverwaltung .
Fuellstellenverwaltung2
Clientverwaltung . . . .
Clientverwaltung2 . . .
Kompressorverwaltung
Kompressorverwaltung2
Serverliste . . . . . . .
Serververwaltung . . .
Serververwaltung2 . . .
Konfiguration . . . . .
Synchronisieren . . . .
Synchronisieren2 . . . .
LOGViewer . . . . . .
LOGViewer2 . . . . . .
Tabellenansicht . . . .
Fehlerhafte Eingabe . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
7.1 Tabelle abschnitte . . . . . . . . . .
7.2 Tabelle atemluftflaschen fuellung . .
7.3 Tabelle atemluftflaschen maengel . .
7.4 Tabelle atemluftflaschen . . . . . . .
7.5 Tabelle atemluftflaschen pruefung . .
7.6 Tabelle atemschutzgeraete maengel .
7.7 Tabelle atemschutzgeraete . . . . . .
7.8 Tabelle atemschutzgeraete pruefung .
7.9 Tabelle atemschutzgeraete wartung .
7.10 Tabelle atemschutzmasken maengel
7.11 Tabelle atemschutzmasken . . . . .
7.12 Tabelle atemschutzmasken wartung
7.13 Tabelle benutzer anmeldung . . . .
7.14 Tabelle benutzer . . . . . . . . . . .
7.15 Tabelle benutzer schulung . . . . .
7.16 Tabelle bezirke . . . . . . . . . . . .
7.17 Tabelle client . . . . . . . . . . . .
7.18 Tabelle dienstgrade . . . . . . . . .
7.19 Tabelle einsatz . . . . . . . . . . . .
7.20 Tabelle feuerwehren . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
197
197
198
198
199
199
200
200
201
201
201
202
202
203
204
204
204
204
205
205
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Seite 221von 231
ALFSA
7.21
7.22
7.23
7.24
7.25
7.26
7.27
7.28
7.29
7.30
7.31
7.32
7.33
7.34
7.35
7.36
7.37
7.38
7.39
7.40
7.41
7.42
7.43
7.44
7.45
ABBILDUNGSVERZEICHNIS
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
Tabelle
fremdflaschen fuellung . . .
fremdflaschen . . . . . . . .
fuell sitzung . . . . . . . . .
fuellstelle . . . . . . . . . .
geraetetraeger . . . . . . . .
geraetetraeger untersuchung
gruppen . . . . . . . . . . .
gruppen user . . . . . . . .
kompressoren maengel . . .
kompressoren . . . . . . . .
kompressoren pruefung . . .
kompressoren wartung . . .
nachrichten gelesen . . . . .
nachrichten . . . . . . . . .
permission . . . . . . . . . .
person kontakt . . . . . . .
person . . . . . . . . . . . .
person telefon . . . . . . . .
schulung . . . . . . . . . . .
server details . . . . . . . .
server . . . . . . . . . . . .
sync . . . . . . . . . . . . .
sync server log . . . . . . .
sync vorgang . . . . . . . .
verbindungskennung . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
205
206
206
206
206
207
207
207
208
208
209
209
209
210
210
210
211
211
211
212
212
212
212
213
213
Seite 222von 231
ALFSA
LISTINGS
Listings
2.1
2.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
PHP Syntaxbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JAVA Syntaxbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Systemaktualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSH Server installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SSH Konfiguration: Root Login verbieten . . . . . . . . . . . . . . . . . . . . .
SSH Server neustarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MySQL Datenbankserver installieren . . . . . . . . . . . . . . . . . . . . . . .
MySQL Konfiguration: Zugriffe über das Netzwerk erlauben . . . . . . . . . .
MySQL Server neustarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MySQL Konfiguration: Passwort für den administrativen Account (root) setzten
Apache2 und PHP5 installieren . . . . . . . . . . . . . . . . . . . . . . . . . .
Apache2: Standardmäßigen VirtualHost deaktivieren . . . . . . . . . . . . . .
Apache2: VirtualHost konfigurieren . . . . . . . . . . . . . . . . . . . . . . . .
Apache2: VirtualHost Konfiguration . . . . . . . . . . . . . . . . . . . . . . . .
Apache2: PHP5 aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Apache2: Konfigurationsdateien neu einlesen . . . . . . . . . . . . . . . . . . .
Subversion installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subversion Konfiguration: Ordnerstruktur anlegen . . . . . . . . . . . . . . . .
Subversion Konfiguration: Konfigurationsdateien anlegen . . . . . . . . . . . .
Subversion Konfiguration: Benuter-/Passworteintrag generieren . . . . . . . . .
Subversion Konfiguration: Benutzer-/Passworteintrag anlegen . . . . . . . . .
Subversion Konfiguration: passwd“ Datei . . . . . . . . . . . . . . . . . . . .
”
Subversion Konfiguration: users-access-file“ Datei . . . . . . . . . . . . . . . .
”
Subversion Konfiguration: Repository anlegen . . . . . . . . . . . . . . . . . .
Subversion Konfiguration: Modulkonfiguration für Apache2 . . . . . . . . . . .
Subversion Konfiguration: Apache2 Modul aktivieren . . . . . . . . . . . . . .
Apache2 Konfiguration neu einlesen . . . . . . . . . . . . . . . . . . . . . . . .
Shell Skript für die Syncronisation . . . . . . . . . . . . . . . . . . . . . . . . .
SSH Konfiguration: RSA Schlüsselpaar generieren . . . . . . . . . . . . . . . .
SSH Konfiguration: Ordnerauflistung .ssh/“ . . . . . . . . . . . . . . . . . . .
”
SSH Konfiguration: authorized keys“ Datei . . . . . . . . . . . . . . . . . . .
”
SSH Konfiguration: Publi-Key Authentifizierung aktivieren . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
46
47
58
59
59
60
60
61
61
61
62
63
63
63
64
64
65
65
65
65
66
66
66
67
67
68
68
82
84
84
85
85
Seite 223von 231
ALFSA
LISTINGS
4.31
4.32
4.33
4.34
4.35
4.36
4.37
4.38
4.39
4.40
4.41
4.42
4.43
4.44
4.45
4.46
4.47
4.48
4.49
4.50
4.51
4.52
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
9.15
9.16
9.17
9.18
SSH Server neustarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
SSH Testverbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
SSH Konfiguration: Portweiterleitung aktivieren . . . . . . . . . . . . . . . . . 86
SSH Server neustarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
SSH Porttunnel aufbauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
SSH Porttunnel testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Funktion zum Erstellen eines Porttunnels . . . . . . . . . . . . . . . . . . . . . 88
Funktion zum Erstellen des RSA Schüsselpaares . . . . . . . . . . . . . . . . . 89
Funktion für die Fehlerhandhabung bei der Syncronisation . . . . . . . . . . . 90
PHP Codeteil zum herausfinden ob ein Port frei ist . . . . . . . . . . . . . . . 92
Funktion zum Auslesen der Primärschlüssel einer Tabelle . . . . . . . . . . . . 92
Funktion zum Auslesen der neuen Datensätze . . . . . . . . . . . . . . . . . . 93
Funktion zum Synchronisieren der Tabellen . . . . . . . . . . . . . . . . . . . . 94
PHP Funktion zum Senden von Daten an der Server und Empfangen von Daten103
Beispiel für einen Verbindungschlüssel . . . . . . . . . . . . . . . . . . . . . . . 106
PHP Code zur Erstellung der Checksumme mit Verbindungschlüssel . . . . . . 106
PHP Code zur Prüfung der Checksumme mit Verbindungschlüssel . . . . . . . 106
PHP Code zur Übertragung des User-Agent . . . . . . . . . . . . . . . . . . . 107
PHP Code zur Prüfung des User-Agent . . . . . . . . . . . . . . . . . . . . . . 107
Grundlegende Verwendung - PHP-Datei . . . . . . . . . . . . . . . . . . . . . 112
Grundlegende Verwendung - Template-Datei . . . . . . . . . . . . . . . . . . . 112
Grundlegende Verwendung - HTML-Ergebnis . . . . . . . . . . . . . . . . . . 113
function add new sync vorgang . . . . . . . . . . . . . . . . . . . . . . . . . . 161
function close sync vorgang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
function error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
function get db summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
function get rand server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
function get server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
function get servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
function get server page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
function get tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
function get this sync vorgang . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
function lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
function locked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
function my mysql exceute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
function print reload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
function read end date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
function read phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
function unlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
function write end date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Brandstätter Andreas, Klaffl Christoph
Seite 224von 231
ALFSA
9.19
9.20
9.21
9.22
9.23
9.24
9.25
9.26
9.27
9.28
9.29
9.30
9.31
9.32
9.33
9.34
9.35
9.36
9.37
9.38
9.39
9.40
9.41
9.42
9.43
9.44
9.45
9.46
9.47
9.48
9.49
9.50
9.51
9.52
9.53
9.54
9.55
9.56
9.57
9.58
LISTINGS
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
write phase . . . . . . . . . . . .
add client . . . . . . . . . . . . .
change client . . . . . . . . . . .
get clients . . . . . . . . . . . . .
get client details . . . . . . . . . .
get next laufnummer . . . . . . .
add compressor . . . . . . . . . .
change compressor . . . . . . . .
del compressor . . . . . . . . . .
get compressors . . . . . . . . . .
get compressor details . . . . . .
get next compressor laufnummer
del cronjob . . . . . . . . . . . . .
new cronjob . . . . . . . . . . . .
read crontab . . . . . . . . . . . .
write crontab . . . . . . . . . . .
add fuellstelle . . . . . . . . . . .
change fuellstelle . . . . . . . . .
get fuellstellen . . . . . . . . . . .
add fw . . . . . . . . . . . . . . .
change fw . . . . . . . . . . . . .
get feuerwehren . . . . . . . . . .
append to log . . . . . . . . . . .
array insert . . . . . . . . . . . .
check config . . . . . . . . . . . .
check form data . . . . . . . . . .
contains only letters . . . . . . .
convert spaces to one space . . .
error . . . . . . . . . . . . . . . .
format data type . . . . . . . . .
get abschnitte . . . . . . . . . . .
get bezirke . . . . . . . . . . . . .
get current dir . . . . . . . . . . .
get homedir . . . . . . . . . . . .
get svn revision . . . . . . . . . .
is ip . . . . . . . . . . . . . . . .
is port . . . . . . . . . . . . . . .
remove cr lf . . . . . . . . . . . .
ping . . . . . . . . . . . . . . . .
test mysql . . . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
164
164
165
165
165
166
166
166
167
167
168
168
168
168
169
169
169
169
169
170
170
171
171
171
171
172
172
172
172
172
173
173
173
173
174
174
174
174
174
175
Seite 225von 231
ALFSA
9.59
9.60
9.61
9.62
9.63
9.64
9.65
9.66
9.67
9.68
9.69
9.70
9.71
9.72
9.73
9.74
9.75
9.76
9.77
9.78
9.79
9.80
9.81
9.82
9.83
9.84
9.85
9.86
9.87
9.88
9.89
9.90
9.91
9.92
9.93
9.94
9.95
9.96
9.97
9.98
LISTINGS
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
function
test ssh . . . . . . . . . . . . .
check permissions . . . . . . .
is assoc . . . . . . . . . . . . .
update config . . . . . . . . .
add authorized key . . . . . .
add known host . . . . . . . .
add server . . . . . . . . . . .
check authorized key . . . . .
check known host . . . . . . .
create rsa key . . . . . . . . .
create tunnel . . . . . . . . .
del authorized key . . . . . .
del server . . . . . . . . . . .
get rsa key . . . . . . . . . . .
get server . . . . . . . . . . .
read authorized keys . . . . .
read known hosts . . . . . . .
setup authorized keys . . . . .
update server . . . . . . . . .
update server config . . . . .
calc level . . . . . . . . . . . .
check if inkonsistent . . . . .
check if table exists . . . . . .
check lock file . . . . . . . . .
clean up . . . . . . . . . . . .
create table . . . . . . . . . .
create table extended . . . . .
del lock file . . . . . . . . . .
del sync . . . . . . . . . . . .
first sync . . . . . . . . . . . .
format string for html console
get all tables . . . . . . . . . .
get new data . . . . . . . . .
get primary keys . . . . . . .
get table levels . . . . . . . .
get table structure . . . . . .
get temporary sync tables . .
output . . . . . . . . . . . . .
read sync date . . . . . . . . .
set fk off . . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
175
175
175
175
176
176
176
177
177
177
177
178
178
178
178
179
179
179
179
179
180
180
180
180
181
181
181
181
182
182
182
182
182
183
183
183
183
184
184
184
Seite 226von 231
ALFSA
9.99 function
9.100function
9.101function
9.102function
9.103function
9.104function
9.105function
9.106function
9.107function
9.108function
9.109function
9.110function
9.111function
9.112function
9.113function
9.114function
9.115function
9.116function
9.117function
9.118function
9.119function
9.120function
9.121function
9.122function
9.123function
9.124function
9.125function
9.126function
9.127function
9.128function
9.129function
9.130function
9.131function
9.132function
9.133function
9.134function
9.135function
9.136function
9.137function
9.138function
LISTINGS
set fk on . . . . . . . . . .
set lock file . . . . . . . .
sort tables after levels . .
sync error . . . . . . . . .
sync table . . . . . . . . .
update sync date . . . . .
update table levels . . . .
update table structure . .
get cpuclock . . . . . . . .
get cpupercent . . . . . . .
get date . . . . . . . . . .
get diskspace . . . . . . .
get distri . . . . . . . . . .
get ip . . . . . . . . . . . .
get netstats . . . . . . . .
get ram . . . . . . . . . .
get server status . . . . . .
get swap . . . . . . . . . .
get temperature . . . . . .
get uptime . . . . . . . . .
add user . . . . . . . . . .
change user . . . . . . . .
check cookie passwd hash
del user . . . . . . . . . .
get alias for permission . .
get available areas . . . .
get available permissions .
get dienstgrade . . . . . .
get fwnr and stbnr . . . .
get permissions . . . . . .
get username . . . . . . .
get users . . . . . . . . . .
get user details . . . . . .
isloggedon . . . . . . . . .
is admin . . . . . . . . . .
login . . . . . . . . . . . .
logout . . . . . . . . . . .
set permissions . . . . . .
new draw table . . . . . .
append to log . . . . . . .
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
184
184
185
185
185
186
186
186
186
186
187
187
187
187
187
188
188
188
188
188
188
189
189
190
190
190
190
190
191
191
191
191
191
192
192
192
192
193
193
193
Seite 227von 231
ALFSA
9.139function error . . . . . . . . . . . . . .
9.140function get filename of cache file . . .
9.141function get primary keys . . . . . . .
9.142function get referenced tables . . . . .
9.143function get referenced tables recursive
9.144function get right client . . . . . . . .
9.145function get tables . . . . . . . . . . .
9.146function my extract . . . . . . . . . . .
9.147function read cache data . . . . . . . .
9.148function write cache data . . . . . . . .
9.149constructor function Template . . . . .
9.150function display . . . . . . . . . . . . .
9.151function get html . . . . . . . . . . . .
9.152function process . . . . . . . . . . . . .
9.153function read diff page . . . . . . . . .
9.154function set . . . . . . . . . . . . . . .
9.155function set html . . . . . . . . . . . .
Brandstätter Andreas, Klaffl Christoph
LISTINGS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
193
194
194
194
194
194
195
195
195
195
196
196
196
196
196
197
197
Seite 228von 231
ALFSA
TABELLENVERZEICHNIS
Tabellenverzeichnis
1.1
1.2
1.3
Zeitplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitskalender von Brandstätter Andreas . . . . . . . . . . . . . . . . . . . .
Arbeitskalender von Klaffl Christoph . . . . . . . . . . . . . . . . . . . . . . .
10
13
15
4.1
Unixzeit-Darstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
6.1
6.2
6.3
6.4
Hardware . . . . .
Miete und Diverses
Arbeitszeit . . . . .
Fixkosten . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Brandstätter Andreas, Klaffl Christoph
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
120
121
121
121
Seite 229von 231
ALFSA
LITERATURVERZEICHNIS
Literaturverzeichnis
[1] Netcraft. Online im Internet: http://news.netcraft.com/archives/web server survey.html,
2008-05-08
[2] Subversion. Online im Internet:
http://www.sable.mcgill.ca/∼hendren/303/Slides/Subversion/subversion.html,
2008-05-08
[3] Computer Language Benchmarks Game. Online im Internet:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=php,
2008-05-08
[4] PHP Handbuch. Online im Internet: http://at.php.net/manual/de/intro.curl.php,
2008-05-08
[5] NTP Pool project. Online im Internet: http://www.pool.ntp.org/zone/europe,
2008-05-08
[6] Wikipedia - General Public License. Online im Internet:
http://de.wikipedia.org/wiki/Gpl, 2008-05-10
[7] Online im Internet: http://mitschang.net/download/IESE-Report%2058.pdf, 2008-05-08
[8] Online im Internet: http://www.patentstorm.us/patents/6957432-description.html,
2008-05-08
[9] Online im Internet: http://www.golem.de/0804/59322.html, 2008-05-08
[10] Interschutz. Online im Internet: http://www.interschutz.de/, 2008-05-11
[11] Retter. Online im Internet: http://www.rettermesse.at/, 2008-05-11
[12] wax.at. Online im Internet:
http://www.wax.at/modules.php?name=News&file=article&sid=6098, 2008-05-11
[13] Bohmann. Online im Internet: http://www.bohmann.at/templates/index.cfm/id/2906,
2008-05-11
[14] wax.at. Online im Internet: http://www.wax.at/, 2008-05-11
Brandstätter Andreas, Klaffl Christoph
Seite 230von 231
ALFSA
LITERATURVERZEICHNIS
[15] fireworld.at. Online im Internet: http://www.fireworld.at, 2008-05-11
[16] Tometa Software. Online im Internet:
http://www.tometasoftware.com/MySQL-5-vs-Microsoft-SQL-Server-2005.asp,
2008-05-12
[17] Tometa Software. Online im Internet:
http://www.tometasoftware.com/MySQL-vs-PostgreSQL.asp, 2008-05-12
[18] MySQL Development. http://dev.mysql.com/doc/refman/5.1/de/multi-computer.html,
2008-05-13
[19] MySQL Development.
http://dev.mysql.com/doc/refman/5.1/de/mysql-cluster-limitations.html, 2008-05-13
[20] PHP Funktionsreferenz. Online im Internet:
http://at2.php.net/mysql real escape string, 2008-05-13
[21] xkcd. Online im Internet: http://xkcd.com/327/?gao, 2008-05-13
[22] Wikipedia - fork. Online im Internet: http://de.wikipedia.org/wiki/Fork, 2008-05-13
[23] Wikipedia - POSIX. Online im Internet: http://de.wikipedia.org/wiki/POSIX,
2008-05-13
[24] Elektronik-Kompendium - OSI-7-Schichten-Modell. Online im Internet:
http://www.elektronik-kompendium.de/sites/kom/0301201.htm, 2008-05-13
[25] Winquadrat - Microsoft SQL Server. Online im Internet:
http://www.winquadrat.de/index.php?mssql, 2008-05-13
[26] Elektronik-Kompendium - Load Balancer. Online im Internet:
http://www.elektronik-kompendium.de/sites/net/0904131.htm, 2008-05-13
Brandstätter Andreas, Klaffl Christoph
Seite 231von 231