Webserver/W3C-Validator lokal installieren

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche
Hinweis:
Dieser Artikel ist eine Textübertragung aus dem aktuell.de.selfHTML-Bereich. Seine Inhalte sind möglicherweise veraltet.
  • zuerst erschienen: 07.06.2004,
  • letzte Aktualisierung: 08.10.2007

Motivation

Warum schreibe ich diesen Artikel? Nun, eigentlich ganz einfach: Seit ein paar Jahren beschäftige ich mich mit HTML. Anfangs war es mehr ein "Schau mal, wie toll" und zum Teil JavaScript-Klickbunti-Zeug, das herauskam. Doch mit der Zeit wandelten sich meine Ansichten bezüglich einer guten Website. So sehe ich nun unter anderem validen Quelltext als selbstverständlich an. Unverzichtbar für die Überprüfung ist dabei ein Validator, wie beispielsweise der Validator des W3C oder Validome. Schnell lernte ich den W3C-Validator zu bedienen und lieben. Doch aufgrund meines Umzugs habe ich jetzt zu Hause kein Internet mehr. Jedes Mal, wenn eine Seite wieder gewachsen war alles mit in die Uni zu schleppen, dort übers Netz zu validieren und letztendlich die Daten auch wieder mit nach Hause zu schleppen ist doch recht unpraktikabel.

Irgendwann stieß ich dann auch einmal darauf, dass man sich den Validator lokal installieren kann. "Hey, das klingt ja prima", dachte ich mir. So lud ich mir die Dateien herunter und versuchte ihn bei mir zum Laufen zu bekommen. Doch es war ein großer K(r)ampf, immer funktionierte etwas nicht, zeitweise wurde mir bei jeder Seite gesagt sie sei nicht valide (ohne Näheres zum DocType zu sagen), obwohl sie 100% korrekt war.

Also durchsuchte ich das Netz nach Anleitungen, fand aber nur die von Björn Höhrmann, die aber leider schon längere Zeit nicht mehr aktuell ist. So suchte ich weiter, fand einige minimale Tipps.

Anhand derer habe ich es doch geschafft, den Validator bei mir richtig zum Laufen zu bekommen. In diesem Artikel möchte ich allen Interessierten meine Schritte aufschreiben und ihnen so Gleiches ermöglichen.

Anmerkung: Mittlerweile gibt es mehrere Anleitungen, sodass die Installation kein großes Problem mehr sein sollte.

Benötigte Programme

Damit der Validator läuft benötigt man natürlich erst einmal einen Webserver. Ich selbst habe auf meinem PC einen Apache in der Version 2.2.2 in Betrieb. Die Erklärung bezieht sich auch auf diese Version. Auf seine Installation und grundlegende Konfiguration gehe ich hier nicht ein. Jedoch empfehle ich den Artikel erst einmal komplett zu lesen um die Verzeichnisstruktur zu überblicken und kein wildes "Drauf-los-Installieren" zu beginnen.

Das Validator-Script selbst ist in Perl geschrieben. Zum Parsen des Scriptes verwende ich bei mir ActivePerl 5.8. Dank eines Installers ist die Installation auch hier nicht schwer. In dieser Version des Validators soll angeblich auch das Apache-Modul "mod_perl" anstelle von ActivePerl als Perl-Interpreter einsetzbar sein. Dies habe ich jedoch (noch) nicht getestet und kann daher keine Installationshilfe geben.

Dann wird natürlich der Validator selbst benötigt. Als tar-Archiv gepackt kann man ihn sich unter http://validator.w3.org/validator.tar.gz (~300KB) herunterladen. Aktuell ist Version 0.8.

Neben dem Validator wird natürlich auch eine Sammlung von DTDs benötigt. Diese ist z. B. unter http://validator.w3.org/sgml-lib.tar.gz (~3MB) zu bekommen.

Der Validator benötigt einige Perl-Module. Unter [ http://ppm.activestate.com/ activestate.com] befindet sich eine Liste aller verfügbaren Module. Ebenso kann man dort erfahren ob ein Modul "Core" (also standardmäßig mitgeliefert) ist oder ob es gezippt zum Download zur Verfügung steht. Ich benötigte die folgenden Module:

  • Class-Accessor
  • Config-General
  • Encode::HanExtra
  • Encode::JIS2K
  • HTML-Encoding
  • HTML-Template
  • HTML-Tidy
  • Net-IP
  • SGML-Parser-OpenSP
  • XML-LibXML
  • XML-NamespaceSupport
  • XML-SAX
  • XML-LibXML-Common

Man kann sie sich einzeln bei ActiveState herunterladen; ich habe sie aber auch fertig zur Installation in einem zip-Archiv zum Download bereitgestellt.

Als letztes ist wohl noch etwas Ruhe und Geduld erforderlich, ich brauchte auch einiges davon ;) Für eine komplette Installation des Validators (inklusive Apache und Perl) sollte man, wenn man wenig Erfahrung hat, ruhig eine Stunde einplanen.

