Der Webserverpark im ZIV

• Rainer Perske

• Westfälische Wilhelms-Universität
  Zentrum für Informationsverarbeitung
  Röntgenstraße 7-13
  48149 Münster

• perske@uni-muenster.de
  +49 251 83 31582 (fon)
  +49 251 83 31555 (fax)

Dokumentation:

http://www.uni-muenster.de/ZIV/Technik/WWW/

oder auch:   www.wwu.de/zv/tehcnik/weww

Konzeption und technische Umsetzung

• Dynamisch generierte Inhalte für alle Infoanbieter

• Weitgehende Konfigurierbarkeit durch alle Infoanbieter

• Skalierbarkeit und Performanz

• Ausfallsicherheit und Stabilität

• Einfaches Management

• Erweiterbarkeit und Anpassungsfähigkeit – schon etliche Male bewiesen

• Sicherheit – Datensicherheit, Datenschutz, Schadensbegrenzung

• Neu: Single Sign-On

• Grafik: Struktur – Skizze

• Grafik: Struktur – Details

URLs und Realisierungen (1)

• Verzeichnisbasierte URLs:

  http://www.uni-muenster.de/NAME/
  http://www.wwu.de/NAME/
  https://www.uni-muenster.de/NAME/
  https://sso.uni-muenster.de/NAME/
  https://xsso.uni-muenster.de/NAME/
  https://ssso.uni-muenster.de/NAME/

• Hostbasierte URLs:

  http://NAME.uni-muenster.de/
  http://www.NAME.uni-muenster.de/
  https://NAME.uni-muenster.de/ (extra IP-Adresse+Zertifikat – nur in Ausnahmefällen)
  https://www.NAME.uni-muenster.de/ (extra IP-Adresse+Zertifikat – nur in Ausnahmefällen)

• Domainbasierte URLs (kostenpflichtig):

  http://www.NAME.TLD/
  https://www.NAME.TLD/ (extra IP-Adresse+Zertifikat – nur in Ausnahmefällen)

URLs und Realisierungen (2)

• Realisierungen:

  1. Normaler Webspace (Frontend: Reverse Proxy; Backend: Server und Plattenplatz)
     dedizierte VirtualHosts,
     jeweils auf mehreren Backend-Servern parallel

  2. High-Performance-Webspace (Frontend: Reverse Proxy; Backend: Server und Plattenplatz)
     dedizierte Apache-Prozessgruppen mit spezieller Konfiguration,
     nur in ganz besonderen Fällen (MeinZIV, LearnWeb, ...),
     jeweils auf mehreren Backend-Servern parallel

  3. Redirect (Frontend: Umleitung auf andere Adresse; Backend: nicht verwendet)

  4. Reverse Proxy (Frontend: Durchreichen zu Institutsserver; Backend: nicht verwendet)
     mit oder ohne Lastverteilung
     private IP-Adressen – oder auch externer Standort – für Institutsserver möglich

• Alle Kombinationen von URLs und Realisierungen möglich

Organisatorisches: Webspace beantragen

• Zugriffsrechte hängen an Nutzergruppen

• Manuell gepflegte Bereiche: X0infoXX

• Imperia-gepflegte Bereiche: X6XXXXXX

• Antrag G durch für Finanzmittel Verantwortliche zwingend erforderlich

  • Bei gemischten Webspaces reicht ein Antrag für beide Gruppen

• Keine Kostenberechnung (außer Fremddomains oder Terabytes)

• Ausfüllhilfe:
  Titel/Thema der Arbeit: Infoanbieter „Name des Projekts“
  Falls Imperia-gepflegt: Ressourcen: Rechner: Webserverpark, Software: Imperia
  Falls manuell gepflegt: Ressourcen: Rechner: Webserverpark, Software: SSH / Samba
  Finanzierungsart: immer WWU, auch bei Drittmittelprojekten

• Bitte immer vorher mit uns absprechen!

• Ansprechpartner: R. Perske (manuelle Webspaces), W. Kaspar oder Online-Redaktion (Imperia-Webspaces)

