Management virtueller Web-Server

Transkript

1 SemWebSE Management virtueller Web-Server Oliver Blaha 1

2 Virtuelle Server Für viele Dienste ist kein eigener physikalischer Rechner notwendig: Mehrere Dienste/Anwender/Kunden teilen sich die Ressourcen eines Systems. Auf einem Rechner werden dazu diverse virtuelle Server betrieben. Wirtschaftlich: Einsparung von Hardwarekosten... Wartungskosten... laufenden Kosten (Stellplatz, Netzanbindung) 2

3 Virtuelle Server auf Basis von Betriebssystemen Ein Host-Betriebssystem beherbergt mehrere Gast- Betriebssysteme Zugriff auf Hardware-Ressourcen ausschließlich über das Host-System Virtualisierung auf verschiedenen Ebenen möglich: Abgeschottete Bereiche des Host-Systems (z.b. Linux vserver) Nutzung des Betriebssystems des Hosts (z.b. Xen) Komplette Betriebssysteme als Gast, einzig Verwaltung der Hardware-Ressourcen durch Host (z.b. User Mode Linux) 3

4 Virtuelle Server auf Basis von Diensten Nur ein Betriebssystem Parallel laufende Dienste, die nach außen den Anschein unabhängiger Server erwecken Beispiel: Ein typischer kommerzieller Web-Server verwaltet auf diese Weise die Internetpräsenzen meist dutzender, wenn nicht gar hunderter Kunden.

5 Typischer Web-Server Zielsetzung: Betrieb eines typischen, kommerziell nutzbaren Web-Servers für durchschnittliche Endkunden Der Server sollte dabei zumindest folgende Dienste bieten: Http (u.a. mit PHP-Unterstützung) Ftp (SMTP, POP3, IMAP) SQL-Datenbank 5

6 Welche Art virtueller Server? Betriebssystem-Basis Dienste-Basis Vorteile: Vorteile: Hohe Unabhängigkeit Einfache Wartung Maximale Flexibilität Zentrale Konfiguration Nachteile: Nachteile: Hoher Aufwand bei Konfiguration und Wartung Einschränkung der Flexibilität 6

7 Welche Art virtueller Server? Die Entscheidung ist ein Kompromiss zwischen Flexibilität und Aufwand. Zielgruppe: Durchschnittliche Anwender i.d.r. nur eingeschränkte technische Kenntnisse Zentrale Konfiguration sinnvoll Möglichst einfacher Zugriff auf die Dienste wenig Bedarf an Speziallösungen Fazit: Virtueller Server auf Basis von Diensten 7

8 Zugriffsmöglichkeiten auf den Server Unmittelbarer Zugriff Zugriff über direkt angeschlossene Peripheriegeräte (Tastatur, Maus, Monitor) Remote Administration Als Remote Administration bezeichnet man alle Möglichkeiten, bestimmte Funktionen eines Rechners fernzusteuern 8

9 Gründe für Remote Administration Kein direkter Zugriff auf den Rechner Räumliche Entfernung (z.b. Unterbringung in Rechenzentrum) Technische Gründe (z.b. keine Tastatur oder kein Bildschirm) Zentralisierung (Verwaltung mehrerer Rechner von einem Arbeitsplatz aus) Distribution (Verwaltung eines oder mehrerer Rechner von den verschiedensten Orten aus) 9

10 Was leistet Remote Administration? Meist administrative Aufgaben, z.b.: Konfiguration Softwareinstallation Steuern von (Server-)Diensten Überwachung Auswerten von Daten 10

11 Möglichkeiten der Remote Administration Vollständiger Zugriff Geht über reine Administration hinaus Umfassende Kontrolle Spezialisierter Zugriff Besserer Überblick über tatsächlich relevante Funktionen Vereinfachte Bedienung 11

12 Vollständiger Zugriff Konsole telnet ssh Grafisches System X-Forwarding VNC Apple Remote Desktop Remote Desktop Protocol (RDP) Timbuktu 12

13 Spezialisierter Zugriff Spezialisierter Zugriff Client-Software z.b. Programme zur Datenbank-Verwaltung Beispiel: MySQLGUI Webbasierte Werkzeuge unter anderem zur Verwaltung von Serverdiensten (z.b. Webmin)... zur Datenbank-Verwaltung (z.b. phpmyadmin)... Online-Shop-Systeme (z.b. OSCommerce)... zum Management kommerzieller Web-Server 13

14 Wahl der Zugriffsart 2 unterschiedliche Szenarien: Installation & Wartung: Vollständiger Zugriff notwendig (Remote) Keine Vereinfachung nötig Grafische Oberfläche nicht notwendig ssh Regulärer Betrieb: Zugriff durch Anwender/Kunden (Remote) Möglichst einfache, zielgerichtete Bedienbarkeit erforderlich Rechte-Management Webbasierte, spezielle Software-Lösung 14

15 Vergleich der speziellen Software-Lösungen Wichtige Vergleichskriterien: Lizenzmodell: Proprietär Open-Source Funktionsumfang Bedienung: Wichtig: Akzeptanz durch Anwender! Skalierbarkeit: Was tun wenn die Anforderungen wachsen? Flexibilität & Kompatibilität: z.b. Abhängigkeit von bestimmten Modulen oder freie Wahl? Betriebssystem? 15

16 Vergleich der Lizenzmodelle Proprietär Open-Source Vorteile: Vorteile: Support i.d.r. inklusive Keine Lizenzkosten Haftung durch Hersteller Nachteile: Eigene Anpassungen möglich Kompromiss zwischen Kosten und Leistungsfähigkeit Nachteile: Keine Haftung durch Hersteller Meist keine eigenen Anpassungen möglich 16

