lokale testumgebung streikt, it works!, aber kein inhalt
michat
- webserver
Hi
meine lokalen Vhosts sind irgendwie in den fritten. Ich nutze das eben nicht regelmäßig und stehe entsprechend belämmert da, wenn etwas, was zuletzt funktionierte biem nächsten aufruf streikt:
Zum lokalen test läuft apache2, den ich (unter Debian/sid) *manuel* starte, wenn ich ihn mal brauche: "etc/init.d/apache2 start"
Die VHosts sind folgendermaßen konfiguriert (und haben so auch funktioniert):
In der /etc/hosts befinden sich die entsprechenden einträge
127.0.0.1 ptac.test
127.0.0.1 test.ptac.test
127.0.0.1 ac52.test
...
127.0.0.1 mdemo.ac52.test
In der /etc/apache2/conf-available/httpd.conf sieht es so aus:
NameVirtualHost 127.0.0.1:80
<VirtualHost 127.0.0.1:80>
ServerName ptac.test
ServerAlias ptac.test www.ptac.test
DocumentRoot "/home/mh/proj/pit/hp/ptac.ch"
ServerAdmin mh@localhost
<Directory "/home/mh/proj/pit/hp/ptac.ch">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
...usw
Das Ergebnis beim Aufruf ist jedoch folgendes:
"It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet."
Natürlich ist Kontent im angegebenen Verzeichnis. Das schaut ja eigentlich nach falschem Pfad zum root directory aus, nur, herje, der ändert sich auch nach 10-maligem kontrollieren nicht. Zudem, der Fehler tritt mit *allen* früher funktionierenden VHosts auf, mit denen es eben genau so früher funktioniert hat. Ich befürchte daher eine subtile Änderung an der Apache2 Basiskonfiguration (durch software updates), die ich nicht mitbekommen habe.
Auf welchem Schlauch stehe ich, wie komm ich runter?
bye
MH
Hello,
In der /etc/apache2/conf-available/httpd.conf sieht es so aus:
NameVirtualHost 127.0.0.1:80
Ich weiß nicht, ob das bei Debian-Sid anders geregelt ist, aber bei meinen sämtlichen Debian-Installationen werden die VirtHosts unter "/etc/apache2/sites-available" eingerichtet und dann unter /etc/apache2/sites-enabled" mit einem Symbolic-Link mit der Konfiguration verbunden.
Beim Starten scannt der Apache das Verzeichnis "sites-enabled" und includet die gefundenen Dateien in die VirtHost-Section.
Ich starte den Apachen überigens lieber mit dem dafür vorgesehehen Script
apache2ctl configtest zum Testen der Konfiguration auf Syntax-Fehler
und
apache2ctl graceful zum Restart im Produktivbetrieb
oder
apache2ctl start zum Neustart
Jetzt besteht die Frage, ob Du schon das Apache-Error-Log ausgewertet hast. Was steht denn dort drin?
Vermutlich fehlt dem Burschen der Zugriff auf die Verzeichnisse für den VirtHost?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
Vermutlich fehlt dem Burschen der Zugriff auf die Verzeichnisse für den VirtHost?
Ach nee, die Seite blieb ja nicht weiß, sondern es kommt "it works".
Dann startet der Server ja.
Das bedeutet dann eher, dass die Virtual-Host-Konfiguration gar nicht eingelesen wurde.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
Das bedeutet dann eher, dass die Virtual-Host-Konfiguration gar nicht eingelesen wurde.
Das Script kann überigens noch mehr:
apache2ctl -S
gibt eine Liste aller eingelesenen Host-Definitionen aus
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach!
Ich weiß nicht, ob das bei Debian-Sid anders geregelt ist, aber bei meinen sämtlichen Debian-Installationen werden die VirtHosts [...]
Ich starte den Apachen überigens lieber mit dem dafür vorgesehehen Script
Warum machst du das so und nimmst nicht das von Debian bereitgestellte Service-Script?
service apache2 start|stop|graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status
Statt service apache2 geht auch /etc/init.d/apache2
Du nimmst ja schließlich auch die von Debian vorgesehene Konfigurationsverwaltung. Und ich denke, dass es ja irgendeinen Sinn haben wird, dass dieses Service-Script noch eine ganze Menge mehr macht, als nur das apache2ctl aufzurufen.
dedlfix.
Hello,
Warum machst du das so und nimmst nicht das von Debian bereitgestellte Service-Script?
Hast Du das auch ausprobiert?
Bei mir hat es nur den folgenden Erfolg:
root@bitworks:~# apache2 -S
apache2: bad user name ${APACHE_RUN_USER}
root@bitworks:~# /etc/init.d/apache2 -S
Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status}.
root@bitworks:~# apache2ctl -S
[Wed Jan 08 19:25:04 2014] [warn] NameVirtualHost *:80 has no VirtualHosts
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:* is a NameVirtualHost
default server bitworks.xxxx.de (/etc/apache2/sites-enabled/000-default:2)
port * namevhost bitworks.xxxx.de (/etc/apache2/sites-enabled/000-default:2)
port * namevhost bitworks.de (/etc/apache2/sites-enabled/100-bitworks.de:1)
port * namevhost selfhtml.bitworks.de (/etc/apache2/sites-enabled/101-selfhtml.bitworks.de:1)
port * namevhost xxxx.buntes-bilderbuch.de (/etc/apache2/sites-enabled/110-xxxx.buntes-bilderbuch.de:1)
port * namevhost weihnachten-nicht-allein.de (/etc/apache2/sites-enabled/113-weihnachten-nicht-allein.de:1)
port * namevhost restaurant-zur-kleinen-kapelle.de (/etc/apache2/sites-enabled/114-kleine-kapelle.com:1)
port * namevhost bergpost.annerschbarrich.de (/etc/apache2/sites-enabled/115-bergpost.de:1)
port * namevhost xxxx.de (/etc/apache2/sites-enabled/116-xxxx.de:1)
port * namevhost annerschbarrich.de (/etc/apache2/sites-enabled/120-annerschbarrich.de:1)
usw.
Syntax OK
Das kann also nicht so ganz stimmen.
apache2ctl macht dafür alles, was ich benötige.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach!
Warum machst du das so und nimmst nicht das von Debian bereitgestellte Service-Script?
Hast Du das auch ausprobiert?
Bei mir hat es nur den folgenden Erfolg:root@bitworks:~# apache2 -S
apache2: bad user name ${APACHE_RUN_USER}
Da fehlt ein service vor dem apache2, außerdem hab ich nichts von -S gesagt.
root@bitworks:~# /etc/init.d/apache2 -S
Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status}.
Auch kennt das Debian-Script -S nicht. Es ist ja keine Durchreiche nach apache2ctl sondern startet und stoppt (und noch ein paar andere Aktionen) den Server passend zu den Eigenheiten des Systems.
Das kann also nicht so ganz stimmen.
apache2ctl macht dafür alles, was ich benötige.
Dass ein paar für das Starten, Stoppen, Restarten etc. nicht benötigte Optionen anderweitig aufgerufen werden müssen, macht das Start-Stop-Script als solches nicht überflüssig.
dedlfix.
Tach!
Das Ergebnis beim Aufruf ist jedoch folgendes:
"It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet."
Das sieht danach aus, als ob der Default-Host aufgerufen wird. Schau doch mal, ob du in der Modulkonfiguration das "info" freigeben kannst, so dass du anschließend http://localhost/server-info aufrufen kannst. Dort kannst du dann alles sehen, was der Server an Konfiguration geladen hat. Da sollten zumindest deine Konfigurationsdirektiven auftauchen.
dedlfix.
Hi
»»...so dass du anschließend http://localhost/server-info aufrufen kannst. Dort kannst du dann alles sehen, was der Server an Konfiguration geladen hat...
Das zeigt zumindest definitiv, das httpd.conf *nicht* geladen wurde. Das erklärt auch warum "# apache2ctl -S" dies anzeigt: "Main DocumentRoot: "/var/www" was meinen konfigurierten pfaden widerspricht. Möglicherweise war ich bei einem dist-upgrade nicht aufmerksam und habe eigene konfigurationsscripte mit maintainerscripten überschreiben lassen, weiß nicht, aber das wäre eine erklärung.
Weiß jemand, wie ich apache2 dazu überreden kann, die httpd.conf die bei mir unter dem pfad /etc/apache2/conf-available/httpd.conf zu finden ist doch zu laden? Das ging ja zuminderst in der übergangszeit durch einen Eintrag (welchen?) in der apache2.config. Ja, klar, heute wird das über sites-available geregelt, müsste ich alles neu einrichten. Ok, Frage an Tom: wie sieht beispielhaft deine sites-available und deine sites-enabled aus (Wenn möglich ein beispiel für einen Vhost). Vielleicht läßt sich das ja relativ unaufwändig aktualisieren indem ich umkopiere. Es ist halt mehr als ein VHost, deshalb zögere ich. Früher benötigte ich auch für mehrere Vhosts das modul vhost_alias *nicht*. Ist vielleicht auch das heute anders?
Danke für eure Hilfe, da bin ich schon wieder etwas weniger generft ;-) .
bye
MH
Tach!
Weiß jemand, wie ich apache2 dazu überreden kann, die httpd.conf die bei mir unter dem pfad /etc/apache2/conf-available/httpd.conf zu finden ist doch zu laden?
Du solltest mal in der Dokumentation deines Systems nachlesen, wie die Entwickler sich gedacht haben, wie Konfigurationsdateien eingebunden werden. Das xxx-available-Verzeichnis sammelt nur alle möglichen Dateien, das xxx-enabled enthält die (Symlinks auf die available-Dateien), die geladen werden.
dedlfix.
Das xxx-available-Verzeichnis sammelt nur alle möglichen Dateien, das xxx-enabled enthält die (Symlinks auf die available-Dateien), die geladen werden.
Das klappt so auch nicht, ich geh jetzt ins debianforum.de
Das seiht nach apache totalschaden aus, neu einrichten wie oben führte zu garnichts, httpd.conf läßt sich jedoch durch link nach xx/conf-enabled aktivieren. Apache greift nun zwar offenbar auf die richtigen verezichnissse zu, jetze bekomme ich jedoch, je nach Vhost, unterschidliche fehlermeldungen:
Forbidden blabla
oder Internal server error blabla
Und das hat alles schön funktioniert zuvor, ich könnt k***********
Das seiht nach apache totalschaden aus, neu einrichten wie oben führte zu garnichts, httpd.conf läßt sich jedoch durch link nach xx/conf-enabled aktivieren. Apache greift nun zwar offenbar auf die richtigen verezichnissse zu, jetze bekomme ich jedoch, je nach Vhost, unterschidliche fehlermeldungen:
Forbidden blabla
Hatte ich nach einem Distributionsupgrade (Ubuntu 12.10 auf 13.04) auf einem Testrechner auch.
Ich 1.) die Ruhe bewahrt und
2.a) die links von /etc/apache2/sites-available/ nach /etc/apache2/sites-enabled/ neu gesetzt und
2.b) in den document-root-Verzeichnissen der vhosts die Rechte neu gesetzt und dann ging es.
Jörg Reinholz
Hi
2.b) in den document-root-Verzeichnissen der vhosts die Rechte neu gesetzt und dann ging es.
Das was du da genau getan hast möchtest du aber nicht verraten? Die links von enable auf availabel hatte ich schon versucht, brachte nichts.
Aus irgend einem Grund wollte der apache die rewrite-Engine geladen haben, wie ich im log herausgefunden habe. Das hat den fehler in soweit verschoben, als dass nun die pfade stimmen, es jedoch für alle Vhosts ein "forbidden You don't have permission to access / on this server." gibt.
BTW, dies ist apache 2.4.7
Ich habe bis jetzt das purgen des Apachen unterlassen, weil es ja Schitte vorwärts, wenn auch nur von Fehler zu Fehler gibt [sakasmus];-)[/sarkasmus], Begreifen und Verstehen und ein Marsch Richtung Lösung scheinen aber noch nicht in Sicht.
Please, genius selhtmlikus help!
MH
Das hat den fehler in soweit verschoben, als dass nun die pfade stimmen, es jedoch für alle Vhosts ein "forbidden You don't have permission to access / on this server."
Kontrolliere mal ob für die vhosts auch der Eintrag
AllowOverride All und
Options Indexes FollowSymLinks ExecCGI Includes
für das document-root gesetzt ist.
Jörg Reinholz
Kontrolliere mal ob für die vhosts auch der Eintrag
AllowOverride All und
Options Indexes FollowSymLinks ExecCGI Includesfür das document-root gesetzt ist.
Jörg Reinholz
Das war alles ok. Der Fehler war, dass die Permissions eine ganz neu Syntax haben und die meisten betreffenden Erklärungen im Netz *falsch* sind:
Alt apache 2.2:
Order allow,deny
Allow from all
FALSCH ersetzt bei apache 2.4:
Order allow,deny
Require all granted
Richtig ersetzt bei apache 2.4:
Require all granted
Damit läuft es wieder wie es soll und hat mich jetzt, mit Unterbrechungen, 8 Stunden gekostet.
> FALSCH ersetzt bei apache 2.4:
> Order allow,deny
> Require all granted
Richtig ersetzt bei apache 2.4:
Require all granted
Damit läuft es wieder wie es soll und hat mich jetzt, mit Unterbrechungen, 8 Stunden gekostet.
Das kann es gewesen sein. Mein Test-Apache ist auch ein 2.4.6. Bei meiner Distri wird allerdings das Modul access_compat.load mit geladen - Link zum Handbuch . (ubuntu)
~> ls -l /etc/apache2/mods-enabled/*compat* ergibt:
lrwxrwxrwx 1 root root 36 Nov 4 03:26 /etc/apache2/mods-enabled/access_compat.load -> ../mods-available/access_compat.load
Einer meiner virtuellen Hosts hat den Eintrag "allow from all". Und der geht also prima. Ich weiß jetzt nicht, warum Deine Distri das Modul bei einem Upgrade(!) nicht per Default aktiviert. Immerhin "sterben" ohne das Modul Webseiten.
Aber bei einem Restart ohne das Modul mit apache2ctl kommt dann auch eine aussagekräftige Fehlermeldung - Das Skript testet nämlich die Konfiguration bevor es den Server beendet.
Alternative ist
~> sudo apache2ctl configtest
Diesen Fehlermeldungen zu folgen dauert dann weniger als 8 Stunden.
Jörg Reinholz
Hi
...Bei meiner Distri wird allerdings das Modul access_compat.load mit geladen - Link zum Handbuch ]. (ubuntu)
das wurde bei mir auch mitgeladen und aktiviert, dennoch ...
~> sudo apache2ctl configtest
Diesen Fehlermeldungen zu folgen dauert dann weniger als 8 Stunden.
Ich weiß ja nicht wie die Fehlermeldungen bei dir aussehen, aber was hier bei mir bei den entsprechenden testen im log zu sehen war ging nicht über die Mitteilung hinaus, dass die Verbindungsaufnahme durch Servereinstellungen verhindert würde. Und dazu fand ich dann im netz Lösungen, die sich als nicht richtig erwiesen, is halt so ...
Dennoch, das Log hat mich in die richtige Spur gebracht, da hat du schon recht.
MH
...Bei meiner Distri wird allerdings das Modul access_compat.load mit geladen - Link zum Handbuch ]. (ubuntu)
das wurde bei mir auch mitgeladen und aktiviert, dennoch ...
Order allow,deny
allow from all
Bei mir geht das. Apache 2.4.6 mit access_compat. Womöglich wegen eines der früheren Fehlers. Ach so, das besagte Upgrade hat - neben dem Löschen der virtuellen Hosts - auch mod_rewrite (genauer dem link in ./mods_enabled) rausgeworfen. Die Liste der "Schäden" war ziemlich lang. Ich habe da wohl auch eine halbe Stunde mit verbracht.
Bei einem Produktivsystem ist also mit Ausfallzeiten zu rechnen. Ich würde das vorher testen und den aktuellen Zustand von /etc/apache2 (vor dem Upgrade) unbedingt sichern. Aber das ist bei einem solchen Upgrade wie von 2.2.x auf 2.4.x sicherlich selbstverständlich...
Jörg Reinholz
Hello,
Weiß jemand, wie ich apache2 dazu überreden kann, die httpd.conf die bei mir unter dem pfad /etc/apache2/conf-available/httpd.conf zu finden ist doch zu laden? Das ging ja zuminderst in der übergangszeit durch einen Eintrag (welchen?) in der apache2.config. Ja, klar, heute wird das über sites-available geregelt, müsste ich alles neu einrichten. Ok, Frage an Tom: wie sieht beispielhaft deine sites-available und deine sites-enabled aus (Wenn möglich ein beispiel für einen Vhost).
zunächst solltest Du mal lesen:
http://httpd.apache.org/docs/2.0/de/vhosts/
oder auch
http://www.prontosystems.org/tux/apache_vhost als mMn gute Anleitung
Und dann sollte unter /etc/apache2/sites-available die default-Seite stehen, und es sollte sich dort auch ein Beispiel für einen vHost befinden:
Die Datei heißt üblicherweise "default.dpkg.dist"
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>
Halte dich einfach an die Gepflogenheiten der Debian-Apache-Konfiguration, dann sollte es mit "Copy-n-Paste" und ein paar "alle ersetzen" für die Hostnamen, sowie ein paar "mkdir" für die Verzeichnisse im Dateisystem udn ein paar "chown www-data:www-data ./ -R" getan sein.
Hier eine meiner Beispielkonfigurationen, die ich eben gerade für einen XAMPP angelegt habe. Die unterscheidet sich mMn aber nicht wesentlich von der späteren für den Produktivserver:
<VirtualHost *:80>
ServerAdmin webmaster@testserver.lan
DocumentRoot "M:/USER/TOM/WebProgTests/gpeasy.lan/htdocs"
ServerName gpeasy.lan
ServerAlias www.gpeasy.lan
<Directory "M:/USER/TOM/WebProgTests/gpeasy.lan">
Order Allow,Deny
Allow from all
Options All
AllowOverride All
IndexOptions +FancyIndexing +IgnoreCase +FoldersFirst +NameWidth=50
AddDefaultCharset UTF-8
## AddDefaultCharset ISO-8859-1
php_value error_reporting 30719
php_value magic_quotes_gpc 0
php_admin_value memory_limit 128M
php_admin_value open_basedir "M:/USER/TOM/WebProgTests/gpeasy.lan/"
php_admin_value upload_tmp_dir "M:/USER/TOM/WebProgTests/gpeasy.lan/tmp"
php_admin_value session.save_path "M:/USER/TOM/WebProgTests/gpeasy.lan/sessions"
</Directory>
ErrorLog "M:/USER/TOM/WebProgTests/gpeasy.lan/logs/error.log"
CustomLog "M:/USER/TOM/WebProgTests/gpeasy.lan/logs/access.log" combined
</VirtualHost>
Wesentlich sind hier eigentlich nur die speziellen PHP-Konfigurationen:
Ich lege grundsätzlich für jeden vHost eigene Verzeichnisse für tmp, sessions, logs, data, includes, etc. _außerhalb_ der Document Root an und setze ein open_basedir. Da ich PHP immer noch als Modul des Apachen benutze, sind so die einzelnen Domains gegeneinander abgeschirmt. Ein Zugriff per Script auf die Daten einer anderen Domain ist so nicht möglich.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi
zunächst solltest Du mal lesen:
http://httpd.apache.org/docs/2.0/de/vhosts/
oder auch
http://www.prontosystems.org/tux/apache_vhost als mMn gute Anleitung
Danke, danke, aber du hättest mal besser genauer oder überhaupt gelesen was ich geschrieben habe, dann wäre dir aufgefallen, dass für einen unstable/sid user nicht nur die dokumentation apache2 2.0 *überholt* ist. Selbst 2.2 ist nutzlos, weil sich bei 2.4 ***entscheidendes*** geändert hat, was dazu führt dass:
Order allow,deny
allow from all
schlichtweg falsch ist. Es ist im übrigen (neben dem verschwindibus der rewrite-Engine) exakt diese permission einstellung, welche die anzeige/auslieferung ***verhindert*** hat ... bis ich es wie beschrieben richtig gemacht habe.
bye
MH