Verzeichnisstruktur

Es sollte schon etwas überlegt werden, wie und wohin die einzelnen Programme installiert werden. Ein einfaches "Weiter"-Klicken in allen Installationsroutinen ist eher unschön. Auf meinem PC habe ich ein Verzeichnis C:\www, in dem alle Programme die etwas mit dem Server zu tun haben, installiert sind (natürlich in entsprechende Unterordner). So liegt der Apache in C:\www\Apache2, Perl in C:\www\perl, die DTD-Sammlung in C:\www\sgml-lib, der Validator selbst in C:\www\validator. Die Zusatzmodule für Perl sollten auch in ein eigenes Verzeichnis entpackt werden; bei mir ist dies C:\www\ppm. Im Folgenden gehe ich immer von den Pfaden meiner Installation aus.

Installation der Programme

Nun werden nacheinander die Programme installiert. Als erstes sollte der Apache installiert und zum Laufen gebracht werden. Wie schon erwähnt gehe ich darauf nicht näher ein; das Netz ist voll von Anleitungen. Zum Glück gibt es ja auch noch die Dokumentation zum Server. Einzig sei vielleicht erwähnt, dass bei der Installation automatisch ein Unterordner Apache2 eingefügt wird. Wählt man also als Installationsverzeichnis C:\www, so wird er tatsächlich nach C:\www\Apache2 installiert. Danach ist Perl an der Reihe, was ebenfalls kein Problem darstellen sollte. Das Generieren der HTML-Dokumentation kann einige Zeit in Anspruch nehmen, möchte man sich aber ein wenig mehr mit Perl beschäftigen, so ist sie durchaus hilfreich.

Die DTD-Sammlung liegt als zip-Archiv vor; sie muss also nur in den entsprechenden Ordner extrahiert werden. Gleiches gilt für den Validator selbst sowie, falls heruntergeladen, die Perl-Modulsammlung von mir. Zu beachten ist, dass das Archiv der DTD-Sammlung selbst noch einige Unterordner erstellt. Diese sind aber nicht unbedingt geeignet, also werden die Ordner verschoben. Der letzte Unterordner, der vom Archiv erstellt wird, heißt sgml-lib; er muss nach C:\www verschoben werden. Die anderen nun leeren Ordner können daraufhin gelöscht werden. Existiert nach dem Entpacken und Verschieben eine Datei sgml.soc im Verzeichnis C:\www\sgm-lib, so sind die DTDs am richtigen Ort.

Einbindung der Perl-Module

Seit Perl Perl 5.8.8 build 817.91 besitzt es eine GUI zur Paketverwaltung. Diese ist einfach zu bedienen; falls es doch Probleme geben sollte hilft ein Blick in die Dokumentation.

Module können mit dem Programm direkt aus dem Netz heruntergeladen und installiert werden. Möchte man sie jedoch aus einem lokalen Repository hinzufügen, so muss man PPM erst dafür konfigurieren (Falls dies nicht der Fall ist kann dieser Abschnitt übersprungen werden).

Neue Repositories werden über den Eigenschaften-Dialog (Edit -> Preferences -> Repositories) hinzugefügt. Nach einem Klick auf das Verzeichnissymbol erscheint eine Eingabemaske. Hier gibt man den Pfad C:\www\ppm an und vergibt dem Repository einen Namen (zum Beispiel "Lokal"). Dann klickt man auf "Add" und abschließend "OK".

Wenn man nun die ersten Buchstaben des gewünschten Moduls eingibt, so verkürzt sich die Liste und nur die relevanten Module werden angezeigt. Nachdem das Modul selektiert wurde kann man "Install" aus dem Kontextmenü wählen. Wenn dies für alle zu installierenden Module gemacht wurde können sie durch einen Klick auf den kleinen grünen Pfeil oben im Fenster installiert werden.

Im Statusfenster im unteren Bereich wird der Fortschritt und Erfolg jeder Installation angezeigt. Wenn alle Module installiert wurden kann PPM beendet werden.

Konfiguration des Apache

