Bug#743860: apache2: Apache forgets about /cgi-bin on restart

2015-01-19 Thread Stefan Fritsch
This is probably this upstream bug report which concerns some 
brokenness with the Define directive:

https://issues.apache.org/bugzilla/show_bug.cgi?id=57328

The config on serverfault shows that you used Define:

> 
> 
> Define ENABLE_USR_LIB_CGI_BIN
> 
> 
> Define ENABLE_USR_LIB_CGI_BIN
> 
> 
> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
> 
> AllowOverride None
> Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
> Require all granted
> 
> 
> 

The fix seems simple enough. I hope I can get it into jessie.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#743860: apache2: Apache forgets about /cgi-bin on restart

2014-04-07 Thread Daniel Martin
Package: apache2
Version: 2.4.9-1
Severity: normal

Dear Maintainer,

I first encountered this problem on my main home Debian box, but
have now reproduced it on a fresh VM I did nothing to after the
initial install except:
1) dist-upgrade to jessie
2) install and configure apache2 as below

The problem is that apache2 will serve cgi-bin programs until it
is restarted with "apache2ctl restart" or "apache2ctl graceful".
Once that happens, it seems to forget the cgi configuration, and I
see messages like this in the error_log:

[Sun Apr 06 22:40:14.487098 2014] [core:info] [pid 8959] [client ::1:48015] 
AH00128: File does not exist: /var/www/html/cgi-bin/hello

and requests for /cgi-bin/ programs will return a standard
404 error page. A second "apache2ctl graceful" or "apach2ctl restart"
or the equivalent "service apache2 reload" will restore cgi-bin
capability. (But a third restart will lose it again, etc.)

Note that logrotate does an "/etc/init.d/apache2 reload", meaning that
without the workaround below every logrotate run would disable cgi.

To reproduce this, on a jessie system install both apache2 and
libapache2-mod-dnssd, and then do:

# a2dismod mpm_event
# a2enmod mpm_prefork
# a2enmod cgi
# a2enmod reqtimeout
# a2enmod userdir
# a2enmod dnssd

When completed, the /etc/apache2/mods-enabled directory should show:

debian@debian:/etc/apache2$ ls mods-enabled/
access_compat.load  autoindex.conf  env.load  reqtimeout.load
alias.conf  autoindex.load  filter.load   setenvif.conf
alias.load  cgi.loadmime.conf setenvif.load
auth_basic.load deflate.confmime.load status.conf
authn_core.load deflate.loadmpm_prefork.conf  status.load
authn_file.load dir.confmpm_prefork.load  userdir.conf
authz_core.load dir.loadnegotiation.conf  userdir.load
authz_host.load dnssd.conf  negotiation.load
authz_user.load dnssd.load  reqtimeout.conf

Now create a simple test cgi script; I used this:

debian@debian:/etc/apache2$ cat /usr/lib/cgi-bin/hello 
#! /bin/sh
echo "Content-Type: text/plain"
echo
echo Hello world from a cgi script.
exit

Restart apache2 with "service apache2 restart". Observe that
http://localhost/cgi-bin/hello is served properly. Run any of
the commands that get apache to reload its configuration ("apache2ctl
graceful", "apache2ctl restart", "service apache2 reload"), and then
observe that http://localhost/cgi-bin/hello is no longer served.

Despite what the apache documentation implies, no setting for
LogLevel seems to ever leave evidence in any log file of exactly which
configuration files were opened and read on each apache restart.

I previously had asked about this issue at
http://serverfault.com/questions/585914/

That page also contains a workaround I discovered (for anyone else
who encounters this issue): placing a "LogLevel warn" statement into
/etc/apache2/000-default.conf changes something so that /cgi-bin/ is
then served consistently. While reproducing this, I've also found that
this bug is *highly* sensitive to exactly which modules are enabled;
for example, disabling any one of the three modules reqtimeout, userdir,
and dnssd makes the bug vanish. When reproducing this, ensure that the
mods-enabled directory reads as above, and that everything else about
the configuration is exactly as shipped in the package.

Given this bug's weird sensitivity to things that shouldn't matter,
I worry this may point to some upstream bug involving a subtle memory
corruption issue in configuration parsing.

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2 depends on:
ii  apache2-bin   2.4.9-1
ii  apache2-data  2.4.9-1
ii  lsb-base  4.1+Debian12
ii  mime-support  3.54
ii  perl  5.18.2-2+b1
ii  procps1:3.3.9-2

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.33

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  apache2-utils
ii  iceweasel [www-browser]  24.4.0esr-1
ii  w3m [www-browser]0.5.3-15

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.0-1
ii  libaprutil1  1.5.3-1+b1
ii  libaprutil1-dbd-sqlite3  1.5.3-1+b1
ii  libaprutil1-ldap 1.5.3-1+b1
ii  libc62.18-4
ii  libldap-2.4-22.4.39-1
ii  liblua5.1-0  5.1.5-5
ii  libpcre3 1:8.31-2
ii  libssl1.0.0  1.0.1f-1
ii  libxml2  2.9.1+dfsg1-3
ii  perl 5.18.2-2+b1
ii  zlib1g   1:1.2.8.dfsg