Diplomarbeit ALFSA Atemluftfüllstellenapplikation

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit ALFSA Atemluftfüllstellenapplikation"

Transkript

1 Diplomarbeit ALFSA Atemluftfüllstellenapplikation 16. Mai 2008

2 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

3 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 Andreas Brandstätter Christoph Klaffl Brandstätter Andreas, Klaffl Christoph Seite i

4 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

5 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

6 INHALTSVERZEICHNIS Inhaltsverzeichnis Vorwort Eidesstattliche Erklärung Kurzfassung Abstract i i ii iii Inhaltsverzeichnis 1 I Projektmanagement 8 1 Projektmanagement Spezifikation Zeitplan Strukturplan Arbeitskalender Brandstätter Andreas Klaffl Christoph Diplomarbeitsbesprechungen Erste Diplomarbeitsbesprechung Zweite Diplomarbeitsbesprechung Dritte Diplomarbeitsbesprechung Vierte Diplomarbeitsbesprechung Fünfte Diplomarbeitsbesprechung Sechste Diplomarbeitsbesprechung Besprechungsnotizen Erste Besprechungsnotiz Zweite Besprechungsnotiz Kontakte Entwicklerteam Betreuer Auftraggeber Brandstätter Andreas, Klaffl Christoph Seite 1von 231

7 INHALTSVERZEICHNIS II Projektentwicklung 26 2 Verwendete Technologien SSH Allgemeines Verwendung Sicherheit Implementierungen APACHE Webserver Allgemeines Aufbau Implementierungen Homepage Datenbanksystem Allgemeines Anforderungen Wartung MySQL Allgemeines Aufbau Administration Implemetierung Linux Allgemeines Was ist Linux? Weitere Entwicklung Verbreitung Distribution Subversion Allgemeines Funktionsweise Implemetierung SSL Allgemeines Funktionsweise Verschlüsselungsverfahren Vorteile Nachteile Probleme Implementierungen PHP Allgemeines Funktionsweise Syntax Implementierung JAVA Brandstätter Andreas, Klaffl Christoph Seite 2von 231

8 INHALTSVERZEICHNIS Allgemeines Funktionsweise Syntax Implementierung Analysen und Entscheidungen Betriebssysteme Debian Etch (LINUX) Microsoft Windows Server Entscheidung Datenbank Server MySQL [16] [17] PostgreSQL [17] Microsoft SQL Server 2005 [16] Entscheidung Replikation vs. Cluster [19] [18] Cluster allgemein Active-Passive-Cluster Active-Active-Cluster Replikation allgemein Master-Slave Replikation Master-Master Replikation Entscheidung Planung und Implementierung Server aufsetzen Installationsmedium besorgen Installation Konfiguration SSH Server aufsetzen Installation Konfiguration Datenbankserver aufsetzten Installation Konfiguration Webserver aufsetzten Installation Konfiguration Subversion-Server aufsetzten Installation Konfiguration Zeitspeicherung Zeitumstellungsproblem Lösungsansatz Unixzeit Einschränkungen Brandstätter Andreas, Klaffl Christoph Seite 3von 231

9 INHALTSVERZEICHNIS Zeitsynchronität Datenbankdesign Primärschlüssel Spalte edit date Löschen von Daten Lineare Abhängigkeiten Grundlegende Struktur Atemluftflaschen Füllungen Datenbankstruktur Tabellen der Datenbank Datenbankzugriff Server - Server Syncronisation Anforderungen Konzept Syncronisationsrichtung Anpassungen der Datenbankstruktur Shell CRON SSH PHP Datenbankstruktur aktualisieren Backupserver Fehlerbehandlung Client - Server Syncronisation Vorgaben Konzept Prinzip Realisierung Umsetzung Sequenzdiagramm Fehlerbehandlung Webinterface Übersicht index.php Template Engine Tests Test des Webinterfaces Test der Server - Server Synchronisation Test der Client - Server Synchronisation Pre-Alpha Development-Test Verwendete Hilfsmittel Verwendete Software Allgemeine Quellen Brandstätter Andreas, Klaffl Christoph Seite 4von 231

10 INHALTSVERZEICHNIS III Wirtschaftlicher Teil Allgemeines Die Firma FRED Das Produkt ALFSA General Public Liecense GPL Kostenrechnung Kalkulation Kalkulation der Fixkosten Kalkulation der variablen Kosten Support Kalkulation der variablen Kosten Preiskalkulation Break-Even-Point Marketing Marktanalyse Primäre Zielgruppe Sekundäre Zielgruppe Konkurrenzanalyse Marketing Der Firmenname Das Firmenlogo Das Produktlogo Logos - Corporate Design Werbung Messen Feuer-Zeitschriften Feuer-Webseiten Taucher-Zeitschriften Promotionswebseite IV Handbuch Administratorhandbuch Willkommen Voraussetzungen Hardware Software Installation Programmdateien kopieren Rechte anpassen Einmalige Einstellungen Erster ALFSA Server Brandstätter Andreas, Klaffl Christoph Seite 5von 231

11 INHALTSVERZEICHNIS Konfiguration Fehlerbehandlung Bedienung Benutzerverwaltung Feuerwehrverwaltung Fuellstellenverwaltung Clientverwaltung Kompressorverwaltung Serverliste Serververwaltung Konfiguration Synchronisieren LOGViewer Tabellenansicht Fehlerhafte Eingabe V Anhang Anhang Funktionen und Klassen Teil Client-Server-Sync am Client Teil Server Teil Client-Server-Sync am Server Teil Mehrfach genutzt Tabellen Tabelle abschnitte Tabelle atemluftflaschen fuellung Tabelle atemluftflaschen maengel Tabelle atemluftflaschen Tabelle atemluftflaschen pruefung Tabelle atemschutzgeraete maengel Tabelle atemschutzgeraete Tabelle atemschutzgeraete pruefung Tabelle atemschutzgeraete wartung Tabelle atemschutzmasken maengel Tabelle atemschutzmasken Tabelle atemschutzmasken wartung Tabelle benutzer anmeldung Tabelle benutzer Tabelle benutzer schulung Tabelle bezirke Tabelle client Tabelle dienstgrade Tabelle einsatz Tabelle feuerwehren Brandstätter Andreas, Klaffl Christoph Seite 6von 231

12 INHALTSVERZEICHNIS Tabelle fremdflaschen fuellung Tabelle fremdflaschen Tabelle fuell sitzung Tabelle fuellstelle Tabelle geraetetraeger Tabelle geraetetraeger untersuchung Tabelle gruppen Tabelle gruppen user Tabelle kompressoren maengel Tabelle kompressoren Tabelle kompressoren pruefung Tabelle kompressoren wartung Tabelle nachrichten gelesen Tabelle nachrichten Tabelle permission Tabelle person kontakt Tabelle person Tabelle person telefon Tabelle schulung Tabelle server details Tabelle server Tabelle sync Tabelle sync server log Tabelle sync vorgang Tabelle verbindungskennung Dateiliste Verzeichnisse 220 Abbildungsverzeichnis 222 Listings 228 Tabellenverzeichnis 229 Literaturverzeichnis 230 Brandstätter Andreas, Klaffl Christoph Seite 7von 231

13 Teil I Projektmanagement Brandstätter Andreas, Klaffl Christoph Seite 8von 231

14 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

15 KAPITEL 1. PROJEKTMANAGEMENT 1.2 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

16 KAPITEL 1. PROJEKTMANAGEMENT 1.3 Strukturplan Abbildung 1.2: Strukturplan Brandstätter Andreas, Klaffl Christoph Seite 11von 231

17 KAPITEL 1. PROJEKTMANAGEMENT 1.4 Arbeitskalender Brandstätter Andreas KW Stunden Tätigkeit Formulierung der Aufgabenstellung Einarbeitung in das Thema Besprechung mit Johannes Ofner und Christian Brandstätter Einarbeitung in das Thema Datenbanksychronisation Client-Server konzeptioniert Datenbanksychronisation Client-Server grundlegend ausgeführt Diplomarbeitsantrag fertiggestellt und abgegeben Datenbanksycronisation Client-Server Datenbank-Verbindung auf UTF-8 umgestellt (für Umlaute) Grundlegende Systemänderungen Diplomarbeitsbesprechung Kooperationsvereinbarung eingeholt 43 7 Arbeitszeitkalender Template-Engine Installation der Software auf Server euklid Logo entworfen und gezeichnet Deckblatt entworfen Zeitumstellungsploblem analysiert Zeitumstellungsploblem dokumentiert Installation der Software dokumentiert 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