Als erstes wird die Konfiguration des Apache ergänzt. Alle Änderungen werden in der httpd.conf, der zentralen Konfigurationsdatei des Apache, gemacht. Ein leichtfertiges Herumspielen kann also schlimmstenfalls dazu führen, dass der Apache nicht mehr laufen will.

Die Validator-Seiten werden mittels SSI zusammengesetzt. Dafür muss der Apache als erstes einmal dieses Modul laden. In der "Section 1: Global Environment" werden die verschiedenen Module geladen. SSI verbirgt sich hinter "mod_include". Die Zeile

LoadModule include_module modules/mod_include.so

muss also auskommentiert (die Raute am Zeilenanfang entfernen) oder ergänzt werden, sofern das Modul nicht schon geladen wird.

Im Folgenden wird ein Virtual Host eingerichtet. Er dient dazu, dass der Validator in seinem zuvor angelegten Verzeichnis arbeiten und auch dort erreicht werden kann und logisch vom normalen Webserver getrennt ist. Dafür müssen nur die folgenden Zeilen an das Ende ("Section 3: Virtual Hosts") der httpd.conf kopiert werden:

Beispiel
NameVirtualHost 127.0.0.2:80 <VirtualHost 127.0.0.2:80> ServerName validator.david.tibbe DocumentRoot "C:/www/validator/htdocs" ErrorLog logs/error_validator.log CustomLog logs/access_validator.log common ScriptAlias /cgi-bin "C:/www/validator/httpd/cgi-bin" ScriptAlias /check "C:/www/validator/httpd/cgi-bin/check" AddType text/html .html AddOutputFilter INCLUDES .html <Directory "C:/www/validator/htdocs"> Options ExecCGI Includes Indexes MultiViews AllowOverride None Order deny,allow Allow from localhost </Directory> <Directory "C:/www/validator/httpd/cgi-bin"> Options ExecCGI Includes Indexes MultiViews AllowOverride None Order deny,allow Allow from localhost </Directory> </VirtualHost>

