Update auf Apache 2.4: Error 403 als Belohnung

Apache_Software_Foundation_Logo
Das Logo der Apache Software Foundation, die u.a. die nicht nur die Entwicklung des gleichnamigen Webservers finanziert.

Wer von Apache 2.2 auf die Version 2.4 des bekannten Webservers updatet und seine bisherige Virtual-Hosts-Konfiguration übernimmt, hat durchaus Chancen, dass der Server zur „Belohnung“ nicht mehr startet. Bei mir startete er zwar, warf aber einen Fehler 403 aus: „Forbidden You don’t have permission to access / on this server.“ Mir passierte das, nachdem ich mein Notebook, das zugleich als lokale Entwicklungsumgebung herhalten darf und deshalb einen kompletten LAMP-Stack bereithalten muss, von (X)Ubuntu 13.04 auf 13.10 aktualisiert hatte. Der Neuauflage haben die Ubuntu-Maintainer erstmals den Apachen in Version 2.4 spendiert, während in Ubuntus im April 2012 veröffentlichter LTS-Version ebenso wie unter dem kürzlich erschienenen Debian Wheezy noch Apache 2.2 läuft.

Der erste Gedanke: Etwas stimmt mit den Zugriffsrechten im Dateisystem nicht – unter Ubuntu wie Debian läuft der Webserver unter dem Benutzernamen www-data, folglich müssen die Dateien für diesen Benutzer oder zumindest die gleichnamige Gruppe lesbar sein. In meinem Fall lag’s daran nicht – vor dem Ubuntu-Update hat es ja auch mit dem Zugriff geklappt. Spielverderber muss also die Konfiguration des Apachen selbst sein.

Spätestens jetzt sollte man in der Apache-Dokumentation die Seite Upgrading to 2.4 from 2.2 gelesen haben. Dann stellt sich nämlich heraus, dass die Apache-Entwickler einige wichtige Direktiven geändert oder ganz rausgeschmissen haben. Ein ganzes Kapitel findet sich unter „Runtime Configuration“ zum Thema „Access Control“. So wurde die alte Verfahrensweise, mit den Direktiven Allow und Deny den Zugriff auf Directories oder Files zu regeln, nachdem zuvor mit der Direktive Order definiert wurde, ob zunächst einmal alles erlaubt oder verboten sein soll, durch einfachere Einzeiler mit der Require-Direktive ersetzt. Dafür trägt das neue Modul mod_authz_host Sorge.

Die Apache-Entwickler haben aber für eine Art Rückwärtskompatibilität gesorgt, indem sie das Modul mod_access_compat beifügen, das die alten Direktiven weiterhin interpretieren kann. Dieses Modul war in meiner Ubuntu-Installation auch aktiv. Wäre es nicht aktiv gewesen, hätte der Apache sowieso wegen eines Syntax Errors in der Konfigurationsdatei den (Neu-) Start verweigert – (Update:) wie in einem anderen Fall in den Kommentaren geschildert: da wurde jemand Opfer der aus der alten Konfiguration für Apache 2.2 übernommenen, aber in 2.4 abgeschafften Direktive RewriteLog.

Daran lag’s bei mir aber auch nicht. Der Apache startete ja … und meldete beharrlich den Fehler 403.

Letztlich lag der Hund anderswo begraben, die Betonung liegt auf: anderswo. Meine vHosts nutzen nämlich nicht das Verzeichnis /var/www, aus dem Apachen mit Debian-Prägung standardmäßig Web-Dokumente servieren; statt dessen liegen die Dateien in einem Unterordner meines Home-Verzeichnisses. Das ist zwar in der vHost-Konfigurationsdatei mit Hilfe der nach wie vor gültigen Direktive DocumentRoot geregelt, und der Apache hält sich auch daran, nur kann er – anders als in Version 2.2 – nicht mehr darauf zugreifen, ergo der 403er Fehler.