18 KAPITEL 1. PROJEKTMANAGEMENT 2 7 Oberfläche der Synchronisation von Client-Server Client-Server Synchronisation: Diverse Inhalte 3 9 Client-Server Synchronisation: verschiedene Server verwenden Client-Server Synchronisation: Server zufällig auswählen grafische Darstellung von Tabellen 5 21 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 6 10 neue Client-Server-Synchronisation (komplett neu aufgebaut, mit foreign-keys) 7 12 Client für Server-Interface (Zentraldatenbank) adaptiert Client-Server-Synchronisation verbessert CMS für Promotionswebseite: Auswahl und Konfiguration CMS: Konfiguration 8 7 Server-Client Synchronisation um Sicherheitsfunktionen erweitert 9 6 Client-Server Synchronisation an neue Tabellennamen angepasst, und div. Maskottchen gezeichnet / entworfen Beschreibung für HTL-innovativ 10 5 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 270 Gesamt Tabelle 1.2: Arbeitskalender von Brandstätter Andreas Brandstätter Andreas, Klaffl Christoph Seite 13von 231

19 KAPITEL 1. PROJEKTMANAGEMENT Klaffl Christoph KW Stunden Tätigkeit Formulierung der Aufgabenstellung Gegenüberstellung der Betriebssysteme Softwareanforderungen der Auftraggeber studieren und überdenken 38 7 Gegenüberstellung der Datenbanksysteme Gegenüberstellung der Möglichkeiten für das redundante Datenbanksystem 39 8 Web-Interface Grundstruktur Diplomarbeitsantrag fertiggestellt und abgegeben Web-Interface entworfen Analysieren der bestehenden Datenbank des Auftraggebers Datenbankstruktur neu erstellen Diplomarbeitsbesprechung Kooperationsvereinbarung eingeholt 42 5 Eintragung aller Feuerwehren, Bezirke und Abschnitte von NÖ in die Datenbank 44 9 Server Server Synchronisation: Konzept erstellt SSH Einarbeitung Public-Key Authentifizierungsverfahren Konfigurationslibarys erstellt Web-Interface Konfigurationsseite für die Syncronisation 47 9 SSL Einarbeitung Library für die Erstellung und Vewaltung der Public Keys 48 7 CRON Einarbeitung Server Server Synchronisation allgemein implementiert Server Server Synchronisation in PHP implementiert Server Server Synchronisation in JAVA implementiert 51 9 Testen und Vergleichen der Server Server Synchronisation in PHP und JAVA Library für die Verwaltung von Cronjobs Überarbeitung der Server Server Synchronisation Logging für dir Server Server Synchronisation Web-Interface Benutzerverwaltung Web-Interface Server Liste 1 Einführung L A TEX Gegenüberstellung in L A TEXdokumentiert 2 6 Web-Interface Füllstellenverwaltung Optimierungen der Libaries 4 5.htaccess Dateien erstellt Cron Library - Intervalleinstellung Brandstätter Andreas, Klaffl Christoph Seite 14von 231

20 KAPITEL 1. PROJEKTMANAGEMENT 5 8 Beziehungen erstellt Server-Server Syncronisierung: Einteilung der Tabellen nach ihren Beziehungsebenen (FK) Entwicklungsseite überarbeitet 6 9 Fehlerkorrekturen durchgeführt Log Viewer programmiert 7 11 Login Maske erstellt Inkompatibilitäten zu IE behoben Server Verwaltung wurde komplett neu geschrieben Design Änderungen 8 4 Cookie Funktion ( Remember Me ) 9 8 Web-Interface Benutzerverwaltung überarbeitet Client-Server-Synchronisation verbessert Abstract und Zusammenfassung Server - Server Synronisation: Fehlerbereinigung Server Verwaltung wurde komplett neu geschrieben Log Viewer wurde überarbeitet Web-Interface Client Verwaltung 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) vertiefte Analyse von verteilten Datenbanken Aufbau und Test eines MySQL-Clusters 16 7 Letzten Fehler behoben Programmcode verbessert und unötigen Code entfernt Dokumentation abschließende Dokumentation abschließende Dokumentation 264 Gesamt Tabelle 1.3: Arbeitskalender von Klaffl Christoph Brandstätter Andreas, Klaffl Christoph Seite 15von 231

21 KAPITEL 1. PROJEKTMANAGEMENT 1.5 Diplomarbeitsbesprechungen 1. Diplomarbeitsbesprechung 2007/08 ALFSA Termin :50 Ort 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: Brandstätter Andreas, Klaffl Christoph Seite 16von 231

22 KAPITEL 1. PROJEKTMANAGEMENT 2. Diplomarbeitsbesprechung 2007/08 ALFSA Termin :10 Ort 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: Brandstätter Andreas, Klaffl Christoph Seite 17von 231

23 KAPITEL 1. PROJEKTMANAGEMENT 3. Diplomarbeitsbesprechung 2007/08 ALFSA Termin :10 Ort 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: Brandstätter Andreas, Klaffl Christoph Seite 18von 231

24 KAPITEL 1. PROJEKTMANAGEMENT 4. Diplomarbeitsbesprechung 2007/08 ALFSA Termin :10 Ort 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: Brandstätter Andreas, Klaffl Christoph Seite 19von 231

25 KAPITEL 1. PROJEKTMANAGEMENT 5. Diplomarbeitsbesprechung 2007/08 ALFSA Termin :10 Ort 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: Brandstätter Andreas, Klaffl Christoph Seite 20von 231

26 KAPITEL 1. PROJEKTMANAGEMENT 6. Diplomarbeitsbesprechung 2007/08 ALFSA Termin :10 Ort 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

27 KAPITEL 1. PROJEKTMANAGEMENT 1.6 Besprechungsnotizen 1. Besprechungsnotiz ALFSA Termin von 15:30 bis 17:15 Ort 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

28 KAPITEL 1. PROJEKTMANAGEMENT 2. Besprechungsnotiz ALFSA Termin von 13:00 bis 14:45 Ort 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

29 KAPITEL 1. PROJEKTMANAGEMENT 1.7 Kontakte Bei Support- oder sonstigen Anfragen wenden Sie sich bitte an folgende Personen: Entwicklerteam Andreas Brandstätter Gerersdorferstraße Sieghartskirchen +43 (664) Christoph Klaffl Birkenweg Langenlois +43 (664) Weiters sind die Entwickler unter erreichbar Betreuer Prof. Dipl. Ing. Wolfgang Alfery Waldstrasse St.Pölten +43 (2742) Prof. Dipl. Ing. Gerd Riesenhuber Waldstrasse St.Pölten +43 (2742) Brandstätter Andreas, Klaffl Christoph Seite 24von 231

30 KAPITEL 1. PROJEKTMANAGEMENT Auftraggeber Abbildung 1.3: Korpsabzeichen der Feuerwehren in Österreich Bezirksfeuerwehrkommando Tulln Hauptstrasse Tulbing +43 (2272) Kontaktperson: Johannes Offner Jakob Schefzikgasse 37/3/ Tulln an der Donau +43 (664) Brandstätter Andreas, Klaffl Christoph Seite 25von 231

31 Teil II Projektentwicklung Brandstätter Andreas, Klaffl Christoph Seite 26von 231

32 KAPITEL 2. VERWENDETE TECHNOLOGIEN Kapitel 2 Verwendete Technologien 2.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: 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

33 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 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

34 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 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 Windows- Shell 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 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 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

35 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 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 trägt Homepage Weitere Informationen können über die Hautptseite des Apache HTTP Servers bezogen werden: 2.3 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

36 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 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

37 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) Wartung Die Wartung wird von Datenbank-Administratoren (DBA) übernommen und wird vollständig über die Verwendung der bereitgestellten Datenbanksprache ausgeführt. 2.4 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

38 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 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 Anfoderungen 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 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 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 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

39 KAPITEL 2. VERWENDETE TECHNOLOGIEN 2.5 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] Was ist Linux? Mit dem Begriff Linux bezeichnet man den Kernel. Er ist der wichtigste Bestandteil eines 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 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

40 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 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

41 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 Distribution Linux wird über die Webseite vertrieben. Es stehen dort sowohl die neuen 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 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 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

42 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

43 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

44 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 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

