Apache 2.4: CGIs werden nicht ausgefuehrt

[Sebastian Suchanek]

Hallo NG!

Vor einiger Zeit hatte ich mir mit Hilfe eines
c't-Kochrezepts[1] einen eigenen DynDNS-Dienst eingerichtet.
Das funktionierte auch einige Zeit zufriedenstellend; seit
ich allerdings den Server, auf dem das läuft, von Debian
Wheezy über Jessie nach Stretch upgedatet habe (Apache v2.2.x
=> v2.4.25), funktioniert es leider nicht mehr.

Hier zunächst die entsprechende vhost-Konfiguration:

--------------------------- 8< ---------------------------

<VirtualHost *:80>
DocumentRoot /usr/share/members
ServerName [entfernt]
ServerAlias [entfernt]
CustomLog /var/log/apache2/members_access.log combined
LogLevel info
Options +ExecCGI
AddHandler cgi-script .cgi
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/nic/update$
RewriteRule (.*) /usr/share/members/update.cgi
<Location />
AuthType Basic
AuthUserFile /usr/share/members/.htpasswd
AuthGroupFile /dev/null
AuthName "DyDN API Access."
Order allow,deny
Deny from all
Satisfy any
Require valid-user
</Location>
</VirtualHost>

--------------------------- 8< ---------------------------

Wenn ich die entsprechende Update-Seite
http://domain.tld/nic/update mit dem Browser aufrufe, erhalte
ich einen Fehler 403.

Da sich IIRC bei Apache 2.4 auch die "Order"-Syntax geändert
hat, habe ich testweise mal den ganzen
Authentifizierungsblock auskommentiert, doch auch damit
erhalte ich nach wie vor 403er. Im Apache Fehlerlog steht
dazu:

| [cgi:error] [...] AH02809: Options ExecCGI is off in this directory: /usr/share/members/update.cgi

WTF!? In der o.g. Konfiguration steht doch deutlich "Options
+ExecCGI".
Testweise habe ich noch in /etc/apache2/apache2.conf im Block

| [...]
| <Directory /usr/share>
| AllowOverride None
| Require all granted
| </Directory>
| [...]

das "AllowOverride" auf "All" geändert, aber auch das hat
keine Veränderung bewirkt. (Und ja, natürlich habe ich den
Apachen nach jeder Änderung immer wieder neu gestartet.)

Was läuft da schief, warum glaubt Apache das CGI-Skript nicht
ausführen zu können/dürfen? Und wie kann ich das Problem
beheben?


TIA,

Sebastian

______
[1] http://www.ct.de/1324196

[Ralph Aichinger]

Sebastian Suchanek <sebastian...@gmx.de> wrote:
> Das funktionierte auch einige Zeit zufriedenstellend; seit
> ich allerdings den Server, auf dem das läuft, von Debian
> Wheezy über Jessie nach Stretch upgedatet habe (Apache v2.2.x
> => v2.4.25), funktioniert es leider nicht mehr.

Blöde Frage: Hat dein vhosts-Config-file die Endung .conf?
Bei irgendeinem Update hat das bei mir Probleme gemacht
(ohne Endung wurde vorher toleriert, nachher nicht mehr).

/ralph

--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund

[Sebastian Suchanek]

Thus spoke Ralph Aichinger:

> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>
>> Das funktionierte auch einige Zeit zufriedenstellend; seit
>> ich allerdings den Server, auf dem das läuft, von Debian
>> Wheezy über Jessie nach Stretch upgedatet habe (Apache
>> v2.2.x => v2.4.25), funktioniert es leider nicht mehr.
>
> Blöde Frage: Hat dein vhosts-Config-file die Endung .conf?
> Bei irgendeinem Update hat das bei mir Probleme gemacht
> (ohne Endung wurde vorher toleriert, nachher nicht mehr).

> [...]

Ja, *diese* blutige Nase habe ich mir schon geholt. (Und die
Dateinamen entsprechend angepasst.) ;-)


Tschüs,

Sebastian

