Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.webserver > #1323 > unrolled thread

Apache 2.4: CGIs werden nicht ausgefuehrt

Back to article view | Back to de.comm.software.webserver

Contents

  Apache 2.4: CGIs werden nicht ausgefuehrt Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2019-04-30 12:04 +0200
    Re: Apache 2.4: CGIs werden nicht ausgefuehrt Ralph Aichinger <ra@pi.h5.or.at> - 2019-04-30 12:19 +0200
      Re: Apache 2.4: CGIs werden nicht ausgefuehrt Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2019-04-30 12:23 +0200
    Re: Apache 2.4: CGIs werden nicht ausgefuehrt Sven Hartge <sh-194@svenhartge.de> - 2019-04-30 12:42 +0200
      Re: Apache 2.4: CGIs werden nicht ausgefuehrt Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2019-04-30 19:39 +0200
        Re: Apache 2.4: CGIs werden nicht ausgefuehrt Sven Hartge <sh-194@svenhartge.de> - 2019-04-30 20:09 +0200
    Re: Apache 2.4: CGIs werden nicht ausgefuehrt Werner Flügel <werner.fluegel@b-tu.de> - 2019-04-30 15:06 +0200

#1323 — Apache 2.4: CGIs werden nicht ausgefuehrt

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

[toc] | [next] | [standalone]

#1324

Sebastian Suchanek <sebastian.suchanek@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

> 
> 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
-- 
-----------------------------------------------------------------------------
                                                              https://aisg.at
                                                   ausserirdische sind gesund

[toc] | [prev] | [next] | [standalone]

#1325

Thus spoke Ralph Aichinger:
> Sebastian Suchanek <sebastian.suchanek@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

[toc] | [prev] | [next] | [standalone]

#1326

Sebastian Suchanek <sebastian.suchanek@gmx.de> wrote:

> <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". 

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.

[toc] | [prev] | [next] | [standalone]

#1328

Thus spoke Sven Hartge:
> Sebastian Suchanek <sebastian.suchanek@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

[toc] | [prev] | [next] | [standalone]

#1329

Sebastian Suchanek <sebastian.suchanek@gmx.de> wrote:
> Thus spoke Sven Hartge:
>> Sebastian Suchanek <sebastian.suchanek@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.

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1327

Am 30.04.2019 um 12:04 schrieb Sebastian Suchanek:
> 
> 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>
> 

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".

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.webserver

csiph-web