45 KAPITEL 2. VERWENDETE TECHNOLOGIEN 2.7 SSL 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 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 denen 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

46 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

47 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 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

48 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 öffentlichen 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 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 s 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 s, 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

49 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 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 behoben 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 GNO- ME, 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

50 KAPITEL 2. VERWENDETE TECHNOLOGIEN 2.8 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) 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

51 KAPITEL 2. VERWENDETE TECHNOLOGIEN Abbildung 2.5: PHP Funktionsprinzip Syntax Ein einfaches Hallo Welt -Beispiel sieht folgendermaßen aus: 1 <?php 2 echo "Hallo Welt!"; 3?> Listing 2.1: PHP Syntaxbeispiel 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 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

52 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] 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 Syntax Ein einfaches Hallo Welt -Beispiel sieht so aus: 1 public class HalloWelt { 2 public static void main(string[] args) { 3 System.out.println("Hallo Welt!"); 4 } 5 } 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

53 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

54 KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN Kapitel 3 Analysen und Entscheidungen 3.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

55 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) 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 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

56 KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN 3.2 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 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

57 KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN Contra Kein direkter Support (Support kann von anderen Firmen gekauft werden) 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 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

58 KAPITEL 3. ANALYSEN UND ENTSCHEIDUNGEN 3.3 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-of- Failure (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) 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

59 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) 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 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

60 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 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

61 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

62 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 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 BitTorrent 1 System steht zur Auswahl. Einige Seiten, über die das Installationsmedium bezogen werden kann, sind: Filesharing Protokoll für die schnelle Verteilung von großen Datemengen Brandstätter Andreas, Klaffl Christoph Seite 57von 231

63 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 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 $ apt-get update Brandstätter Andreas, Klaffl Christoph Seite 58von 231

64 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 2...AUSGABE... 3 $ apt-get upgrade 4...AUSGABE... Listing 4.1: Systemaktualisierung 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 Installation Die Installation gestaltet sich nach dem Debian Prinzip sehr einfach und es reicht folgender Befehl, der im Terminal ausgeführt wird: 1 $ apt-get install openssh-server 2...AUSGABE... Listing 4.2: SSH Server installieren 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: # Authentication: 3 LoginGraceTime PermitRootLogin no <<=== Brandstätter Andreas, Klaffl Christoph Seite 59von 231

65 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 5 StrictModes yes 6 7 RSAAuthentication yes 8 PubkeyAuthentication yes 9... Listing 4.3: SSH Konfiguration: Root Login verbieten Danach wird der SSH Server über das Init Script /etc/init.d/ssh neugestartet: 1 $ /etc/init.d/ssh restart 2 * 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 Installation Um den MySQL Server zu installieren genügt folgender Befehl: 1 $ apt-get install mysql-server 2...AUSGABE... Listing 4.5: MySQL Datenbankserver installieren Zusätzlich zum MySQL Server wird auch der Kommandozeilen Client mysqlclient automatisch installiert. Die Administration wird durch dieses Tool durchgeführt. Brandstätter Andreas, Klaffl Christoph Seite 60von 231

66 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 skip-external-locking 2 # 3 # Instead of skip-networking the default is now to listen only on 4 # localhost which is more compatible and is not less secure. 5 #bind-address = <<== 6 # 7 # * Fine Tuning 8 # 9 key_buffer = 16M 10 max_allowed_packet = 16M 11 thread_stack = 128K 12 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 $ /etc/init.d/mysql restart 2 * Stopping MySQL database server mysqld [ OK ] 3 * Starting MySQL database server mysqld [ OK ] 4 * 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 mysql --user=root 2 Welcome to the MySQL monitor. Commands end with ; or \g. Brandstätter Andreas, Klaffl Christoph Seite 61von 231

67 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 3 Your MySQL connection id is 7 4 Server version: Debian_1ubuntu3.1-log Debian etch distribution 5 6 Type help; or \h for help. Type \c to clear the buffer. 7 8 mysql> update mysql.user set Password=PASSWORD( <das neue Passwort kommt hier hin> ) where User= root ;Query OK, 1 row affected (0.00 sec) 9 Rows matched: 1 Changed: 1 Warnings: mysql> flush privileges; 12 Query OK, 0 rows affected (0.00 sec) mysql> quit 15 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) Installation Um den Apache2 Webserver zu installieren genügt folgender Befehl: 1 $ apt-get install apache2 libapache2-mod-php5 php5- cli php5-common 2...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

68 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 $ a2dissite default 2 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 $ vim /etc/apache2/sites-available/alfsa_ssl Listing 4.11: Apache2: VirtualHost konfigurieren Die Konfigurationsdatei sieht wie folgt aus: 1 <VirtualHost *:443> 2 3 # General setup for the virtual host 4 DocumentRoot "/home/alfsa/server-www/" 5 ServerName ffsieg.dyndns.org:443 6 ServerAdmin 7 8 # Logfiles: 9 CustomLog /var/log/apache2/access-alfsa_ssl combined 10 ErrorLog /var/log/apache2/error-alfsa_ssl 11 # Possible values include: debug, info, notice, warn, error, crit, 12 # alert, emerg. 13 LogLevel notice # SSL 16 SSLEngine On 17 SSLCipherSuite HIGH:MEDIUM 18 SSLCertificateFile /etc/apache2/ssl/alfsa_ssl.ffsieg.dyndns. org.crt 19 SSLCertificateKeyFile /etc/apache2/ssl/alfsa_ssl.ffsieg.dyndns. org.key 20 Brandstätter Andreas, Klaffl Christoph Seite 63von 231

69 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 21 </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 $ a2enmod php5 2 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 $ /etc/init.d/apache2 force-reload 2 * 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 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

70 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 $ apt-get install subversion libapache2-svn 2...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, Konfiguration Als erster Schritt werden die Verzeichnisse für Subversion eingerichtet: 1 $ mkdir /home/svn 2 $ mkdir /home/svn/conf 3 $ mkdir /home/svn/repositories Listing 4.16: Subversion Konfiguration: Ordnerstruktur anlegen Als nächstes wird die Konfiguration für die Subversion Benutzer angelegt: 1 $ touch /home/svn/conf/passwd 2 $ 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 $ htpasswd -n christoph Brandstätter Andreas, Klaffl Christoph Seite 65von 231

71 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 2 New password: 3 Re-type new password: 4 christoph:/xs182hqpismk Listing 4.18: Subversion Konfiguration: Benuter-/Passworteintrag generieren Die letzte Ausgabezeile ist die Zeile, die in die passwd geschrieben wird. Der Übergabeparameter 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 geschrieben werden: 1 $ htpasswd /home/svn/conf/passwd christoph 2 New password: 3 Re-type new password: 4 Adding password for user christoph Listing 4.19: Subversion Konfiguration: Benutzer-/Passworteintrag anlegen Die fertige Konfigurationsdatei passwd sieht dann folgendermaßen aus: 1 christoph:58//0wxlrzyzu 2 silicium:uoqpqz4qfoqms 3 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 [alfsa:/] 4 christoph = rw 5 silicium = rw 6 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

72 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 $ 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 # dav_svn.conf - Subversion/Apache configuration 2 <Location /svn> 3 4 Order allow,deny 5 Allow from all 6 # Uncomment this to enable the repository, 7 DAV svn 8 9 # Set this to the path to your repositories 10 SVNParentPath /home/svn/repositories/ SSLRequireSSL # Uncomment the following line to enable Authz Authentication 15 AuthzSVNAccessFile /home/svn/conf/users-access-file #try anonymous access first, resort to real 18 #authentication if necessary. 19 Satisfy Any 20 Require valid-user # The following allows for basic http authentication. Basic authentication 23 # should not be considered secure for any particularly rigorous definition of 24 # secure # how to authenticate a user 27 AuthType Basic 28 AuthName "My Subversion repository" 29 AuthUserFile /home/svn/conf/passwd Brandstätter Andreas, Klaffl Christoph Seite 67von 231

73 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 $ a2enmod dav_svn 2 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 $ /etc/init.d/apache2 force-reload 2 * 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 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

74 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 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 Unixzeit Die Unixzeit ist ein Zeitstempel, der diese Bedingung erfüllt. Die Unixzeit zählt die vergangenen Sekunden seit dem :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(2- stellig):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 Ausgabe von date( Y-m-d H:i:s (T), Timestamp) :33:20 (CEST) :06:40 (CEST) :40:00 (CEST) :13:20 (CET) :46:40 (CET) :20:00 (CET) Tabelle 4.1: Unixzeit-Darstellungen Brandstätter Andreas, Klaffl Christoph Seite 69von 231

