OS Contentmanagement mit Plone/Zope: Dokumentation Webserver-Integration

Transkript

1 OS Contentmanagement mit Plone/Zope: Dokumentation Webserver-Integration Anton Herzfeld, Matthias Grefe Leipzig der 11. Februar 2011 Inhaltsverzeichnis 1 Webserver allgemein 2 2 Voraussetzung für die Integration von Plone/Zope Virtual Hosts Virtual Host Rewrite Rule Virtual Hosts Konfiguration in Plone/Zope Der NginX-Server Installation und Konfiguration NgniX Virtual-Host Konfiguration Der Apache-HTTPd-Server Installation und Konfiguration Virtual-Host-Konfiguration Zusammenfassung 11 Anton Herzfeld, Matthias Grefe, 2010/2011 1

2 1 Webserver allgemein Ein Webserver ist eine Software welche zur Annahme und Verarbeitung von Anfragen über das HTTP bzw. das HTTPs Protokoll dient. Diese Protokolle laufen im Allgemeinen auf den Ports 80 (http) sowie Port 443 (HTTPs). Der Webserver erstellt benutzerdefinierte Antworten und leitet diese zum anfragenden Client weiter. Die Antworten können z.b. folgende Inhalte sein: Statische Dokumente (z.b.: HTML-, Bild-, Audio-, Video-, PHP- oder Javadateien) Dynamische Inhalte (z.b.: Web- und Datenbankanwendungen) Aufgrund der Vielzahl der verschiedenen Webserver fällt die Auswahl auf die Bedürfnisse des Kunden zurück. Dabei ist die Performance der Webserver ein entscheidender Faktor bei der Auswahl des passenden Webservers. In Abbildung 1 werden verschiedene Features für die Auswahl eines geeigneten Webserver aufgezeigt. Bei der Wahl Abbildung 1: Kurzübersicht der am Markt am häufigsten vorkommenden Webserver. des richtigen Webservers spielen vor Allem Aspekte, wie Open-Source, die angebotenen Features sowie die angebotenen Plattformen eine bedeutende Rolle. Innerhalb dieser Dokumentation wird genauer auf den Webserver Apache2 sowie NgniX eingegangen. Apache 2 als einer der am meisten genutzten Webserver sowie NginX als Anton Herzfeld, Matthias Grefe, 2010/2011 2

3 Performance Vorreiter dienen zur Veranschaulichung für die Integration von Plone/Zope in eine Serverarchitektur. 2 Voraussetzung für die Integration von Plone/Zope Für die Integration eines bestehenden Plone/Zope Systems in eine Webserverarchitektur müssen beide Systeme einige Voraussetzungen erfüllen. Der Webserver muss in der Lage sein Virtual Hosts verwalten zu können, sowie Rewrite Rule Module zu unterstützen. Bei einigen Webservern müssen diese Module während des Kompilierens bereits gesetzt sein um diese später nutzen zu können. Plone/Zope muss wiederrum mit diesen Rewrite Rules des Virtual Hostings umgehen können, dazu muss die Zope Instanz das Virtual Host Monster unterstützen (in neueren Versionen z.b. Plone 4.0 ist dieses bereits aktiviert). 2.1 Virtual Hosts Ein Virtual Host ist im Prinzip eine Weiterleitung des HTTP Servers auf einen anderen Pfad, IP oder Server. Dabei wird der Webserver als Proxyserver umfunktioniert und über den Virtual Host werden Anfragen modifiziert und an Zope weitergeleitet. Für den Client entsteht jedoch der Eindruck das der Webserver selbst diese Anfragen verarbeitet. Der Client bemerkt an dieser Weiterleitung demnach nichts. Im Webserver wird dabei der HTTP Port 80 an die Plone/Zope Instanz welche z.b. auf Port 8080 läuft weitergeleitet. Innerhalb des Webserver wird dabei ein Virtual Host für eben diese Weiterleitung definiert. Die Virtual Host Architektur lässt sich anhand Abbildung 2 erklären. Eine Anfrage wird zuerst über den Port identifiziert und anschließend über die Adresse an den zugewiesen Server und Port geleitet. Über den Servernamen wird der Server dann genauer spezifiziert. Das Virtual Hosting ermöglicht es so über Adresse und Port den Webserver anzusprechen über den angeforderten Servernamen wird jedoch der virtuelle Server gesucht. Wird dieser innerhalb der Virtual Host Konfiguration gefunden, so wird die Restlich Server Konfiguration geladen und der Virtual Host ist aktiv. Wird der virtuelle Server Name nicht gefunden, so wird dieser nach regulären Ausdrücken überprüft und gegeben falls die restliche Server Konfiguration geladen. Wird der virtuelle Server Name gar nicht gefunden so kann die Anfrage nicht beantwortet werden. Anton Herzfeld, Matthias Grefe, 2010/2011 3