Der Grund ist eine von mehreren Änderungen, mit denen die Debian-Maintainer (und damit auch Ubuntu) den Webserver in Version 2.4 ausliefern: Die globale Konfigurationsdatei /etc/apache2/apache2.conf enthält anders als früher eine Directory-Direktive, die den Zugriff auf /var/www beschränkt. Man muss dem Apachen also explizit erlauben, die Dateien aus einem außerhalb liegenden Verzeichnis zu servieren. Wer das nicht für jeden vHost einzeln konfigurieren mag, fügt also in eben jene globale Konfigurationsdatei eine Verzeichnis-basierte Regel dieser Art ein (und ergänzt sie ggf. mit weiteren Optionen):

<Directory /home/pfad/zu/www/>
        [...]
        Require all granted
</Directory>

Nebenbei: Bei mir weigerte sich Apache 2.4 zunächst, die alte vHost-Konfiguration überhaupt mit a2ensite zu aktivieren. Der Grund: Konfigurationsdateien müssen auf .conf enden, so ist es am Ende der /etc/apache2/apache2.conf geregelt:

IncludeOptional sites-enabled/*.conf

Unter dem Strich kann das Update von Apache 2.2 auf 2.4 also einige Nacharbeit erfordern; was vorher ging, muss nachher womöglich wieder in Gang gebracht werden. Dabei gilt es sowohl von den Apache-Entwicklern selbst vorgenommene Modifikationen als auch Änderungen seitens der Paket-Maintainer der entsprechenden Distribution (hier war von Debian und Co. die Rede; Suse oder Fedora oder … haben ganz andere Konventionen) zu beachten. Vermutlich wird man noch die eine oder andere 403er-Anfrage in den einschlägigen Foren zu lesen bekommen, wenn erst die typischen Server-Distributionen wie Ubuntu LTS oder Debian Stable in neuen Version mit upgedateten Apache-Paketen erscheinen.

4 comments on “Update auf Apache 2.4: Error 403 als Belohnung”

  1. Hallo,

    ich bin über google auf die Seite gekommen, und habe fast das gleiche Problem mit dem Apache update.
    Ich habe nach dieser Anleitung [1] mein System auf Debian Jessie umgestellt. Natürlich habe ich die Einträge in Jessie geändert. 😉
    Bis auf ein Problem mit dem Apache Server lief das Update gut durch.
    Der Apache Server Startete nicht, als ich diesem mit [code]/etc/init.d/apache2 start[/code]
    starten wollte erhielt ich folgende Meldung:

    [code][….] Starting apache2 (via systemctl): apache2.serviceJob for apache2.service failed. See ’systemctl status apache2.service‘ and ‚journalctl -xn‘ for details.
    failed![/code]

    systemctl status httpd.service ergibt:

    [code]systemctl status httpd.service
    ● httpd.service
    Loaded: not-found (Reason: No such file or directory)
    Active: inactive (dead)[/code]
    Das macht mich schon stutzig ?
    [b]
    journalctl -xe [/b]
    [code]Apr 03 21:05:01 debianserver CRON[3120]: pam_unix(cron:session): session closed
    Apr 03 21:05:01 debianserver CRON[3121]: pam_unix(cron:session): session closed
    Apr 03 21:05:02 debianserver CRON[3119]: pam_unix(cron:session): session closed
    Apr 03 21:06:06 debianserver apache2[3154]: Starting web server: apache2 failed!
    Apr 03 21:06:06 debianserver apache2[3154]: The apache2 configtest failed. … (
    Apr 03 21:06:06 debianserver apache2[3154]: Output of config test was:
    Apr 03 21:06:06 debianserver apache2[3154]: AH00526: Syntax error on line 82 of
    Apr 03 21:06:06 debianserver apache2[3154]: Invalid command ‚RewriteLog‘, perhap
    Apr 03 21:06:06 debianserver apache2[3154]: Action ‚configtest‘ failed.
    Apr 03 21:06:06 debianserver apache2[3154]: The Apache error log may have more i
    Apr 03 21:06:06 debianserver systemd[1]: apache2.service: control process exited
    Apr 03 21:06:06 debianserver systemd[1]: Failed to start LSB: Apache2 web server
    — Subject: Unit apache2.service has failed
    — Defined-By: systemd
    — Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

    — Unit apache2.service has failed.

    — The result is failed.
    Apr 03 21:06:06 debianserver systemd[1]: Unit apache2.service entered failed sta
    Apr 03 21:09:01 debianserver CRON[3211]: pam_unix(cron:session): session opened
    Apr 03 21:09:01 debianserver CRON[3212]: (root) CMD ( [ -x /usr/lib/php5/sessio
    Apr 03 21:09:03 debianserver CRON[3211]: pam_unix(cron:session): session closed
    lines 1354-1376/1376 (END)
    Apr 03 21:05:01 debianserver CRON[3120]: pam_unix(cron:session): session closed for user root
    Apr 03 21:05:01 debianserver CRON[3121]: pam_unix(cron:session): session closed for user root
    Apr 03 21:05:02 debianserver CRON[3119]: pam_unix(cron:session): session closed for user root
    Apr 03 21:06:06 debianserver apache2[3154]: Starting web server: apache2 failed!
    Apr 03 21:06:06 debianserver apache2[3154]: The apache2 configtest failed. … (warning).
    Apr 03 21:06:06 debianserver apache2[3154]: Output of config test was:
    Apr 03 21:06:06 debianserver apache2[3154]: AH00526: Syntax error on line 82 of /etc/apache2/apache2.conf:
    Apr 03 21:06:06 debianserver apache2[3154]: Invalid command ‚RewriteLog‘, perhaps misspelled or defined by a module not included in the server configuration
    Apr 03 21:06:06 debianserver apache2[3154]: Action ‚configtest‘ failed.
    Apr 03 21:06:06 debianserver apache2[3154]: The Apache error log may have more information.
    Apr 03 21:06:06 debianserver systemd[1]: apache2.service: control process exited, code=exited status=1
    Apr 03 21:06:06 debianserver systemd[1]: Failed to start LSB: Apache2 web server.
    — Subject: Unit apache2.service has failed
    — Defined-By: systemd
    — Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

    — Unit apache2.service has failed.

    — The result is failed.
    Apr 03 21:06:06 debianserver systemd[1]: Unit apache2.service entered failed state.
    Apr 03 21:09:01 debianserver CRON[3211]: pam_unix(cron:session): session opened for user root by (uid=0)
    Apr 03 21:09:01 debianserver CRON[3212]: (root) CMD ( [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)
    Apr 03 21:09:03 debianserver CRON[3211]: pam_unix(cron:session): session closed for user root[/code]

    Gruß
    Stefan

    [1]https://www.howtoforge.com/how-to-upgrade-debian-squeeze-to-wheezy

  2. Das sind die entscheidenden Zeilen:

    Syntax error on line 82 of /etc/apache2/apache2.conf:
    Invalid command ‘RewriteLog’, perhaps misspelled or defined by a module not included in the server configuration

    Apache mag also wegen eines Fehlers in der Config-Datei nicht mehr, und tatsächlich: Die Direktiven RewriteLog and RewriteLogLevel gibt’s in Apache 2.4 nicht mehr. Schmeiß diese Zeilen raus, dann ist die Config-datei valide und der Server startet wieder!

  3. Hi,
    hatte das Problem erst jetzt, da ich von wheezy auf stretch migriert bin.
    Ich würde die von Dir beschriebenen Änderungen nicht in „/etc/apache2/apache2.conf“ machen, sondern eine eigene conf-Datei im Unterverzeichnis conf-available anlegen und dann von conf-enabled dorthin verlinken.
    Das passt besser zur gesamten Methodik, lokale Änderungen nicht in der globalen apache-config zu pflegen.

  4. Stimmt, das ist die saubere Lösung. Man legt also eine Datei conf-available/mein-verzeichnis.conf an, in der der Directory-Block notiert wird. Anschließend legt man einen Symlink zu dieser Datei in conf-enabled/ an – entweder händisch oder per a2enmod mein-verzeichnis.conf. Bin mir nur gerade nicht sicher, ob es unter Stretch noch conf.d/ statt conf-available/ als Unterverzeichnis gab. In diesem Fall muss die mein-verzeichnis.conf also in conf.d/ landen.

Schreibe einen Kommentar