75 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 :00:00 (UTC) und :14:08 (UTC) verarbeitet werden kann. Die Unixzeit verwendet einen long- Datentyp, der auf den meisten Systemen mit 32 Bit definiert ist. Die Unixzeit zählt die vergangenen Sekunden seit dem und wird daher am den Wertebereich von 31 Bit überschreiten. Das 32te Bit wird zur Speicherung von negativen Zahlen verwendet. Daher springt die Zeit beim Überlauf auf den Diese Einschränkung des Zeitbereiches ist im Bereich vergangener Zeitpunkte (vor ) nicht relevant, da keine Daten mit Zeiten vor 1970 gespeichert werden müssen. Im Bereich zukünftiger Zeitpunkte (nach ) 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 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 :02:00 eingetragen. Die Flasche wird 5 Minuten später am Server B außer Dienst gestellt. Dieser Datensatz wird mit Datum :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

76 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 [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 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

77 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 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 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 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

78 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 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

79 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 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

80 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 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 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 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

81 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

82 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 Spalten 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

83 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG Aufruf: Erzeugter SQL Befehl: SELECT name,adresse,telefonnummer FROM benutzer WHERE name LIKE %hugo% Eine SQL Injection sieht bei diesem Beispiel folgendermaßen aus: Aufruf: +;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 UPDA- TE Query ausgeführt, welches alle Namen in der Datenbank auf hacked setzt. Diese unrechtmäßge Manipulation der Daten muss daher durch Maskierung jeglicher Benutzereingaben verhindert werden. 4.9 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, SE- LECT,...) 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 Konzept Für die Realisierung der Syncronisation wurden folgende Technologien/Programme verwendet: Brandstätter Andreas, Klaffl Christoph Seite 78von 231

84 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

85 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 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

86 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 dieser Spalte die aktuelle Unixzeit (siehe auch Kapitel 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

87 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 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 Kommandozeilenclient 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

88 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 CRON Das Erzeugen eines Eintrags für die Syncronisierung kann über folgenden Befehl erfolgen: 1 $ 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 Nachrichten durch Cron versandt. Brandstätter Andreas, Klaffl Christoph Seite 83von 231

89 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 $ 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 $ ls -l.ssh/ 2 -rw-r--r-- 1 www-data www-data :00 authorized_keys 3 -rw www-data www-data :03 id_rsa 4 -rw-r--r-- 1 www-data www-data :03 id_rsa.pub 5 -rw-r--r-- 1 www-data www-data :10 known_hosts 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

90 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 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuDr+4 s3ockz0tcurhjlpcxbqc5xqsn1h9v6vsybzdq4oqo05fub06tynm/6 ohinue3s6hvf53nkrg18huukb8tu4ha9fqydl6bw/phxlzjxatkgbhk/ jjjvhwswfel0atpqz0xosshkqnohl1jiil9rshmr7lrunb2wilxywzrublk/ fbcwadet7wikuck9foiotz4chy2wd/zcmujxqpapfsbrktm8vj368pgtr0z3u+ ThSaEx3zpQ1ortqFPjIzUmcHIkyTK560LJjUwG4Z1bbuMDqIy+AaTM3+ RIP1xLku/diTVXEYhB9AwFvX+pUaZc6k628q0kL/OvYPkd+oRQ== euklid- server 2 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuFoQMhCTiMWZZHmHyD9DlfDoq/ uiqdancnnfr6k2ztudtivor8yq6px7sp4rlrkb6b99uqvquemoblx/ mnresj8dbqp8uxcsjrrzukjch4n3eyd/salnkig2s2a/h7qxwx+ Li1cDCEy3hBJCLVdvff2j3fN5yItaMN7jyIjSgiYQb776iNO2rc/ qb8h8rpqypgrezl16jski6lzqpjgtnvsv7jwnjm/ UseJC11SmVUMeHugQ5klLNZ8VlHu9eCl+Jmw7/1vIqPJ9+0GCpBNy79h7/ SW36szgGFc5DYukbXDbrrDeVv725j0CTlfTTxDJeMQEYiQU/s6drFXfunM2kQ == debian-server 3 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: # Authentication: 3 LoginGraceTime PermitRootLogin no 5 StrictModes yes 6 7 RSAAuthentication yes <<=== 8 PubkeyAuthentication yes <<=== Brandstätter Andreas, Klaffl Christoph Seite 85von 231

91 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 9 #AuthorizedKeysFile %h/.ssh/authorized_keys # Don t read the user s /.rhosts and /.shosts files 12 IgnoreRhosts yes Listing 4.30: SSH Konfiguration: Publi-Key Authentifizierung aktivieren Um die getätigten Einstellungen zu übernehmen, wird der SSH Server neugestartet: 1 $ /etc/init.d/ssh restart 2 * 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 $ ssh trinity-server 2 No mail. 3 Last login: Mon May 5 19:40: from chief.tux.lan 4 $ 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 # GSSAPI options 2 #GSSAPIAuthentication no 3 #GSSAPICleanupCredentials yes 4 5 AllowTcpForwarding yes <<=== 6 X11Forwarding yes 7 X11DisplayOffset 10 8 X11UseLocalhost yes 9 PrintMotd no 10 PrintLastLog yes 11 TCPKeepAlive yes 12 #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

92 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 1 $ /etc/init.d/ssh restart 2 * 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 $ ssh trinity-server -L 3000:localhost : No mail. 3 Last login: Mon May 5 19:40: from chief.tux.lan 4 $ 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 überprüfen: 1 $ telnet localhost Trying Connected to localhost. 4 Escape character is ˆ]. 5 J Debian_1ubuntu3.3-logw->.iJt-,UoNv)c= Listing 4.36: SSH Porttunnel testen Brandstätter Andreas, Klaffl Christoph Seite 87von 231

93 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG Anhand der Ausgabe sieht man, dass sich der MySQL Server des entfernten Servers trinityserver 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 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

94 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 "/.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

95 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 Optionen 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"]); 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

96 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 26 $string=format_string_for_html_console($string); 27 if($argv) 28 { 29 $fp = fopen("php://stderr", w ); 30 flock($fp, LOCK_EX ); 31 fputs($fp, $string["console"]); 32 flock($fccp, LOCK_UN ); 33 fclose($fp); 34 }else 35 { 36 echo $string["html"]; 37 } 38 } if($die==true) 41 { 42 global $dbhandle; 43 if(clean_up($dbhandle)==true) 44 del_lock_file(inconsistent_lock_file); //Datenbankserver wieder als aktiv markieren append_to_log(sync_info_log,"synchronisation wegen eines Fehlers abgebrochen, siehe Sync Error Log"); 47 die(); 48 } 49 } 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

97 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 && $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 Portbereich, der für die Syncronisation verwendet werden darf, im Format <Startport>-<Endport> steht. Dieser Portbereich wird mittels der Funktion explode() in Start- und Endport aufgespalten 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 $retries kann festgestellt werden, dass der Vorgang nicht erfolgreich war (sie hat in diesem Fall den Wert 0). 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

98 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"]); 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

99 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ückgegebenen 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

100 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG if($count<count($temp)) 23 $sql.=, ; 24 else 25 $sql.= ; ; 26 } 27 $result=mysql_query($sql,$dbhandle); 28 if(mysql_errno($dbhandle)==1062) //1062: Duplicate Entry --> Daher muss statt ein INSERT Query eine UPDATE Query durchgefuehrt werden 29 { 30 $sql= UPDATE. mysql_real_escape_string($target_tablename ). SET ; 31 $count=0; 32 $where=""; 33 foreach($temp as $key=>$element) 34 { 35 $count++; 36 $tmp=0; foreach($primary as $pkey) 39 if($key==$pkey) 40 $tmp=1; if($key=="edit_date") 44 { 45 if($where!="") 46 $where.= AND ; 47 $where.= edit_date<". $element. " ; 48 } 49 if($tmp) 50 { 51 if($where!="") 52 $where.= AND ; 53 $where.=. $key. =". $element. " ; 54 }else 55 { if(is_null($element)) 58 $sql.=. $key. =NULL ; 59 else 60 $sql.=. $key. =". $element. " ; 61 if($count<count($temp)) 62 $sql.=, ; 63 else 64 $sql.= WHERE ; 65 } Brandstätter Andreas, Klaffl Christoph Seite 95von 231