17 Proprietäre Software-Lösungen Confixx Sehr verbreitet Leicht bedienbar Optisch ansprechend Akzeptanz durch Anwender Nur für Einzelsysteme, kaum skalierbar Geringe Flexibilität Linux 17

18 Proprietäre Software-Lösungen ViSAS Kostengünstig Nur für Einzelsysteme, kaum skalierbar Etwas größerer Funktionsumfang als Confixx Plesk Modular, daher sehr skalierbar Nachfolger von Confixx, daher Akzeptanz der Anwender Zentrale Steuerung mehrerer Systeme möglich Auch als Windows-Version verfügbar Aber: Sehr teuer! 18

19 Open-Source-Lösungen Ispman Sehr flexibel, speziell konzipiert für n-tier-architektur: Frontend-Server (hosten die Anwender-Schnittstelle) Backend-Server Datenbank-Server Funktionsreichste Open-Source-Lösung Umständlich zu bedienen Schwer einzurichten Langsam 19

20 Open-Source-Lösungen SysCP Nur für Einzelsysteme, kaum skalierbar VHCS Hat offensichtlich Confixx zum Vorbild, daher erbt es dessen Vorzüge: Optisch ansprechend Leichte Bedienbarkeit Hohe Akzeptanz Jedoch gilt auch hier: Nur für Einzelsysteme, kaum skalierbar 20

21 Beispiel: VHCS Funktionsweise Schritte zum lauffähigen System: Vorbereiten des Systems Installation der Software Konfiguration der Dienste Anpassen an spezielle Erfordernisse 21

22 Funktionsweise von VHCS Einfache 2-Tier-Architektur: Client (Web-Oberfläche): Interagiert mit Benutzer Führt Plausibilitätsprüfungen durch Sendet Kommandos an den VHCS Daemon Server (VHCS Daemon): Zuständig für tatsächliche Änderungen an der Konfiguration der Dienste 22

23 Vorbereiten des Systems Installation des Betriebssystems: Linux (z.b. Debian Sarge) Installation der nötigen Dienste, VHCS gibt hier vor welche Software verwendet werden muss: Http: Apache, mit PHP Ftp: ProFTPd Postfix (SMTP) + Courier IMAP (IMAP + POP3) Datenbank: MySQL Vorbereiten einer Datenbank + DB-Benutzer 23

24 Installation Installation von VHCS: Download ( Entpacken Entsprechend der dem Archiv beiliegenden Anleitung in wenigen Schritten installieren 24

25 Konfiguration Bei VHCS erfolgt die Konfiguration im Zuge der Installation weitestgehend automatisch. Besonders aufpassen bei: /etc/hosts: Hier sollte die eigene IP und der eigene Hostname korrekt eingetragen sein Mail-Konfiguration (/etc/postfix/main.cf): Wichtig: Korrekten Hostname des Servers einstellen! Andernfalls könnten ausgehende Mails von fremden Servern abgelehnt werden Auf die Behandlung der Haupt-Domain achten ggf. werden Mails sonst an lokale Benutzerkonten zugestellt 25

26 Anpassen Mögliche Anpassungen der Software: Änderungen um andere Dienst-Software verwenden zu können (z.b. um bestimmte Features zu ermöglichen) Allg. Erweiterung/Einschränkung der Funktion (z.b. generelles Deaktivieren von Alias-Domains) Beheben/Umgehen von Sicherheitslücken 26

27 Beispiel: Sicherheitslücke Alias-Domains Benutzer können ihren Präsenzen selbst Alias-Domains hinzufügen Problem: Was passiert wenn der Benutzer an der Domain nicht berechtigt ist? Auf den ersten Blick nicht kritisch, da Domains durch zentrale Vergabestellen verwaltet werden Aber: Bei ausgehenden s wird zunächst die lokale Zuständigkeit geprüft, daher: Abfangen von Mails möglich Lösungsansätze: Funktion nicht freischalten (Verlässlichkeit? Faktor Mensch?) Im Quellcode Funktion auskommentieren (Quick'n'Dirty) Prüfroutine integrieren (Aber: Was tun bei Software-Update?) 27

28 Beispiel: Verwendung von Maildrop Die Standardkonfiguration von VHCS nutzt procmail zum Verteilen eingehender Mails. Um stattdessen Maildrop zu verwenden gibt es ein Patch. (Demo Patch) Bereits an dem Patch erkennt man, dass erhebliche Redundanz im Quellcode herrscht. 28

29 VHCS aus Software-Engineering-Sicht Zusammenfassung: Redundanter Code Zaghafte Sicherheitspolitik Rückschluss: VHCS wurde offensichtlich in code-andfix -Zyklen entwickelt: Code wächst, Struktur und Übersicht leiden Wartbarkeit nimmt ab Mit steigender Komplexität nimmt das Risiko von Fehlern und Sicherheitslücken zu 29

30 VHCS aus Software-Engineering-Sicht Besser bei einem Projekt dieser Größe: Wasserfallmodell Hier konkret besonders wichtig: Sorgfältige Planung der benötigten Funktionen Genaue Zuordnung von Rechten der Anwendergruppen Definition von flexiblen Schnittstellen für modulare Erweiterbarkeit VHCS 3.0 wird mitunter aus diesen Gründen, mit besonderem Augenmerk auf Modularität, von Grund auf neu entwickelt. 30