4 Abbildung 2: Die Virtual Host Architektur Quelle: Virtual Host Rewrite Rule Die Rewrite Rule beschreibt den Vorgang der Weiterleitung genauer und wird bei einer Anfrage des Client auf den definierten Virtual Host ausgeführt. Im Folgenden wird veranschaulicht, wie die Rewrite-Rule zu verstehen ist. VirtualHostRoot// Beschreibt den Server, auf welchen die Anfragen weitergeleitet werden sollen VirtualHostBase http Zeigt Zope Server an, dass Virtuelles Hosting aktiv ist. Wichtig: Es darf keine Plone Seite mit diesem Namen erstellt werden beschreibt das Protokoll welches genutzt werden soll Beschreibt die im Webbrowser angeforderte Webseite Virtual Host Root Gibt das Wurzelverzeichnis des virtuellen Hosts an. Alle Einträge danach werden in die neu erzeugte URL übernommen Anton Herzfeld, Matthias Grefe, 2010/2011 4

5 2.3 Virtual Hosts Konfiguration in Plone/Zope Für ältere Plone/Zope Installationen ist es notwendig ein Virtual Host Monster zu erstellen. Bei Plone 4.0 ist dieser Schritt nicht mehr notwendig. Das Virtual Host Monster kann über das ZMI (Zope Management Interface) hinzugefügt werden. Das Hinzufügen des Objektes reicht bereits aus damit der Zope Server mit Virtual Host Anfragen umgehen kann. Das VHM Objekt fängt alle eingehenden Anfragen ab und übersetzt diese in Zope konforme URLs. Dabei ist zu beachten, dass ein Eintrag nach VirtualHostBase der ursprüngliche Browseraufruf ist und dabei durch Nutzung des VirtualHostRoot in eine komplette Plone URL umgewandelt wird. Anton Herzfeld, Matthias Grefe, 2010/2011 5

6 3 Der NginX-Server NginX ist ein modularer Webserver ähnlich dem Apache HTTP Server. Durch seine Modularität ist er sehr vielfältig und ressourcenschonend. Insbesondere hervorzuheben ist das Load Balancing welche dem NginX die nötige Performanz verschafft. Weitere Features sind: Flash Video Streaming SSL Als Proxy Cache nutzbar IMAP/POP3 Proxy Server NginX wird aufgrund seiner Module und seiner Performanz verbreitet genutzt, sein Marktanteil ist jedoch noch weiter unter dem des Apache HTTP Servers 3.1 Installation und Konfiguration NgniX Die Installation auf Ubuntu/Debian Systemen mittels Advanced Packaging Tool findet durch folgenden Aufruf statt: sudo apt get i n s t a l l nginx Die Installation aus Quell Code setzt die nötigen Develop Bibliotheken vorraus: z l i b devel wget openssl devel pcre pcre devel sudo gcc make\ autoconf automake Danach folgt die Installation über die folgenden Befehle:. / c o n f i g u r e [ add module=/path / to /module1/ source ] o p t i o n a l make make i n s t a l l Die Standard NginX Installation sowie Konfiguration befindet sich unter: / usr / l o c a l / nginx Zum Starten des NginX Webserver Daemons: / e t c / i n i t. d/ nginx s t a r t Nach der Änderung an Konfigurationsdateien des NginX können folgende Befehle ausgeführt werden um den Daemon neu zu starten und somit die Änderungen zu übernehmen: Anton Herzfeld, Matthias Grefe, 2010/2011 6