101 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 66 } 67 $sql.= $where. ; ; 68 $result=mysql_query($sql,$dbhandle) or sync_error( LINE, FILE, $sql, mysql_error($dbhandle)); 69 }else 70 if(mysql_error($dbhandle)!="") 71 sync_error( LINE, FILE, $sql, mysql_error($dbhandle) ); 72 } 73 $limit_start+=max_new_data; 74 $new_data=get_new_data($source_tablename,$dbhandle2,$limit_start, MAX_NEW_DATA); 75 $count_all+=count($new_data); } return $count_all; //Hinzugefuegt/aktualisierte Datensaetze 80 } 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 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 durchgelaufen 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

102 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 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) 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

103 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 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 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

104 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 , 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

105 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 Client - Server Syncronisation 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 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 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

106 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 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 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

107 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

108 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 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 * Fragt eine Server-Seite ueber CURL ab. 3 * 4 array $post Daten, die per POST uebergeben werden. 5 int $phase Arbeitsschritt, der aktuell abgearbeitet wird. 6 string $server Servername, auf den die Anfrage ausgefuehrt wird. 7 array Inhalt der Seite und eventuell aufgetretene Fehler. 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

109 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 15 // Daten des Servers aus der Datenbank holen 16 $server = get_server($server); 17 echo "Verbunden mit Server: ".$server["name"]."(".$server[" hostname"].")<br />"; 18 flush(); 19 $server = $server["hostname"]; flush(); 22 // Die Session mit URL initialisieren 23 $ch = curl_init("https://".$server."/aaron/server-www/client-sync /"); // Session Optionen setzen // Wenn ein Proxy in Konfigurationsdatei vorhanden, Proxy setzen 28 if(proxy_string!= "") 29 curl_setopt($ch, CURLOPT_PROXY, PROXY_STRING); // Header nicht in die Ausgabe aufnehmen 32 curl_setopt($ch, CURLOPT_HEADER, 0); 33 // User-Agent-Feld (Browserkennung) im HTTP Header 34 curl_setopt($ch, CURLOPT_USERAGENT, "ALFSA sync agent"); 35 // gibt Transfer zurueck, anstatt Ausgabe vorzunehmen 36 curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); 37 // Peerueberpruefung von HTTPS setzen 38 curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); 39 // Hostueberpruefung von HTTPS setzen 40 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0); 41 // Timeout der Verbindung 42 curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10); // POST-Parameter setzen 45 $postvalues = ""; 46 // Datum der letzen vollstaendigen Synchronisation 47 $posts = array( "last_date" => read_end_date(), 48 // Datum der aktuellen Synchronisation 49 "this_date" => $this_sync_vorgang["start_date"], 50 // aktuelles Datum 51 "current_date" => time(), 52 // Feuerwehrnummer der Fuellstelle 53 "fwnr" => FUELLSTELLE, 54 // Laufnummer des Clients 55 "client" => CLIENT, 56 // aktuelle Phase (Arbeitsschritt) 57 "phase" => intval($phase), 58 // Pruefsumme der Daten und Verbindungskennung 59 "chksum" => md5($post["data"]." ".CONNECTION), 60 // Zufallsdaten um Caching zu vermeiden Brandstätter Andreas, Klaffl Christoph Seite 104von 231

110 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); // Ausfuehren der CURL-Aktion 72 $result = curl_exec($ch); // Ergebnis als globale Variable fuer Debugzwecken zur Verfuegung stellen 75 global $raw_result; 76 $raw_result = $result; // 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"]; if($error["error"]) 90 $this_error = $error["code"]; 91 echo $error["text"]."<br />"; 92 } // wenn Debug aktiviert ist, Ergebnis ausgebe 95 if(sync_debug) 96 echo "<pre>### html-rueckgabe ###\r\n".$result."\r\n</pre>"; // 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 />"; $codes.= "[=curl]"; 105 $this_error = "[=curl]"; 106 } 107 Brandstätter Andreas, Klaffl Christoph Seite 105von 231

111 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 108 // CURL-Session beenden 109 curl_close($ch); // 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

112 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG 1 if($_post["chksum"]!= md5($_post["data"]." ".$row["kennung"])) 2 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 if($_server["http_user_agent"]!= "ALFSA sync agent") 2 { 3 append_to_log("user agent", "wrong user agent dedected: ".$_SERVER[ "HTTP_USER_AGENT"], "critic"); 4 die( You are not allowed to show this page directly!<br />."\n". 5 go to: <a href="http://www.bfkdo-tulln.at/alfsa/">alfsa - webpage</a><br />."\n". 6 <br />."\n". 7 [=agerr] ); 8 } Listing 4.49: PHP Code zur Prüfung des User-Agent Sequenzdiagramm Dieses Sequenzdiagramm stellt den Ablauf der Client - Server Synchronisation dar. Brandstätter Andreas, Klaffl Christoph Seite 107von 231

113 KAPITEL 4. PLANUNG UND IMPLEMENTIERUNG Abbildung 4.9: Sequenzdiagramm 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

R e m o t e A c c e s s. Cyrus Massoumi

R e m o t e A c c e s s. Cyrus Massoumi R e m o t e A c c e s s Präsentation im Seminar Internet-Technologie im Sommersemester 2008 von Cyrus Massoumi I n h a l t Was versteht man unter Remote Access Unsichere Remotezugriffe TELNET Remote Shell

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Remote Tools SSH SCP Proxy SFTP Port X11 christina.zeeh@studi.informatik.uni-stuttgart.de Grundlagen SSH Inhalt Remote-Login auf marvin Datentransfer Graphische Anwendungen Tunnel VPN SSH für Fortgeschrittene

Mehr

Remote Tools SFTP. Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools SFTP. Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Proxy Remote Tools SFTP SSH X11 Port SCP christina.zeeh@studi.informatik.uni-stuttgart.de Inhalt Grundlagen SSH Remote-Login auf marvin Datentransfer Graphische Anwendungen Tunnel VPN SSH für Fortgeschrittene

Mehr

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Remote Tools SSH SCP Proxy SFTP Port X11 christina.zeeh@studi.informatik.uni-stuttgart.de Grundlagen IP-Adresse 4x8 = 32 Bit Unterteilung des Adressraumes in Subnetze (Uni: 129.69.0.0/16) 129.69.212.19

Mehr

Seminar Internet-Technologie

Seminar Internet-Technologie Seminar Internet-Technologie Zertifikate, SSL, SSH, HTTPS Christian Kothe Wintersemester 2008 / 2009 Inhalt Asymmetrisches Kryptosystem Digitale Zertifikate Zertifikatsformat X.509 Extended-Validation-Zertifikat

Mehr

Installationsleitfaden kabelsafe storage mit FileZilla Client Programm