Organisatorisches: Redirect oder Reverse Proxy beantragen

• Einrichtung auf Zuruf (Telefon, E-Mail)

• Nur durch Verantwortliche

  • Nutzergruppenleiter von Infoanbietergruppen

  • technisch Verantwortliche von Webservern

  • Online-Redaktion

  • usw.

• Nur Einzelfälle, keine Massen

• Bitte immer mit uns absprechen! – Ansprechpartner: R. Perske

Organisatorisches: Namenswahl

• Verzeichnisbasiert: http://www.uni-muenster.de/NAME/ usw.

  • Grundsätzlich keine Dreibuchstabenkürzel

  • Grundsätzlich keine Begriffe, auf die mehrere Stellen Anspruch erheben könnten

  • Bei Bedenken und über Ausnahmen entscheidet Online-Redaktion i. A. des Rektorats

• Hostbasiert: http://NAME.uni-muenster.de/ usw.

  • Es gelten (nur) die allgemeinen Regeln für Rechnernamen in der WWU

• Domainbasiert: http://www.NAME.TLD/ usw.

  • Es gelten die einschlägigen Gesetze und dienstrechtlichen Vorschriften

Organisatorisches: Webspace einrichten

• Nutzergruppe muss bereits eingerichtet sein

• Alles weitere läuft auf Zuruf per Telefon oder E-Mail

  1. Vereinbarung der URL

  2. Einrichtung des Webspaces (Plattenplatz, Backend- und Frontend-Server)

  3. Weitere Wünsche, z. B. MySQL-Datenbank, Software usw.

  4. Plattenplatzquote (anfänglich 1 GB) erhöhen

• Bitte lassen Sie sich durch uns beraten!

• Schon vielen Nutzern haben wir viele unnötige Arbeit ersparen können.

Struktur: http://www.uni-muenster.de/NAME/ als Webspace (1)

• Zugreifbar unter mehreren Webadressen:

  • http://www.uni-muenster.de/NAME/ – ungeschützt

  • http://www.wwu.de/NAME/ – für Visitenkarten, Veröffentlichungen

  • https://www.uni-muenster.de/NAME/ – abhörsicher

  • https://sso.uni-muenster.de/NAME/ – Single Sign-On (Passwort)

  • https://xsso.uni-muenster.de/NAME/ – Single Sign-On (Zertifikat)

  • https://ssso.uni-muenster.de/NAME/ – Single Sign-On (Shibboleth)

Struktur: http://www.uni-muenster.de/NAME/ als Webspace (2)

• Frontends agieren als Reverse Proxy mit Lastverteilung auf verschiedene zivwebNN:

  http://www.uni-muenster.de/NAME/
  http://www.wwu.de/NAME/
  ⇒ http://zivwebNN.uni-muenster.de:1NNNN/NAME/
  

  https://www.uni-muenster.de/NAME/
  ⇒ https://zivwebNN.uni-muenster.de:2NNNN/NAME/

  https://sso.uni-muenster.de/NAME/
  https://xsso.uni-muenster.de/NAME/
  https://ssso.uni-muenster.de/NAME/
  ⇒ https://zivwebNN.uni-muenster.de:3NNNN/NAME/

  Jeder Infoanbieter hat ein eigenes NNNN auf mehreren zivwebNN

Struktur: Andere URLs und Realisierungen (1)

• NAME.uni-muenster.de oder www.NAME.TLD als Webspace

  • Kein Imperia

  • Kein Single Sign-On

  • HTTPS nur in Ausnahmefällen (extra IP-Adresse+Zertifikat)

  • www.NAME.TLD kostenpflichtig und unerwünscht (Corporate Identity)

  • Verzeichnisbaum /www/data/NAME/ – daher nur falls keine Kollision