Ausführlich werde ich die einzelnen Zeilen nicht erklären, wen es interessiert, was dort gemacht wird, der kann ja einfach ins [ Manual des Apache schauen oder sich den Artikel von Christoph zur Serverkonfiguration ansehen. Nur so viel: In den ersten Zeilen wird der Name eingestellt, danach werden die Logfiles angegeben, danach Kurzbefehle für das eigentliche Validator-Script check und das cgi-bin angegeben. Danach wird gesagt, dass alle html-Dateien auf SSI geparst werden sollen. Als letztes werden noch Zugriffsrechte für Verzeichnisse gesetzt.

Die im Verzeichnis C:\www\Apache2\logs liegenden Log-Files für den Validator-Host, error_validator.log und access_validator.log, werden über alle auftretenden Fehler und alle Zugriffe Buch führen und bei Problemen wichtige Hinweise geben.

Nun muss der Apache noch neu gestartet werden, damit die Änderungen aktiv werden. Dies geht bequem über das Startmenü; in der Programmgruppe des Apache gibt es in der Untergruppe Control Apache Server den Punkt Restart. Nun sollte kurz eine Dos-Konsole erscheinen, nach ihrem Verschwinden ist der Apache fertig gestartet.

Wird nun im Browser http://127.0.0.2/ aufgerufen, so sollte die von Validator bekannte Seite zu erkennen sein. Zwar wurde in der Konfiguration des Virtual Hosts der ServerName validator.david.tibbe eingegeben, jedoch wird dieser nicht erkannt. Damit dies funktioniert, muss nun noch die hosts-Datei angepasst werden.

Anpassung der hosts-Datei

Die angesprochene hosts-Datei befindet sich im Verzeichnis C:\windows\hosts unter Windows 9x und im Verzeichnis C:\Windows\system32\drivers\etc\hosts unter Windows XP. Es kann sein, dass die Datei hosts nicht vorhanden ist, wohl aber eine hosts.sam. In diesem Fall muss sie einfach nur umbenannt werden.

Öffnet man die Datei mit einem Editor, so befindet sich ein einleitender Kommentar darin sowie die Zeile

Beispiel
127.0.0.1 localhost

Das bedeutet, dass, wenn man im Browser http://localhost/ aufruft, diese Anfrage an http://127.0.0.1/ weitergeleitet wird. Nun wird diese Datei wie folgt geändert:

Beispiel
127.0.0.1 localhost 127.0.0.1 www.david.tibbe 127.0.0.2 validator.david.tibbe

Nach dieser Änderung ist der Server wie bisher unter http://localhost/, aber jetzt auch unter http://www.david.tibbe/ erreichbar. Zudem werden nun auch die Anfragen auf http://validator.david.tibbe/ zu http://127.0.0.2/ weitergeleitet.

Die Serverkonfiguration ist somit abgeschlossen. Möchte man aber eine Seite validieren lassen, so wird es wahrscheinlich einen "Internal Server Error" geben. Das liegt daran, dass das check-Script noch nicht konfiguriert wurde.

Unter Umständen kann es passieren, dass Windows XP mit installiertem Service-Pack 2 Probleme mit den Loopback-Adressen (127.0.0.2 u.Ä.) hat. Das Problem und Lösngen dafür werden bei Microsoft auf einer Seite beschrieben: [ Programs that connect to IP addresses that are in the loopback address range may not work as you expect in Windows XP Service Pack 2.

Konfiguration des Validators

Im Verzeichnis C:\www\validator\htdocs\config liegt eine Datei namens validator.conf. Diese kann mit einem beliebigen Editor geöffnet und bearbeitet werden. Dabei sind die Zeilen mit einer Raute am Anfang Kommentare.

Für Library wird c:/www/sgml-lib/ angegeben. Zu beachten ist, dass im Pfad einfache Slashes verwendet werden, nicht die von Windows gewohnten Backslashes.

Home Page wird auf die URI des Validators geändert, bei mir also http://validator.david.tibbe/.

Der letzte Punkt, Allow Private IPs = { yes | no }, muss auf yes gestellt werden. Andernfalls kann man die Dateien nicht vom lokalen Rechner aus validieren lassen und erhält nur einen Zugriffsfehler aus Sicherheitsgründen.

Die vollständige Konfigurationsdatei sieht danach in etwa so aus:

Beispiel
# # Main Configuration File for the W3C Markup Validation Service. # # $Id: validator.conf,v 1.28 2007/03/14 06:33:35 ot Exp $ # # See 'perldoc Config::General' for the syntax, and be aware that the # 'SplitPolicy' is 'equalsign', ie. keys and values are separated by '\s*=\s*', # and that 'InterPolateVars' is in effect. # # # Base Path for Markup Validator files. # # You MUST set these unless you use the default locations for the files. # e.g. the config files in "/etc/w3c/" and everything else in # "/usr/local/validator/". # # Make sure all file paths below do NOT end with a slash <Paths> # # Base path. Defaults to the value of the W3C_VALIDATOR_HOME environment # variable or /usr/local/validator if the variable does not exist. #Base = /usr/local/validator # # Location of template files Templates = $Base/share/templates # configuration file for HTML Tidy Module, if available TidyConf = $Base/htdocs/config/tidy.conf <SGML> # # The SGML Library Path. Library = C:/www/sgml-lib </SGML> </Paths> # # This controls whether the debugging options are allowed to be enabled. Allow Debug = yes # # This lets you permanently enable the debugging options. Can be overridden # with CGI options (unlike "Allow Debug" above). Enable Debug = no # # Whether private RFC1918 addresses are allowed. Allow Private IPs = yes # # Enable (or not) the web service API for this validator # see http://validator.w3.org/docs/api.html Enable SOAP = yes # # Whether the validator will check its own output. # 0 means it will refuse to check its own output, 1 means it will but it will # refuse to check the results of it checking itself. Etc. Max Recursion = 0 # # Protocols the validator is allowed to use for retrieving documents. # The default is to allow http and https. <Protocols> Allow = data,http,https </Protocols> # # Email address of the maintainer of this service. Maintainer = www-validator@w3.org # # The "Home Page" for the service. Make sure this ends with a slash. Home Page = http://validator.david.tibbe/ # # Base URI for the Element Reference. Element Ref URI = http://www.htmlhelp.com/reference/html40/ # Localization # only English available for now Languages = en # # Mapping tables etc... # # # Maps element names to URLs (cf. "Element Ref URI" above). <Elements> Include eref.cfg </Elements> # # Main document Type Registry; contains all information on the types # of documents we support and how they are processed. <Types> Include types.conf </Types> # # Mapping of charset names to their IANA names and how iconv(3) knows them. <Charsets> Include charset.cfg </Charsets> # # Map MIME Media Type to Parse Mode mapping. <MIME> text/xml = XML image/svg = XML image/svg+xml = XML application/smil = XML application/xml = XML text/html = TBD text/vnd.wap.wml = XML application/xhtml+xml = XML application/mathml+xml = XML </MIME> # # Source for the "Tip of The Day" blurbs. <Tips> Include tips.cfg </Tips>

Nun ist der Validator schon einmal konfiguriert. Dennoch arbeitet er nicht, da noch ein paar Zeilen am Validator-Script selbst geändert werden müssen.

Anpassung des 'check'-Scripts

Ja, nun sind es nur noch wenige Zeilen bis zum laufenden Validator. Also, auf geht's. Die folgenden Änderungen am Script sind deswegen nötig, da es für einen Unix-Server geschrieben wurde, dort jedoch ein paar Kleinigkeiten anders sind als unter Windows.

Das Script check aus dem Verzeichnis C:\www\validator\httpd\cgi-bin wird nun mit einem beliebigen Editor geöffnet. In den folgenden Anweisungen gebe ich bewusst keine Zeilennummern an, da sich diese in zukünftigen Versionen verschieben können. Es ist aber jeweils ein Hinweis auf die Zeilen davor oder danach gegeben, anhand derer man sich orientieren kann.

Direkt die erste Zeile muss in

Beispiel
#!c:/www/perl/bin/perl.exe

geändert werden. Dies ist der Pfad zu dem Perl-Interpreter, bisher steht er dort nur in Unix-Form. So muss er also an Windows angepasst werden. Ebenso wird dabei der Parameter "-T" entfernt.

Als nächstes wird nun dem Script mitgeteilt, wo die Konfigurationsdatei liegt. Dies geschieht nach dem Kommentar in diesen Zeilen

Beispiel
# # Read Config Files. eval { my %config_opts = ( -ConfigFile => ($ENV{W3C_VALIDATOR_CFG} || '/etc/w3c/validator.conf'), Sie müssen auf {{Beispiel| {{BeispielCode|<nowiki> # # Read Config Files. eval { my %config_opts = ( -ConfigFile => 'C:/www/validator/htdocs/config/validator.conf',

geändert werden.

Für manche Einstellungen muss das check-Skript wissen, wo sich das Wurzelverzeichnis befindet. Es versucht dies durch das Auswerten der Umgebungsvariable W3C_VALIDATOR_HOME und nutzt einen Standardpfad, falls diese nicht gesetzt ist. Dies geschieht in den Zeilen

Beispiel
Paths => { Base => ($ENV{W3C_VALIDATOR_HOME} || '/usr/local/validator'), },

Sie werden zu

Beispiel
Paths => { Base => 'C:/www/validator', },

geändert.

Nun muss das Script nur noch einmal abgespeichert werden. Danach kann über http://validator.david.tibbe/ wie bisher über http://validator.w3.org/ gearbeitet werden.

Der eigene Validator ist installiert!

Hinweise für zukünftige Versionen

In neuen Versionen werden vielleicht erneut weitere Module benötigt. Diese lassen sich aber wie oben beschrieben mit PPM herunterladen und installieren. Welche das wären, ist gegebenenfalls einfach zu erkennen. Die vom Script erzeugte Fehlermeldung wird automatisch an den Browser gesendet. Sie lautet dann beispielsweise:

Beispiel
Can't locate Config/General.pm in @INC (@INC contains: C:/www/perl/lib C:/www/perl/site/lib .) at C:/www/validator/httpd/cgi-bin/check line 46. BEGIN failed--compilation aborted at C:/www/validator/httpd/cgi-bin/check line 46.

Es ist nicht schwer zu sehen, dass das Modul "Config General" fehlt und nachinstalliert werden muss.

Windows XP mit Service Pack 2 kann unter Umständen Probleme mit der Loopback-Adresse 127.0.0.2 machen. Das Problem und seine Lösung wird auf http://support.microsoft.com/default.aspx?kbid=884020 beschrieben.

Schlussbemerkungen & Dank

Diese Anleitung habe ich nach meiner erfolgreichen Installation geschrieben. Ich kann nicht garantieren, dass es auf allen anderen Systemen genauso funktioniert, es sollte aber kein Problem sein.

Falls ich in meiner Anleitung einen Fehler gemacht haben sollte oder deswegen eine eigene Installation scheitert, so stehe ich gerne per Mail (E-Mail david@tibbe-online.de) für Fragen bereit. Fragen zur Installation des Apache werden hingegen ignoriert und gelöscht.

Das hier Beschriebene habe ich nicht alles alleine hinbekommen. Auf meiner Suche waren mir folgende Personen besonders hilfreich, sodass ich diesen hier gerne ein "Danke" sagen möchte: Nennen möchte ich zum einen Björn Höhrmann für die ersten Tipps zur Installation und einige weitere Hinweise und Carsten Protsch für einige Tipps im Zusammenhang mit den Perl-Modulen sowie seiner alten Validator-Version.

Nun wünsche ich aber allen viel Spaß beim Validieren.

Weblinks