Installationsleitfaden kabelsafe storage mit FileZilla Client Programm Installationsleitfaden kabelsafe storage mit FileZilla Client Programm Installationsanleitung kabelsafe storage unter Verwendung des kostenlos unter verschiedenen Betriebssystemplattformen (Windows, Apple

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

Versionskontrollsysteme

Versionskontrollsysteme Versionskontrollsysteme Erfassung von Änderungen an Dateien Protokollierung von Änderungen Wiederherstellung alter Zustände Archivierung der gesamten Historie Koordinierung des gemeinsamen Zugriffs Verzweigung

Mehr

LINUX Schulung. FrauenComputerZentrum Berlin. Jutta Horstmann, Mai 2006

LINUX Schulung. FrauenComputerZentrum Berlin. Jutta Horstmann, Mai 2006 LINUX Schulung FrauenComputerZentrum Berlin Jutta Horstmann, Mai 2006 Agenda Was ist Linux Was ist Open Source Warum Open Source Software Wie sieht Open Source Software aus Was kann man damit machen Ausprobieren!!

Mehr

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH von Dominick Baier (dbaier@ernw.de) und Jens Franke (jfranke@ernw.de) 1 Einleitung Dieses Dokument behandelt die flexible

Mehr

Collax Web Application

Collax Web Application Collax Web Application Howto In diesem Howto wird die Einrichtung des Collax Moduls Web Application auf einem Collax Platform Server anhand der LAMP Anwendung Joomla beschrieben. LAMP steht als Akronym

Mehr

Enigma2 Plugin Entwicklung mit Eclipse

Enigma2 Plugin Entwicklung mit Eclipse Enigma2 Plugin Entwicklung mit Eclipse Enigma2 Plugin Entwicklung mit Eclipse 1/15 Inhaltsverzeichnis 1 ÜBER... 3 2 INSTALLATION... 4 2.1 INSTALLATION VON ECLIPSE... 4 2.2 INSTALLATION VON PYDEV... 4 3

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

SSH. Die Secure Shell am Beispiel von OpenSSH. Dirk Geschke. Linux User Group Erding. 26. Oktober 2011

SSH. Die Secure Shell am Beispiel von OpenSSH. Dirk Geschke. Linux User Group Erding. 26. Oktober 2011 SSH Die Secure Shell am Beispiel von OpenSSH Dirk Geschke Linux User Group Erding 26. Oktober 2011 Dirk Geschke (LUG-Erding) SSH 26. Oktober 2011 1 / 18 Gliederung 1 Historisches 2 Details 3 Keys 4 SSH-Optionen

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Linux im Studium. Serbest Hammade / Resh, Christian Sturm. Do, 15. November 2012

Linux im Studium. Serbest Hammade / Resh, Christian Sturm. Do, 15. November 2012 Linux im Studium Serbest Hammade / Resh, Christian Sturm Do, 15. November 2012 Linux Aufbau von Linux Distributionen Grafische Desktopumgebungen HFU & Linux Instant Messaging via Jabber (XMPP) HFU & Jabber

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Persona-SVS e-sync auf Windows Terminal Server

Persona-SVS e-sync auf Windows Terminal Server Persona-SVS e-sync auf Windows Terminal Server 2014 by Fraas Software Engineering GmbH Alle Rechte vorbehalten. Fraas Software Engineering GmbH Sauerlacher Straße 26 82515 Wolfratshausen Germany http://www.fraas.de

Mehr

HTWK Leipzig. Matthias Jauernig. Die Secure Shell

HTWK Leipzig. Matthias Jauernig. Die Secure Shell LV Kryptologie WS06/07, HTWK Leipzig Matthias Jauernig 12.12.06 SSH Die Secure Shell Inhalt 1. Motivation 2. Historie 3. Funktionsweise von SSH-2 4. Das OpenSSH Programmpaket 5. Schlussbemerkungen, Links

Mehr

Schwachstellenanalyse 2013

Schwachstellenanalyse 2013 Schwachstellenanalyse 2013 Sicherheitslücken und Schwachstellen in Onlineshops Andre C. Faßbender Schwachstellenforschung Faßbender 09.01.2014 Inhaltsverzeichnis 1. Abstract... 3 2. Konfiguration der getesteten

Mehr

Lastenheft zur Diplomarbeit. Konzeption und Realisierung einer Intranet-Lösung mit TYPO3 auf Basis der Knoppix-Linux-Distribution und VMWare

Lastenheft zur Diplomarbeit. Konzeption und Realisierung einer Intranet-Lösung mit TYPO3 auf Basis der Knoppix-Linux-Distribution und VMWare Lastenheft zur Diplomarbeit Konzeption und Realisierung einer Intranet-Lösung mit TYPO3 auf Basis der Knoppix-Linux-Distribution und VMWare Fakultät für Informatik, TU Karlsruhe erstellt: 19.01.2005 Zusammenfassung

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

SQL, MySQL und FileMaker

SQL, MySQL und FileMaker SQL, MySQL und FileMaker Eine kurze Einführung in SQL Vorstellung von MySQL & phpmyadmin Datenimport von MySQL in FileMaker Autor: Hans Peter Schläpfer Was ist SQL? «Structured Query Language» Sprache

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

KeePass. 19.01.2010 10:15-10:45 Uhr. Birgit Gersbeck-Schierholz, IT-Sicherheit, RRZN

KeePass. 19.01.2010 10:15-10:45 Uhr. Birgit Gersbeck-Schierholz, IT-Sicherheit, RRZN KeePass the free, open source, light-weight and easy-to-use password manager 19.01.2010 10:15-10:45 Uhr Birgit Gersbeck-Schierholz, IT-Sicherheit, RRZN Agenda Einführung Versionen Features Handhabung Mobile

Mehr

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle Vorlesung Programmieren Versionskontrolle Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Versionskontrollsysteme Wie organisiert man die

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

Einführung in Verteilte Versionskontrollsysteme. am Beispiel von Git

Einführung in Verteilte Versionskontrollsysteme. am Beispiel von Git Einführung in Verteilte Versionskontrollsysteme am Beispiel von Git Diplominformatiker (BA), Git Benutzer seit 2009 Daniel Böhmer Leibniz Institut für Troposphärenforschung 8. März 2012 Verteilte Versionskontrollsysteme/Git

Mehr

Handbuch für ios 1.4 1

Handbuch für ios 1.4 1 Handbuch für ios 1.4 1 Inhaltsverzeichnis 1. Leistungsumfang... 3 1.1 Über Boxcryptor Classic... 3 1.2 Über dieses Handbuch... 4 2. Installation... 5 3. Grundfunktionen... 6 3.1. Einrichtung von Boxcryptor

Mehr

Handbuch für Android 1.5

Handbuch für Android 1.5 Handbuch für Android 1.5 1 Inhaltsverzeichnis 1 Leistungsumfang... 3 1.1 Über Boxcryptor Classic... 3 1.2 Über dieses Handbuch... 3 2. Installation... 5 3. Grundfunktionen... 5 3.1 Einrichtung von Boxcryptor

Mehr

CVS-Einführung. Sebastian Mancke, mancke@mancke-software.de

CVS-Einführung. Sebastian Mancke, mancke@mancke-software.de CVS-Einführung Sebastian Mancke, mancke@mancke-software.de Grundlagen Motivation und Anforderung Sobald ein Softwaresystem anwächst, ergeben sich Probleme im Umgang mit dem Quell Code. CVS (Concurrent

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Anmeldung über Netz Secure Socket Layer Secure Shell SSH 1 SSH 2. Systemverwaltung. Tatjana Heuser. Sep-2011. Tatjana Heuser: Systemverwaltung

Anmeldung über Netz Secure Socket Layer Secure Shell SSH 1 SSH 2. Systemverwaltung. Tatjana Heuser. Sep-2011. Tatjana Heuser: Systemverwaltung Systemverwaltung Tatjana Heuser Sep-2011 Anmeldung über Netz Secure Socket Layer Secure Shell Intro Client-Server SSH 1 Verbindungsaufbau SSH 2 Verbindungsaufbau Konfiguration Serverseite ssh Configuration

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Das Handbuch zu Desktop Sharing. Brad Hards Übersetzung: Frank Schütte

Das Handbuch zu Desktop Sharing. Brad Hards Übersetzung: Frank Schütte Brad Hards Übersetzung: Frank Schütte 2 Inhaltsverzeichnis 1 Einleitung 5 2 Das Remote Frame Buffer -Protokoll 6 3 Verwendung von Desktop Sharing 7 3.1 Verwaltung von Desktop Sharing-Einladungen.....................

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Universal Mobile Gateway V4

Universal Mobile Gateway V4 PV-Electronic, Lyss Universal Mobile Gateway V4 Autor: P.Groner Inhaltsverzeichnis Allgemeine Informationen... 3 Copyrightvermerk... 3 Support Informationen... 3 Produkte Support... 3 Allgemein... 4 Definition

Mehr

Domain Control System. [ Dokumentation und Hilfe ] Stand 10. 05. 2005

Domain Control System. [ Dokumentation und Hilfe ] Stand 10. 05. 2005 Domain Control System [ Dokumentation und Hilfe ] Stand 10. 05. 2005 Seite 1 von 9 Einfü hrung Das 4eins Domain Control System (DCS) stellt Ihnen verschiedene Dienste und Funktionen für die Konfiguration

Mehr

Martin Vorländer PDV-SYSTEME GmbH

Martin Vorländer PDV-SYSTEME GmbH SSH - eine Einführung Martin Vorländer PDV-SYSTEME GmbH Das Problem TCP/IP-Dienste (z.b. Telnet, FTP, POP3, SMTP, r Services, X Windows) übertragen alle Daten im Klartext - auch Passwörter! Es existieren

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Holger Wirtz, DFN-Verein. wirtz@dfn.de. 36. Betriebstagung

Holger Wirtz, DFN-Verein. wirtz@dfn.de. 36. Betriebstagung Holger Wirtz, DFN-Verein wirtz@dfn.de 36. Betriebstagung Wozu eine Standortverwaltung? Entwurf und Entscheidungskriterien Implementierung Vorführung Erweiterungen Was soll verwaltet werden? Ansammlung

Mehr

WinSCP Zugriff auf Daten des Uni-Netzwerkes

WinSCP Zugriff auf Daten des Uni-Netzwerkes WinSCP Zugriff auf Daten des Uni-Netzwerkes Robert Hillig 2013/03 1. Vorwort Das Universitätsnetzwerk ist von außen per SSH (Secure SHell) über login.tu-chemnitz.de auf Port 22 erreichbar. SSH ist ein

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

MySQL Schulung - Zusammenfassung

MySQL Schulung - Zusammenfassung MySQL Schulung - Zusammenfassung Marcel Noe 9.10-20.10.2006 Kapitel 1 1.1 MySQL Einführung 1.1.1 Einleitung Bei MySQL handelt es sich um einen sehr skalierbares Datenbank-Management System. MySQL wird

Mehr

Remote Desktop Verbindungen. Felix SEMMLER Heiko KISS Systemprogrammierung SS08 Fachhochschule Wiesbaden

Remote Desktop Verbindungen. Felix SEMMLER Heiko KISS Systemprogrammierung SS08 Fachhochschule Wiesbaden Remote Desktop Verbindungen Felix SEMMLER Heiko KISS Systemprogrammierung SS08 Fachhochschule Wiesbaden Agenda Überblick Remote Control Remote Desktop Protocol Virtual Network Computing NX NoMachine RDesktop

Mehr

1 Remotedesktopdienste (ehem. Terminal Services)

1 Remotedesktopdienste (ehem. Terminal Services) Windows Server 2008 (R2): Anwendungsserver 1 Remotedesktopdienste (ehem. Terminal Services) Die Remotedesktopdienste gehören zu den Desktopvirtualisierungsprodukten von Microsoft. Die Remotedesktopdienste

Mehr

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001 V3.05.001 MVB3 Admin-Dokumentation Einrichten eines Servers für MVB3 ab Version 3.5 Inhalt Organisatorische Voraussetzungen... 1 Technische Voraussetzungen... 1 Konfiguration des Servers... 1 1. Komponenten

Mehr

How to install freesshd

How to install freesshd Enthaltene Funktionen - Installation - Benutzer anlegen - Verbindung testen How to install freesshd 1. Installation von freesshd - Falls noch nicht vorhanden, können Sie das Freeware Programm unter folgendem

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

SSH. Nun brauchen wir noch das passwd-file. Dieses erstellen wir mit folgendem Befehl: mkpasswd -k -u marco >>..\etc\passwd

SSH. Nun brauchen wir noch das passwd-file. Dieses erstellen wir mit folgendem Befehl: mkpasswd -k -u marco >>..\etc\passwd SSH 1 Grundlagen... 1 2 Authentifizierung... 1 3 Installation von OpenSSH for Windows... 1 3.1 Anmeldung mit Schlüsselpaar... 3 4 SSH-Tunnel... 4 4.1 Funktionsweise... 5 4.2 Remote-Desktop durch einen

Mehr

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof Authentifizierung Benutzerverwaltung mit Kerberos Referent: Jochen Merhof Überblick über Kerberos Entwickelt seit Mitte der 80er Jahre am MIT Netzwerk-Authentifikations-Protokoll (Needham-Schroeder) Open-Source

Mehr

ESB - Elektronischer Service Bericht

ESB - Elektronischer Service Bericht Desk Software & Consulting GmbH ESB - Elektronischer Service Bericht Dokumentation des elektronischen Serviceberichts Matthias Hoffmann 25.04.2012 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713

Mehr

Sicherheitskonzept Verwendung Batix CMS

Sicherheitskonzept Verwendung Batix CMS TS Sicherheitskonzept Verwendung Batix CMS Sicherheitsrichtlinien und Besonderheiten Batix CMS ausgearbeitet für VeSA Nutzer Version: 1.3 Stand: 1. August 2011 style XP communications Gössitzer Weg 11

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum CORVUS by init.at... 3 3 Ihre Vorteile durch CORVUS... 3 4 CORVUS Features... 4

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Mindtime Online Backup

Mindtime Online Backup Mindtime Online Backup S e r v i c e L e v e l A g r e e m e n t Inhaltsangabe Service Definition... 3 1) Datenverschlüsselung... 3 2) Gesicherte Internetverbindung... 3 3) Datencenter... 4 4) Co- Standort...