[Sven Hartge]

Ja, aber nicht für das Verzeichnis, nur für den VHost. Und ich bin mir
fast sicher, dass die Option "ExecCGI" auf VHost-Ebene keine Wirkung
hat.

Du brauchst in deiner vhost.conf noch ein

<Directory /usr/share/members/>
Options +ExecCGI
</Directory>

Bemerkungen, die nichts mit dem Problem zu tun haben, die mir aber
auffallen:

1) Ich würde die .htpasswd nicht in einem direkt via HTTP erreichbaren
Verzeichnis liegen lassen, diese sollte außerhalb des DocumentRoot
liegen.

2) Unter /usr/share würde ich nichts ablegen, sondern die Daten eher
unter einem Pfad wie /srv/web/dyndns/html haben wollen. Die .htpasswd
kann dann unter /srv/web/dyndns/htpasswd liegen.

S!

--
Sigmentation fault. Core dumped.

[Werner Flügel]

Hat mit Deinem Problem vielleicht nichts zu tun, aber IIRC hat sich in
der Konfig zum Teil die Syntax geändert: statt "Deny from all" heißt es
jetzt "Require all denied".

[Sebastian Suchanek]

Thus spoke Sven Hartge:
> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>
>> [...]

>> WTF!? In der o.g. Konfiguration steht doch deutlich
>> "Options +ExecCGI".
>
> Ja, aber nicht für das Verzeichnis, nur für den VHost. Und
> ich bin mir fast sicher, dass die Option "ExecCGI" auf
> VHost-Ebene keine Wirkung hat.
>
> Du brauchst in deiner vhost.conf noch ein
>
> <Directory /usr/share/members/>
> Options +ExecCGI
> </Directory>

Danke, das war's - mit der o.g. verzeichnisbezogenen Option
funktioniert es.

Was ist der Grund dafür, dass man das "neuerdings" (auch)
verzeichnisbasiert aktivieren muss und vhost-basiert (alleine)
nicht mehr ausreicht?

> Bemerkungen, die nichts mit dem Problem zu tun haben, die
> mir aber auffallen:

> [...]

Im Prinzip stimme ich Dir zu. Klarer Fall von "erstmal überhaupt
an's Laufen bringen" und danach vergessen... ;-)


Tschüs,

Sebastian

[Sven Hartge]

Sebastian Suchanek <sebastian...@gmx.de> wrote:
> Thus spoke Sven Hartge:
>> Sebastian Suchanek <sebastian...@gmx.de> wrote:

>>> [...]
>>> WTF!? In der o.g. Konfiguration steht doch deutlich
>>> "Options +ExecCGI".
>>
>> Ja, aber nicht für das Verzeichnis, nur für den VHost. Und
>> ich bin mir fast sicher, dass die Option "ExecCGI" auf
>> VHost-Ebene keine Wirkung hat.
>>
>> Du brauchst in deiner vhost.conf noch ein
>>
>> <Directory /usr/share/members/>
>> Options +ExecCGI
>> </Directory>

> Danke, das war's - mit der o.g. verzeichnisbezogenen Option
> funktioniert es.

> Was ist der Grund dafür, dass man das "neuerdings" (auch)
> verzeichnisbasiert aktivieren muss und vhost-basiert (alleine) nicht
> mehr ausreicht?

Warum kann ich nicht sagen. Ich bin überrascht, dass es *überhaupt*
jemals außerhalb von <Directory> funktioniert hat.

Ich z.B. habe immer die Kombination von

DocumentRoot /foo/var
<Directory /foo/bar>
...
</Directory>
<Location /
...
</Location>

in meinem VHosts, weil das m.M.n. einfach logischer so ist. Dann gibt es
keine Überraschungen, was für Einstellungen für welches Verzeichnis an
welcher Stelle gelten.

Ich kann mir durchaus vorstellen, dass es früher nur aus Versehen
funktioniert hat, aus Sicherheitsgründen so nie gedacht war und daher
irgendwann vor 2.4 korrigiert wurde.