7 / e t c / i n i t. d/ nginx r e s t a r t ODER / e t c / i n i t. d/ nginx k r e c o n f i g u r e 3.2 Virtual-Host Konfiguration Zuerst sollte ein Backend erstellt werden. Das Backend dient zur Vereinfachung der Konfiguration sowie für einen geringeren Wartungsaufwand bei Änderungen des Zope Server Systems. Innerhalb der backends.conf sollten folgende Einträge vorgenommen werden. /etc/nginx/conf.d/backends.conf ODER /usr/local/nginx/conf/backends.conf upstream zope_backend{ s e r v e r l o c a l h o s t : ; } zope_backend dient als Variable für das Backend und kann beliebig definiert werden server localhost:8080 gibt dabei das Zope Backend an und definiert IP und Port des Zielservers /etc/nginx/sites-enabled/zope.conf s e r v e r { } l i s t e n 8 0 ; server_name l o c a l h o s t l o c a t i o n /{ proxy_pass http : / / zope_backend/ VirtualHostBase \ / http / l o c a l h o s t :80/ hosts / l o c a l h o s t \ / VirtualHostRoot / ; } Der Ordner sites-enabled zeigt der NginX Standard Konfiguration an welche weiteren Virtuellen Hosts aktiv sind. Innerhalb dieses Ordners werden alle Konfigurationsdateien beim Start des NginX Daemons geladen. Der Name zope.conf ist ein Beispiel und kann beliebig definiert werden. Innerhalb der zope.conf wird der Virtuelle Server definiert. Anton Herzfeld, Matthias Grefe, 2010/2011 7

8 server zeigt den Beginn der Konfiguration des virtuellen Servers listen 80 gibt den Port des Abhörens an. Der Server wartet auf diesem Port auf Anfragen server_name localhost definiert den Servernamen hierbei sollte der Servername mit dem eventuellen DNS Eintrag übereinstimmen. Um auch auf externe Anfragen korrekt Antworten zu können location / gibt den Pfad nach dem Servernamen an ab welchem wohin weitergeleitet werden soll. Location spannt eine Unterkonfiguration auf und beschreibt die zu nutzenden Regeln proxy_pass definiert die Weiterleitung, dabei dient der Webserver nur noch als Proxyserver und leitet die Anfragen weiter anstatt sie selbst zu bearbeiten enthält das vorher definierte Backend und dient zur Weiterleitung auf den im Backend definierten virtuellen Server. Durch die Definition des Backends ist besonders bei vielen Location und proxy_pass Regeln die Wartungsarbeit minimiert da nur noch das Backend geändert werden muss und nicht jeder einzelne Eintrag innerhalb der zope.conf Anton Herzfeld, Matthias Grefe, 2010/2011 8

9 4 Der Apache-HTTPd-Server Mit über ca. 60 Prozent Marktanteil ist der Apache-HTTPd-Server der am weitesten verbreitete Webserver derzeit. Dieser wurde auf Basis des NCSA-HTTPd-Webservers, einer der ersten Webserver überhaupt, entwickelt. Im Jahre 1995 wurde das erste Release des Apache-HTTPd veröffentlicht und bereits 1996 war es der meistgenutzte Server. Neben der weiten Verbreitung, der dadurch auch sehr umfangreichen und guten Dokumentation, ist die Unterstützung unterschiedlichster Plattformen gegeben. Dazu zählen die gängigen Betriebssysteme wie Windows, Mac OSX, Linux aber auch nicht so bekannte Plattformen wie das BSD, Solaris oder OS2 und weitere. Der Apache-HTTPd ist modular aufgebaut und ist somit in seiner Funktionalität erweiterbar. Weiterhin werden verschiedenste serverseitige Skriptsprachen wie bspw. PHP, Perl oder Python für die Anzeige dynamischer Inhalte unterstützt. Im Folgenden wird gezeigt wie der Apache-HTTPd-Server installiert und konfiguriert wird. 4.1 Installation und Konfiguration Für die Installation ist die Entscheidung zu treffen, ob der Server von Hand kompiliert oder mit dem Advanced Packaging Tool einfach nur installiert werden soll. Für die erste Variante stehen mehr Optionen zur Konfiguration zur Verfügung, die zweite geht einfacher vonstatten. Mit den Aufrufen:. / c o n f i g u r e p r e f i x =/usr / l o c a l / apache2 enable r e w r i t e make make i n s t a l l ist die komplette Installation des Servers erledigt. Hierbei ist anzumerken, dass die langen Striche eigentlich doppelten Bindestrichen entsprechen. Mit dem ersten Aufruf erfolgt die Konfiguration des Codebaumes unter Verwendung eines für die weiteren Erklärungen notwendigen Modules, dem mod_rewrite. Dieses wird hierdurch statisch eingebunden und muss in weiteren Schritten nicht zusätzlich integriert werden, wie das bei der dynamischen (nachträglichen) Einbindung von Modulen der Fall ist. Die Wert der weiteren angegebenen Option prefix stellt den Installationspfad des Apache-Servers dar, welcher in diesem Beispiel in /usr/local/apache2 untergebracht wird. Mit make wird der Quellcode kompiliert und mit make install schlussendlich installiert. Die einfache Installation findet über den Aufruf Anton Herzfeld, Matthias Grefe, 2010/2011 9