Mehr

TYPO3 KNOW-HOW INHALT. von Alexander Busch, MCITP, MCSA 2003, CCA, VCS. Spam-Schutz für Typo3... 2. Robots.txt in Typo3... 2. Captcha Extension...

TYPO3 KNOW-HOW INHALT. von Alexander Busch, MCITP, MCSA 2003, CCA, VCS. Spam-Schutz für Typo3... 2. Robots.txt in Typo3... 2. Captcha Extension... TYPO3 KNOW-HOW von Alexander Busch, MCITP, MCSA 2003, CCA, VCS INHALT Spam-Schutz für Typo3... 2 Robots.txt in Typo3... 2 Captcha Extension... 3 Meta Angaben... 3 TYPO3 Update 4.1.10 auf 4.2.6... 4 SPAM-SCHUTZ

Mehr

Anleitungen und Informationen zu KK-NetServer

Anleitungen und Informationen zu KK-NetServer Anleitungen und Informationen zu KK-NetServer 1. Vorwort Unser KK-NetServer ist einer der modernsten und sichersten Daten-Server mit verschiedenen Nutzungsrechten. Er dient in erster Linie zur Bereitstellung

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Konfiguration HTTPS-Tunnel

Konfiguration HTTPS-Tunnel Konfiguration HTTPS-Tunnel Installation und Hinweise für Entwickler und Administratoren Weitere Informationen zu CATS finden Sie im Internet unter www.cats.ms Stand: 07.06.2006 by SPUeNTRUP Software 1/9

Mehr

Qargo.com Qargo X - Online Freight-Exchange-System - Frachtenbörse

Qargo.com Qargo X - Online Freight-Exchange-System - Frachtenbörse Qargo.com Qargo X - Online Freight-Exchange-System - Frachtenbörse Dokumentation Version: 1.0 Stand: 08.08.2008 Seite 1 von 16 Inhaltsverzeichnis 1 Erste Schritte... 3 1.1 Über qargo x... 3 1.2 Installation...

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Installationsanleitung TOPIX WebSolution Server

Installationsanleitung TOPIX WebSolution Server Installationsanleitung TOPIX WebSolution Server WebSolution Version 1.309 TOPIX:8 Ab Version 8.9.3v2 Stand 08/2014 Inhalt 1 Systemvoraussetzungen...3 2 Vorbereitungen für die Installation...4 Die aktuelle

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

GNU / Linux. TUX, das Linux-Maskottchen von Larry Ewing, Simon Budig and Anja Gerwinski. Betriebssysteme Studiengang Kartographie und Geomatik

GNU / Linux. TUX, das Linux-Maskottchen von Larry Ewing, Simon Budig and Anja Gerwinski. Betriebssysteme Studiengang Kartographie und Geomatik GNU / Linux TUX, das Linux-Maskottchen von Larry Ewing, Simon Budig and Anja Gerwinski 1 GNU/Linux General Public Licence (GPL) Allgemeine Lizenz für quell-offene und lizenzfreie Software Zusammenfassung:

Mehr

TimePunch SQL Server Datenbank Setup

TimePunch SQL Server Datenbank Setup TimePunch TimePunch SQL Server Datenbank Setup Benutzerhandbuch 26.11.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch SQL Server Datenbank

Mehr

Medienkompetenz, Grafik und DTP

Medienkompetenz, Grafik und DTP VO 340381 Informationsdesign; Medienkompetenz, Grafik und DTP Zentrum für Translationswissenschaft Letztes Mal sprachen wir über: Computer Aufbau Software Was ist Software? Software Soft im Sinne von weich/veränderbar

Mehr

Einrichtung des NVS Calender-Google-Sync-Servers. Installation des NVS Calender-Google-Sync Servers (Bei Neuinstallation)