• Redirects (Umleitungen) und Reverse Proxys

  • uni-muenster.de/NAME ⇒ irgendwas

  • NAME.uni-muenster.de ⇒ irgendwas

  • www.NAME.TLD ⇒ irgendwas (kostenpflichtig, aber als Umleitung erwünscht)

  • Pfade bleiben: www.NAME.TLD/ABC/DEF ⇒ irgendwas/ABC/DEF

Struktur: Andere URLs und Realisierungen (2)

• Gerne als Kombination

  • Redirect: http://NAME.uni-muenster.de/ ⇒ http://www.uni-muenster.de/NAME/

  • und/oder: http://www.NAME.TLD/ ⇒ http://www.uni-muenster.de/NAME/

  • Webspace: http://www.uni-muenster.de/NAME/

• vereinigt Vorteile beider Verfahren

• Nachteil nicht der Rede wert (uni-muenster-Adresse in Browser-Adresszeile)

Pflege: http://www.uni-muenster.de/NAME/ als Webspace (1)

• SSH: upload.uni-muenster.de:/www/data/NAME/
  Login als: username
  Authentifizierung mittels SSH-Public-Keys (über MeinZIV hochgeladen)

• SMB: \\upload.uni-muenster.de\www\NAME\
  Login als: uni-muenster\username
  Authentifizierung mittels Active Directory

• Verzeichnisbaum:
  /www/data/NAME/ – Wurzelverzeichnis, nur für Infoanbietergruppe zugreifbar
  /www/data/NAME/htdocs/ – »Document Root« (kaum nutzbar)
  /www/data/NAME/htdocs/NAME/ – alle angebotenen Inhalte
  /www/data/NAME/imperialive/NAME/ – (R/O) per Imperia freigeschaltete Inhalte
  /www/data/NAME/home/USER/ – Unix-Homeverzeichnis (.bashrc, SSH-Schlüssel)
  /www/data/NAME/XYZ/ – frei für Installations- und Arbeitsdateien
  /www/data/NAME/sessions/ – empfohlen für Sitzungsdateien (nicht /tmp/ verwenden!)
  /www/data/NAME.logs/ – Error-Logdateien (live; nicht in Diskquota)

Pflege: http://www.uni-muenster.de/NAME/ als Webspace (2)

• Imperia: https://imperia.uni-muenster.de/imperia/
  Login als: username
  Authentifizierung mittels zentralem Passwort

• Nur bei gemischten Webspaces (teils mit Imperia, teils manuell gepflegt):

  • Zwei Verzeichnisbäume:
    /www/data/NAME/htdocs/NAME/ – manuell gepflegte Inhalte
    /www/data/NAME/imperialive/NAME/ – mit Imperia gepflegte Inhalte

  • Der Webserver liefert nur /www/data/NAME/htdocs/NAME/ aus

  • Einbindung von mit Imperia gepflegten Bereichen (Dateien, Verzeichnisbäume):
    ln -sfn /www/data/NAME/imperialive/NAME/BEREICH /www/data/NAME/htdocs/NAME/BEREICH

  • neuerdings automatisch, nur falls /www/data/NAME/htdocs/NAME/BEREICH noch nicht existiert

Pflege: Dateisystem-Zugriffsrechte

• Alle Dateien: R/W by Owner, R/W by Group, R/O by Other!

• Sonst kann der Apache nicht zugreifen
  (dieser läuft teils als User=apache, teils als User=XinfoXX)

• Das Wurzelverzeichnis verhindert unbefugte Zugriffe:
  Owner=apache, Group=X0infoXX, Mode=dr-xrws---

• Zugriffsrechte werden bei Schreibzugriff via SMB erzwungen, bei SSH leider nicht

• Notfalls reparieren: /www/bin/repairwebspace NAME (oder mit MeinZIV)

• Innerhalb eines Webspaces keine Rechte-Differenzierung!

• Schreibzugriff hängt an Mitgliedschaft in Nutzergruppe

Pflege: SSH

• upload.uni-muenster.de (nur mit Public-Key-Authentifizierung)

• Public Key wird mit MeinZIV auf Server abgelegt

  • Unix-Home (mit .bashrc, .ssh/authorized_keys) liegt im Webspace

  • Nicht als persönliche Ablage gedacht!