10 apt get i n s t a l l apache2 statt. Nach der Installation kann der Server über die Kommandos:. / a p a c h e c t l s t a r t. / a p a c h e c t l stop. / a p a c h e c t l r e s t a r t im Apache Verzeichnis /usr/local/apache2/bin/ gestartet, gestoppt oder neugestartet werden. Wie dieser gerade installierte Webserver für die Auslieferung einer Plone/Zope-Instanz vorbereitet und konfiguriert wird, zeigt der nächste Abschnitt. 4.2 Virtual-Host-Konfiguration Die zentrale Konfigurationsdatei ist die httpd.conf. Diese befindet sich im Verzeichnis [Apacheroot]/conf. Hier werden die unterschiedlichen Konfigurationen, wie etwa das dynamische Einbinden zusätzlicher Module, der Port auf dem der Server lauscht und der Virtual-Host eingerichtet. Mit dem Eintrag: <VirtualHost > ServerName http : / / l o c a l h o s t / RewriteEngine On RewriteRule ^ / (. ) http : / / l o c a l h o s t :8080\ / VirtualHostBase / http/%{server_name}:80/ $1 [P] </VirtualHost > wird dieser eingerichtet, um auf die Plone-Instanz umzuleiten. Die Deklarationen bedeuten im Einzelnen: VirtualHost * leitet die Deklaration des Virtual-Hosts innerhalb der httpd.conf-datei ein. ServerName definiert den Servernamen. Dabei sollte der Servername mit dem eventuellen DNS Eintrag übereinstimmen, um auch auf externe Anfragen korrekt Antworten zu können. RewriteEngine On aktiviert die Umleitung durch das Module mod_rewrite RewriteRule ˆ/(.*) entspricht einem regulären Ausdruck, der alles (.*) nach dem Domainnamen abfängt. Anton Herzfeld, Matthias Grefe, 2010/

11 entspricht der Ziel-URL der Umleitung. Alle Anfragen werden auf diese Adresse umgeleitet. /VirtualHostBase/http/%SERVER_NAME:80/$1 Diese Deklaration wird vom VirtualHostMonster von Zope verwendet um die angforderten Seiten in eine Plone-URL umzusetzen. Dabei bedeutet speziell das $1, dass die Worte, die dem regulären Ausdruck entsprechen zum Aufruf einer speziellen Seite von Plone führen. 5 Zusammenfassung Insgesamt hat sich gezeigt, dass die Einbindung von Plone/Zope unkompliziert abläuft. Es müssen lediglich die bereitgestellten Funktionen des jeweiligen Webservers erfasst werden, die für dieses Anwendungsziel notwendig sind. Dies lässt sich, wie diese Dokumentation zeigt, auf zwei wesentliche Bestandteile herunterbrechen: auf Virtual Hosts und auf die Rewrite Rule Sind diese eingerichtet ist auf der Server-Seite bezüglich dieses einfachen Beispiels nichts zusätzlich zu tun. In Plone/Zope selbst ist, wenn man es genau betrachtet, nichts einzurichten, denn seit Version 4 ist das Virtual Host Monster von vornherein vorhanden. In den früheren Versionen musste dieses über das Zope-Management-Interface explizit hinzugefügt werden. Anton Herzfeld, Matthias Grefe, 2010/