Einrichtung des NVS Calender-Google-Sync-Servers. Installation des NVS Calender-Google-Sync Servers (Bei Neuinstallation) Einrichtung des NVS Calender-Google-Sync-Servers Folgende Aktionen werden in dieser Dokumentation beschrieben und sind zur Installation und Konfiguration des NVS Calender-Google-Sync-Servers notwendig.

Mehr

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen SFTP Datenübertragungsclient PK-SFTP automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen senden, abholen und verifizieren der bereitstehenden Daten Protokollierung der Datenübertragung

Mehr

Installationsanleitung MS SQL Server 2005. für Sage 50 Ablage & Auftragsbearbeitung. Sage Schweiz AG D4 Platz 10 CH-6039 Root Längenbold

Installationsanleitung MS SQL Server 2005. für Sage 50 Ablage & Auftragsbearbeitung. Sage Schweiz AG D4 Platz 10 CH-6039 Root Längenbold Installationsanleitung MS SQL Server 2005 für Sage 50 Ablage & Auftragsbearbeitung Sage Schweiz AG D4 Platz 10 CH-6039 Root Längenbold Inhaltsverzeichnis 1. GRUNDSÄTZLICHES... 3 2. SQLExpress Installationsanleitung

Mehr

Softwareverteilung. mit. m23

Softwareverteilung. mit. m23 Softwareverteilung mit m23 Überblick Was ist Softwareverteilung? Was ist m23? Warum m23? Wie funktioniert m23? Live-Demonstration Was ist Softwareverteilung? Was ist Softwareverteilung? Installation von:

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

LUSC Workshopweekend 2008. Verschlüsselung mit Truecrypt

LUSC Workshopweekend 2008. Verschlüsselung mit Truecrypt LUSC Workshopweekend 2008 Verschlüsselung mit Truecrypt Zusammenfassung Teil 1 Was ist Truecrypt? Warum Truecrypt? Was macht die Software? Verschiedene Varianten Anwendungsmöglichkeiten Gundlagen 1, 2

Mehr

MySQL Cluster. Kai Voigt MySQL AB kai@mysql.com. Kiel, 17. Februar 2006

MySQL Cluster. Kai Voigt MySQL AB kai@mysql.com. Kiel, 17. Februar 2006 MySQL Cluster Kai Voigt MySQL AB kai@mysql.com Kiel, 17. Februar 2006 1 Agenda Warum? Wie? Wie genau? Was sonst? 2 Warum? 3 Kosten runter Hochverfügbarkeit (99,999%) Redundante Daten und Systeme Wiederherstellung

Mehr

Good Dynamics by Good Technology. V1.1 2012 by keyon (www.keyon.ch)

Good Dynamics by Good Technology. V1.1 2012 by keyon (www.keyon.ch) Good Dynamics by Good Technology eberhard@keyon.ch brunner@keyon.ch V1.1 2012 by keyon (www.keyon.ch) 1 Über Keyon Experten im Bereich IT-Sicherheit und Software Engineering Als Value added Reseller von

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

HD-Pool und Remote Tools

HD-Pool und Remote Tools HD-Pool und Remote Tools Kleine Hausapotheke gegen poolbedingte Klaustrophobie Ina Becker Inhalt Hauptdiplomspool Arbeiten in der Universität Arbeiten von zu Hause aus Internetzugang durch Informatik/Uni

Mehr

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen)

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen) Datenschutzerklärung der Etacs GmbH Die Etacs GmbH wird den Anforderungen des Bundesdatenschutzgesetzes (BDSG) gerecht.personenbezogene Daten, d.h Angaben, mittels derer eine natürliche Person unmittelbar

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Multisite Setup. mit Nutzung von Subversion. Drupal Voice Chat 21.10.2008 mcgo@drupalist.de

Multisite Setup. mit Nutzung von Subversion. Drupal Voice Chat 21.10.2008 mcgo@drupalist.de Multisite Setup mit Nutzung von Subversion Drupal Voice Chat 21.10.2008 mcgo@drupalist.de 1 Voraussetzungen Server (dediziert oder virtuell) Zugriff auf Terminal (z.b. per ssh) Webserver / Datenbankserver

Mehr

Hinweise zu A-Plan 2009 SQL

Hinweise zu A-Plan 2009 SQL Hinweise zu A-Plan 2009 SQL Für Microsoft Windows Copyright Copyright 2008 BRainTool Software GmbH Inhalt INHALT 2 EINLEITUNG 3 WAS IST A-PLAN 2009 SQL? 3 WANN SOLLTE A-PLAN 2009 SQL EINGESETZT WERDEN?

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Embedded Linux, OpenWRT

Embedded Linux, OpenWRT Embedded Linux, OpenWRT von Tim Keller EBV Spezialbetriebssysteme 1 Pro und Contra Embedded Linux Pro fehlende (oder bei fertigen Distributionen geringere) Lizenz- und Laufzeitgebühren Zugang zum Quellcode(gut

Mehr

Installationsanleitung für Haufe Advolux Kanzleisoftware ab Version 2.5 (Linux)

Installationsanleitung für Haufe Advolux Kanzleisoftware ab Version 2.5 (Linux) Installationsanleitung für Haufe Advolux Kanzleisoftware ab Version 2.5 (Linux) Verfasser : Advolux GmbH, AÖ Letze Änderung : 20.04.2012 Version : v2 1 Inhaltsverzeichnis 1. Hardware-Voraussetzungen...

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

Anleitungen und Informationen zu KK-CloudServer

Anleitungen und Informationen zu KK-CloudServer Anleitungen und Informationen zu KK-CloudServer 1. Vorwort Ihr neuer KK-CloudServer ist eines der modernsten und sichersten Daten-Server- Systeme zur sicheren und plattformunabhängigen Aufbewahrung Ihrer

Mehr

TYPO3-Workshop Zugangsgeschützte Webbereiche in TYPO3

TYPO3-Workshop Zugangsgeschützte Webbereiche in TYPO3 Leibniz Universität IT Services TYPO3-Workshop Zugangsgeschützte Webbereiche in TYPO3 Workshop TYPO3@RRZN Sep. 2012 Dr. Thomas Kröckertskothen - RRZN Zugangsgeschützte Webbereiche in TYPO3 Was sind zugangsgeschützte

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage. RAM empfohlen. RAM maximal

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage. RAM empfohlen. RAM maximal 1. HANDLUNGSSCHRITT Aufgabe 13 Betriebssystem Prozessortakt RAM empfohlen RAM maximal Installationsgröße SMP Anzahl Prozessoren Windows 7 Ultimate 2008 Web 2008 Standard 2008 Enterprise 2008 Datacenter

Mehr

Internet Information Services v6.0

Internet Information Services v6.0 Internet Information Services v6.0 IIS History Evolution von IIS: V1.0 kostenlos auf der CeBit 1996 verteilt V2.0 Teil von Windows NT 4.0 V3.0 Als Update in SP3 von NT4.0 integriert V4.0 Windows NT 4.0

Mehr

Anleitung. Handhabung des ftp-clients FileZilla. Copyright 2015 by BN Automation AG

Anleitung. Handhabung des ftp-clients FileZilla. Copyright 2015 by BN Automation AG Anleitung Handhabung des ftp-clients FileZilla Copyright 2015 by BN Automation AG Alle Rechte vorbehalten. Die Weitergabe und Vervielfältigung dieses Dokuments oder von Teilen davon ist gleich welcher

Mehr

Browser mit SSL und Java, welcher auf praktisch jedem Rechner ebenso wie auf vielen mobilen Geräten bereits vorhanden ist

Browser mit SSL und Java, welcher auf praktisch jedem Rechner ebenso wie auf vielen mobilen Geräten bereits vorhanden ist Collax SSL-VPN Howto Dieses Howto beschreibt wie ein Collax Server innerhalb weniger Schritte als SSL-VPN Gateway eingerichtet werden kann, um Zugriff auf ausgewählte Anwendungen im Unternehmensnetzwerk

Mehr

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen 1 Allgemeines Was versteht man unter SFTP? Die Abkürzung SFTP steht für SSH File Transfer Protocol oder Secure File Transfer Protocol.

Mehr

Installationsanleitung Webhost Linux Flex

Installationsanleitung Webhost Linux Flex Installationsanleitung Webhost Linux Flex Stand März 2014 Inhaltsverzeichnis 1. Zugangsdaten & Login... 3 2. Passwort ändern... 4 3. Leistungen hinzufügen / entfernen... 6 4. Datenbanken anlegen / entfernen...

Mehr