• Nach einmaliger Überwindung der Einstiegshürde genauso simpel bedienbar wie übliche FTP-Software

• Linux/Mac-Software: OpenSSH (ssh, scp usw.)

• Windows-Software 1: PuTTY plus Filezilla

• Windows-Software 2: SSH Secure Shell Client

• oder jede andere SSH-Software

• Ausführliche Anleitungen für obige Programme im WWW

• Demo: SSH-Zugang mit PuTTY+Filezilla einrichten

Pflege: SMB (Netzwerklaufwerke)

• \\upload.uni-muenster.de\www (entspricht /www/data/)

• Anmelden als uni-muenster\username

• Erzwingt automatisch richtige Dateisystemzugriffsrechte

• Dafür keine Kommandozeile und keine Symlinks

• Achtung bei Steuerdateien .htaccess usw.: CR+LF ⇒ LF umwandeln!

• Nur aus dem lokalen Netz (oder mit VPN)

• Deshalb vielleicht doch besser SSH verwenden? Sie haben die Wahl.

Pflege: Sicherungskopien, Statistiken

• Zugriff auf TSM-Backup (nur per SSH):

  • restore [-inactive] [-pick] dateiname [neuerdateiname]

  • (nicht „dsmc restore“, das erspart LC_ALL=..., -errorlogname=..., -asnode=zivweb)

• Zugriff auf statistische Log-Auswertungen (AWstats):

  • https://sso.uni-muenster.de/NAME/sys-log/ (verzeichnisbasiert)

  • https://NAME.uni-muenster.de/NAME/sys-log/ (hostbasiert, nur falls mit SSL)

  • https://www.NAME.TLD/NAME.TLD/sys-log/ (domainbasiert, nur falls mit SSL)

  • Nur mit einigen Tagen bis Wochen Verzögerung verfügbar

  • Die Auswertung der Logfiles von 3 Tagen dauert über 8 Stunden!

• Anonymisierung erfolgt vor Logfileanalyse, daher nicht alle Angaben sinnvoll

Steuerung: Eigene Einstellungen (1)

• Steuerdateien:

  • .htaccess für http://www.uni-muenster.de

  • .htsslaccess für https://www.uni-muenster.de

  • .htssoaccess für https://sso.uni-muenster.de (u. a. SSO-Zugänge)

  • .htaccess.imperia für https://imperia.uni-muenster.de

    (Imperia-Vorschau, beschränkte Einstellmöglichkeiten)

• Fallback, falls Datei nicht existiert: .htssoaccess ⇒ .htsslaccess ⇒ .htaccess

• Unix-Zeilenenden (LF), keine Windows-Zeilenenden (CR+LF)

Steuerung: Eigene Einstellungen (2)

• WWW-Zugriffsrechte (s. u.)

• Eigene Umleitungen

• Dateinamen von Titelseiten

• Eigene Fehlermeldungsseiten

• Server Side Includes (welche Dateien werden ge-parse-t?)

• Zuordnungen

  • Dateiendungen – MIME-Typen

  • Dateiendungen – Apache-Handler (CGI, PHP, As-is, ...)

    Beispiel: AddHandler cgi-script pl

• u. v. a. m.

Steuerung: WWW-Zugriffsrechte

• Nicht zu verwechseln mit Dateisystem-Zugriffsrechten

• Verschiedene Alternativen siehe im WWW

• Von Zugangskontrolle per IP-Adresse wird abgeraten

  • funktioniert wegen Reverse Proxy auch anders als üblich

• Zugangskontrolle per Identitätsnachweis, allgemeiner Fall:

  • http://www.uni-muenster.de/NAME/ABC/
    Kein Zugang, Umleiten zu SSO

  • https://www.uni-muenster.de/NAME/ABC/
    Zugang für Gäste mit manuell vergebenem Gastpasswort
    (Auch für Vorlesungsskript-Passwörter o.ä.)

  • https://sso.uni-muenster.de/NAME/ABC/
    https://xsso.uni-muenster.de/NAME/ABC/ usw.
    Zugang mit ZIV-Nutzerkennung und Passwort/Zertifikat/usw.

  • Verteilung mit offener Vorschaltseite (unnötig falls nur ZIV-Nutzer oder nur Gäste)

Steuerung: WWW-Zugriffsrechte: Allgemeiner Fall (1)

• Datei .htaccess

  RedirectPermanent / https://www.uni-muenster.de/

• Hier steckt die Umschaltung auf »Login erforderlich«

• Datei .htsslaccess

  AuthName "Nur fuer eingeladene Gaeste"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /www/data/NAME/gastzugaenge
  Require valid-user

• /www/data/NAME/gastzugaenge enthält manuell vergebene Nutzer und Passwörter

• Require valid-user nur mit eigenen, niemals mit Systemdateien verwenden!

Steuerung: WWW-Zugriffsrechte: Allgemeiner Fall (2)

• Datei .htssoaccess

  AuthName "Nur fuer zweifelsfrei der WWU Angehoerige"
  AuthTypeBasic
  AuthBasicProvider dbm
  AuthDBMUserFile /www/data/usersso
  AuthDBMGroupFile /www/data/groups
  Require group user1 user2 ... group1 group2 ... rolle1 rolle2 ...

• Nur Require group, niemals Require user oder Require valid-user verwenden!

• Bei Verwendung der Datei /www/data/groups ist der Nutzer perske Mitglied

  • der Gruppe perske (diese Gruppe enthält nur diesen Nutzer)

  • der Gruppen u0mitarb, u0zivmit usw. (Gruppen aus der Nutzerverwaltung)

  • der Gruppen an=uni=sicher, an=uni=unsicher, sys=ras-wwu usw.
    (aus verschiedenen Quellen abgeleitete Rollen und Gruppen)

• Externe Nutzer hans@uni-wurst.de sind automatisch in hans@uni-wurst.de und @uni-wurst.de,
  dazu evtl. in @staff@uni-wurst.de, @student@uni-wurst.de usw. (https://ssso ist Teil der DFN-AAI)

Steuerung: WWW-Zugriffsrechte: Pseudo-Gruppen

• Ausschließlich für WWW-Autorisierung verfügbar

• Nicht in WWU-Benutzerverwaltung, sondern algorithmisch hergeleitet:
  an=uni=sicher zweifelsfrei der WWU Angehörige*
  an=uni=unsicher wahrscheinlich der WWU Angehörige
  an=uni=ukm=unsicher wahrscheinlich der WWU oder dem UKM Angehörige
  an=uni=stud Student(in)*
  an=uni=mitarb wiss. oder nichtwiss. Mitarbeiter(in)*
  an=uni=whk, an=uni=shk wiss. bzw. stud. Hilfskraft*
  an=uni=lehr, an=uni=emerit Lehrbeauftragte(r)* bzw. Emeritus/a*
  sys=aix-urz Zugang zu den zentralen Mailservern
  sys=pc-urz Zugang zu den PC-Pools (Domäne uni-muenster)
  sys=ad-wwu Zugang zu den PC-Pools (Domäne wwu)
  sys=cms-imperia Zugang zu Imperia
  sys=ras-wwu Zugang zu den Einwahlzugängen
  sys=intro-wwu Darf Intro-Karte bekommen
  any=p0, any=q0, any=r0 Mitglied einer Nutzer p0..., q0..., r0...
  usw. (* = laut Verwaltungsdaten)

• Weitere (Pseudo-) Gruppen bei Bedarf – Fragen Sie uns!

Steuerung: Pseudo-Cron-Jobs

• Schutz gegen Amok: Keine normalen Cron-Jobs

• Daily-Skripte

  • /www/data/NAME/cron/daily

  • wird täglich kurz nach 3 Uhr aufgerufen

• Häufigere Aktionen

  • /www/data/NAME/cron/XYZ.loop

  • Skripte werden alle 5 Minuten ausgeführt

  • Aber nur, wenn seit mehr als 5 Minuten beendet

  • ⇒ nicht mehrere gleichzeitig, maximal alle 10 Minuten

  • Für seltenere Ausführung: Am Ende: sleep $((NNN-600))

    stündlich: sleep 3000; zweistündlich: sleep 6600

Inhalte: Verweise in WWW-Seiten

• In verzeichnisbasierten Webspaces (www.uni-muenster.de/NAME/)

  wegen der verschiedenen URLs:

  niemals: <a href="http://www.uni-muenster.de/AAA/BBB/CCC">
  sondern: <a href="/AAA/BBB/CCC">

  niemals: <img src="http://www.uni-muenster.de/AAA/BBB/CCC">
  sondern: <img src="/AAA/BBB/CCC">

  niemals: <a href="https://sso.uni-muenster.de/perMail">
  sondern: <a href="/perMail/"> (mit Schrägstrich!)

  schreiben!

• Dann funktionieren Links, Bilder und Medien auch mit HTTPS und Single Sign-On

  (Kein Secure-Insecure-Mix oder Wechsel der Authentifizierungsmethode mehr)

Inhalte: Eigene Programme und Skripte (1)

• Apache-Handler

  • *.php wird mit PHP-Interpreter ausgeführt (zzt. PHP 5.3)

  • *.cgi wird als CGI-Program ausgeführt (bei Skripten: #!-Zeile nötig)

  • Ausführen von *.pl als Perl-Programm:

    • Erste Zeile: #!/usr/bin/perl (mit LF, nicht CR+LF!)

    • AddHandler cgi-script pl (in .htaccess & Co.)

• Anfragen werden willkürlich auf Server verteilt

  • Gemeinsames Dateiesystem /www/data/

  • Sitzungsdaten daher nicht in /tmp/

  • PHP: ini_set('session.save_path','/www/data/NAME/sessions');

Inhalte: Eigene Programme und Skripte (2)

• E-Mail-Versand: Envelope-Absender angeben!

  • PHP: mail($to,$subj,$msg,'','-f user@uni-muenster.de')

• Login-Username (auch Single Sign-On)

  • PHP: $_SERVER['REDIRECT_REMOTE_USER']
    (bei High-Performance-Webspace: $_SERVER['REMOTE_USER'])

  • andere: Umgebungsvariable REMOTE_USER

  • Abgesprochene Attribute in Umgebungsvariable HTTP_X_TRUSTED_REMOTE_ATTR

• Eigene Kontrolle auf Zugehörigkeit zu (Pseudo-) Gruppe:

  • PHP: require_once('/www/data/groups.php');
    if(is_array($groups)) if(is_array($groups[$user])) if(in_array($grp,$groups[$user])) {...}

  • andere: /www/data/groups.txt lesen

  • DFN-AAI-Infos stehen nicht dort, sondern in Umgebungsvariable HTTP_X_TRUSTED_REMOTE_ROLE

Inhalte: Notfallvorsorge

• Bei erheblichen Problemen wird auf das Notfallsystem umgeschaltet

• Inhalte (mit Ausnahmen) werden täglich synchronisiert

• Dort laufen keine Skripte oder Handler (PHP, CGI), wohl aber Server Side Includes

• Bei Zugriff auf Skripte: ErrSOS.html; falls andere Seite erwünscht:

  • Zu Datei XYZ.php eine Notfalldatei XYZ.php-sos.html anlegen.

  • Zu Datei XYZ.cgi eine Notfalldatei XYZ.cgi-sos.html anlegen.

  • Beliebiger HTML-Inhalt nach Wahl (aber kein Server Side Include)

  • Notfallsystem schaut bei Skripten nach solchen Notfalldateien

• Kein Support für eigene Content-Management-Systeme!

  • Systeme, die statische (ohne Skript abrufbare) Seiten produzieren, sind klar im Vorteil

  • Bei dynamischen Systemen: Bitte an Notfalldateien denken