Re: help needed to complete regression fix for apache2 Bug#858373
Hi, sorry for the delay. Gmail filed this one into spam :-( Unfortunately, I don't have access to that environment anymore to confirm. I'll pass this on to the folks that do so hopefully they can. My recollection from this issue was that I'd tested it against different package versions and the 400 ErrorDocuments had worked beforehand (we used them for ModSec types of things primarily, and I'm confident that mode was working well before hand and after), though possibly not in that particular protocol error context. I vaguely recall having issues reproducing a working ErrorDocument with non-cgi methods in that protocol error mode style test as well, but I don't recall if rhat was only in the newer versions of the software that I had been testing with or true before that update as well. Anyways, thanks much for following up. Sorry I don't have more info to offer at the moment. Cheers, Brian On Fri, Jul 21, 2017, 08:44 Antoine Beaupré <anar...@orangeseeds.org> wrote: > TL;DR: New proposed package (deb7u11) doesn't ctually show a new > regression, please test: > > > https://people.debian.org/~anarcat/debian/wheezy-lts/apache2_2.2.22-13+deb7u11_amd64.changes > > In particular, Brian Kroth: are you *sure* you had that ErrorDocument > 400 working in apache2_2.2.22-13+deb7u7 (ie. before the DLA-841-1 > upload)? In my tests, it didn't actually work at all. It wouldn't > trigger a segfault, but the CGI script wouldn't get called either. In > the above package, we don't segfault anymore, but we yield a 400 + 500 > error message (because the ErrorDocument fails). The solution, here, is > obviously to update to a later Apache version (e.g. update to jessie, > really) to get that functionality working, from my perspective. > > More technical details follow. > > On 2017-07-21 09:24:00, Stefan Fritsch wrote: > > Hi Antoine, > > > > On Wednesday, 19 July 2017 15:45:20 CEST Antoine Beaupre wrote: > >> As I mentioned in the #858373 bug report, I started looking at fixing > >> the regression introduced by the 2.2.22-13+deb7u8 upload, part of > >> DLA-841-1. The problem occurs when a CGI(d) ErrorDocument is configured > >> to handle 400 error messages that can be triggered with a simple "GET / > >> HTTP/1.0\n\n". Such a request segfaults Apache in Wheezy right now. > > > >> Unfortunately, re-introducing the protocol initialization code isn't > >> sufficient: it does fix the segfaults, but the ErrorDocument handling is > >> not quite working yet. Instead of seeing the output of the > >> ErrorDocument, after 10 seconds, I get the raw 400 message, doubled with > >> a 500 error document warning: > > > >> Note that I have also tried to see if sending "\r\n" instead of just > >> "\n" in my "hello world" example would work around the issue: it > >> doesn't, unfortunately. > >> > >> I am at a loss as where to go from here, to be honest. The patch > >> (attached) at least fixes the segfault, which resolves the primary issue > >> at hand here (DoS by crashing processes!) but it would be nice to > >> actually fix the ErrorDocument as well.. > > > > This sounds familiar. Maybe it's simply broken in 2.2.22. Can you > compare with > > 2.2.22-13+deb7u7 if that bug has been there already? > > Well, the problem is - how do I reproduce this? I can't generate the > same 400 error message in deb7u7 (I tried!) with the previous techniques > because the new request handling code isn't there. That is, the > following query just works: > > # printf "GET / HTTP/1.0\n\n" | nc localhost 80 | head -1 > HTTP/1.1 200 OK > > > Furthermore, generating a 400 error, when it works in deb7u7, doesn't > trigger the ErrorDocument - not sure why: > > # printf "G ET / HTTP/1.0\r\n\r\n" | nc localhost 80 > HTTP/1.1 400 Bad Request > Date: Fri, 21 Jul 2017 13:40:48 GMT > Server: Apache/2.2.22 (Debian) > Vary: Accept-Encoding > Content-Length: 302 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > > > 400 Bad Request > > Bad Request > Your browser sent a request that this server could not understand. > > > Apache/2.2.22 (Debian) Server at wheezy.raw Port 80 > > > Logs show the following: > > [Fri Jul 21 13:40:48 2017] [error] [client 127.0.0.1] Invalid URI in > request G ET / HTTP/1.0 > > ... whether or not the 400 ErrorDocument directive is present. Notice > how the ErrorDocument isn't triggered at all here. > > Of course, a 404 ErrorDocument still works correctly: > > # printf "GET /wtf HTTP/1.0\r\n\r\n" | nc localhost 80 > HTTP/1.1 404 Not Found > Date: Fri, 21 Ju
Bug#858373: apache2: segfaults upon recieving bad request when using worker/event mpm and cgid errordoc
Package: apache2.2-common Version: 2.2.22-13+deb7u8 Severity: normal Tags: security Dear Maintainer, We have some websites running on Debian Wheezy, so still using Apache 2.2.22, that are configured either in Worker or Event MPM (so are using mod_cgid in what follows), and have a custom "ErrorDocument 400" directive that points at a perl script for providing custom ModSecurity error. I haven't dug up an older version of the package from snapshots to confirm this, but I think that since the recently backported HttpProtocolOptions directive to that version (BTW, where was that announced - I had to run strings on the binary to find it), I've been seeing a lot of segfault/coredumps registered in the Apache error logs. After some analysis, I've found that I can reproduce the error with a fairly trivial shell command: # echo -ne "GET / HTTP/1.0\n" | nc $some_website 80 From the coredump, I was able to find that this line (1371) in the cgid_handler() code in the modules/generators/mod_cgid.c source file has a null pointer issue on the r->protocol field: is_included = !strcmp(r->protocol, "INCLUDED"); Seems like a bit of a security issue to me. No combination of adjustments to the HttpProtocolOptions directive seemed to help from what I could see. I also haven't been able to reproduce this issue on a Prefork MPM backend webserver. Varying the details of the perl ErrorDocument script's implementation don't appear to help either (eg: it still occurs even with a simple hello world script). The error still occurs if I disable ModSecurity, but leave the ErrorDocument for 400 messages. Let me know if you need any more details or have any questions. Thanks, Brian -- Package-specific info: List of /etc/apache2/mods-enabled/*.load: alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgid deflate dir env expires headers include info mime mod-security negotiation reqtimeout rewrite rpaf setenvif shib2 ssl status unique_id userdir* (A * means that the .conf file for that module is not enabled in /etc/apache2/mods-enabled/) -- System Information: Debian Release: 7.11 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2 depends on: ii apache2-mpm-worker 2.2.22-13+deb7u8 ii apache2.2-common2.2.22-13+deb7u8 apache2 recommends no packages. apache2 suggests no packages. Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.22-13+deb7u8 ii apache2.2-bin 2.2.22-13+deb7u8 ii lsb-base 4.1+Debian8+deb7u1 ii mime-support 3.52-1+deb7u1 ii perl 5.14.2-21+deb7u4 ii procps 1:3.3.3-3 Versions of packages apache2.2-common recommends: pn ssl-cert Versions of packages apache2.2-common suggests: pn apache2-doc pn apache2-suexec | apache2-suexec-custom ii lynx-cur [www-browser] 2.8.8dev.12-2+deb7u1 -- no debconf information
Bug#721563: apache2: please update itk to 2.4.x
Package: apache2 Version: 2.4.6-3 Severity: wishlist The version of mpm_itk included with the apache2 package doesn't support the AssignUserIDExpr, LimitUIDRange, or LimitGIDRange options. I would like to use this functionality to implement sane git uploads over HTTP. Is it possible that you could update the itk MPM to something from the ITK 2.4.x series, now that Apache 2.4 is in unstable? -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-rc4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#710934: apache2: please include a way to automatically move conf.d files to conf-available
Package: apache2 Version: 2.4.4-5 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** To ease the transition to apache 2.4, could you have a script that automatically copies files in /etc/apache2/conf.d to /etc/apache2/conf-available? thanks, Brian Minton - -- Package-specific info: Enabled MPM: prefork List of enabled modules: dir (enabled by unknown) reqtimeout (enabled by unknown) negotiation (enabled by unknown) headers (enabled by unknown) autoindex (enabled by unknown) authn_file (enabled by unknown) mime (enabled by unknown) ssl (enabled by site administrator) authz_host (enabled by unknown) expires (enabled by unknown) filter (enabled by maintainer script) socache_shmcb (enabled by site administrator) jk (enabled by unknown) php5 (enabled by unknown) deflate (enabled by unknown) authn_core (enabled by maintainer script) alias (enabled by unknown) authz_owner (enabled by unknown) authz_core (enabled by maintainer script) setenvif (enabled by unknown) unique_id (enabled by unknown) vhost_alias (enabled by unknown) access_compat (enabled by maintainer script) mpm_prefork (enabled by site administrator) status (enabled by unknown) env (enabled by unknown) dav (enabled by unknown) wsgi (enabled by unknown) auth_pam (enabled by site administrator) List of enabled php5 extensions: curl gd gmp idn imap ldap mcrypt mhash mssql mysql mysqli odbc pam_auth pdo pdo_dblib pdo_mysql pdo_odbc pdo_pgsql pdo_sqlite pgsql ps ps recode sqlite sqlite3 suhosin uuid xmlrpc xsl List of enabled configurations: localized-error-pages (enabled by maintainer script) etag (enabled by site administrator) analog (enabled by site administrator) other-vhosts-access-log (enabled by maintainer script) httpd (enabled by site administrator) ignoresvn (enabled by site administrator) apache2-doc (enabled by maintainer script) mythweb (enabled by site administrator) upload (enabled by site administrator) pagespeed_libraries (enabled by site administrator) sugarplum (enabled by site administrator) nph-proxy (enabled by site administrator) gallery (enabled by site administrator) ajaxterm (enabled by site administrator) secure (enabled by site administrator) phpmyadmin (enabled by site administrator) info2www (enabled by site administrator) shellinabox (enabled by site administrator) pdbv (enabled by site administrator) charset (enabled by maintainer script) mythtv (enabled by site administrator) gitweb (enabled by site administrator) dwww (enabled by site administrator) myphpmoney (enabled by site administrator) gallery2 (enabled by site administrator) azureus (enabled by site administrator) doc (enabled by site administrator) bbclone (enabled by site administrator) request-length (enabled by site administrator) darcsweb (enabled by site administrator) tetex-doc (enabled by site administrator) awstats (enabled by site administrator) anyterm (enabled by site administrator) serve-cgi-bin (enabled by maintainer script) nanourl (enabled by site administrator) openwebmail (enabled by site administrator) ajaxvnc (enabled by site administrator) phppgadmin (enabled by site administrator) bminton_gallery2 (enabled by site administrator) security (enabled by maintainer script) phpgacl (enabled by site administrator) mythweb.conf.bak (enabled by site administrator) javascript-common (enabled by site administrator) servername (enabled by site administrator) ilohamail (enabled by site administrator) soht (enabled by site administrator) doc-central.apache2 (enabled by site administrator) libhtml-mason-perl-examples (enabled by site administrator) dc (enabled by site administrator) dhelp (enabled by site administrator) dpkg-www (enabled by site administrator) phpbb3 (enabled by site administrator) - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.9.0 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages apache2 depends on: ii apache2-bin 2.4.4-5 ii apache2-data 2.4.4-5 ii lsb-base 4.1+Debian11 ii mime-support 3.54 ii perl 5.14.2-21 ii procps1:3.3.8-1 Versions of packages apache2 recommends: ii ssl-cert 1.0.32 Versions of packages apache2 suggests: ii apache2-doc
Bug#619408: apache2.2-common: mod_authnz_ldap require directives unrecognized if loaded after mod_authnz_default
Package: apache2.2-common Version: 2.2.16-6 Severity: normal In the default configuration mod_authnz_ldap.load is symlinked from mods-available to mods-enabled but that orders it (lexicographically) after the symlink to load mod_authnz_default. This causes a number of ldap specific arguments to the Require definition to be unrecognized and logged as follows: [Wed Mar 23 11:04:48 2011] [error] [client 10.10.10.10] access to /auth failed, reason: unknown require directive:ldap-user bpktest bpkroth [Wed Mar 23 11:04:48 2011] [error] [client 10.10.10.10] access to /auth failed, reason: unknown require directive:ldap-group cn=bpk-test,ou=Group,o=ORG [Wed Mar 23 11:04:48 2011] [error] [client 10.10.10.10] access to /auth failed, reason: unknown require directive:ldap-attribute myacl=unix [Wed Mar 23 11:04:48 2011] [error] [client 10.10.10.10] access to /auth failed, reason: user bpktest not allowed access The relevant tidbits from my .htaccess file are as follows: # Allow authenticated access AuthType Basic AuthName Restricted Access AuthBasicProvider ldap AuthzLDAPAuthoritative on AuthLDAPURL ldap://ldapauth.mydomain.com:389/ou=People,o=ORG?uid; STARTTLS AuthLDAPRemoteUserIsDN Off AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN off Require ldap-user bpktest bpkroth Require ldap-group cn=bpk-test,ou=Group,o=ORG Require ldap-attribute myacl=unix Adding another symlink to mod_authnz_ldap.load in mods-enabled as 01-mod_authnz_ldap.load corrects this behavior, albeit with a warning message on startup (probably avoidable with an if statement around the load). Let me know if you need anything else. Thanks, Brian -- Package-specific info: List of /etc/apache2/mods-enabled/*.load: 01-authnz_ldap alias auth_basic auth_kerb auth_pam auth_plain auth_sys_group authn_file authnz_ldap authz_default authz_groupfile authz_host authz_user autoindex cgi deflate dir env include info ldap mime mod-security negotiation php5 reqtimeout rewrite rpaf setenvif ssl status unique_id vhost_alias wsgi List of enabled php5 extensions: adodb apc curl ffmpeg gd geoip gmp idn imagick interbase lasso ldap mcrypt memcache ming mssql mysql mysqli odbc pam_auth pdo pdo_dblib pdo_mysql pdo_odbc pdo_pgsql pdo_sqlite pgsql ps pspell radius recode redland sasl snmp sqlite sqlite3 ssh2 suhosin tidy uuid xmlrpc xsl -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.16-6 utility programs for webservers ii apache2.2-bin 2.2.16-6 Apache HTTP Server common binary f ii libmagic1 5.04-5 File type determination library us ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mime-support3.48-1 MIME files 'mime.types' 'mailcap ii perl5.10.1-17Larry Wall's Practical Extraction ii procps 1:3.2.8-9/proc file system utilities Versions of packages apache2.2-common recommends: pn ssl-cert none (no description available) Versions of packages apache2.2-common suggests: pn apache2-doc none (no description available) pn apache2-suexec | apache2-su none (no description available) ii lynx-cur [www-browser] 2.8.8dev.5-1 Text-mode WWW Browser with NLS sup Versions of packages apache2.2-common is related to: pn apache2-mpm-event none (no description available) pn apache2-mpm-itk none (no description available) ii apache2-mpm-prefork 2.2.16-6 Apache HTTP Server - traditional n pn apache2-mpm-workernone (no description available) -- Configuration Files: /etc/apache2/mods-available/authnz_ldap.load changed: # NOTE: This must be loaded before mod_authnz_default to avoid messages like this: # unknown require directive:ldap-attribute myacl=unix # 2011-03-23 # bpkroth # Depends: ldap LoadModule authnz_ldap_module /usr/lib/apache2/modules/mod_authnz_ldap.so -- no debconf information -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323163100.29873.39275.report...@bobo.cae.wisc.edu
Bug#619408: apache2.2-common: mod_authnz_ldap require directives unrecognized if loaded after mod_authnz_default
Stefan Fritsch s...@sfritsch.de 2011-03-23 23:01:
On Wed, 23 Mar 2011, Brian P Kroth wrote:
In the default configuration mod_authnz_ldap.load is symlinked from
mods-available to mods-enabled but that orders it (lexicographically)
after the symlink to load mod_authnz_default. This causes a number of
ldap specific arguments to the Require definition to be unrecognized and
logged as follows:
[Wed Mar 23 11:04:48 2011] [error] [client 10.10.10.10] access to
/auth failed, reason: unknown require directive:ldap-user bpktest
bpkroth
This message is not produced by apache2's core or any of the default
modules. Therefore I expect that the bug is in a third party module.
To find out which module may be the culprit, enter as root:
grep require: $(cat /proc/XXX/maps |fgrep .so|awk '{print $6}'|sort -u)
Replace XXX with the pid of a running apache process.
Fixed your grep up and did this instead:
# for pid in `pgrep apache2`; do for so in `cat /proc/$pid/maps | fgrep .so |
awk '{ print $6 }' | sort -u`; do strings $so | grep -qi 'unknown require
directive:' echo $so; done; done
Which turned up this:
/usr/lib/apache2/modules/mod_auth_plain.so
This is in this package:
# dpkg -S /usr/lib/apache2/modules/mod_auth_plain.so
libapache2-mod-auth-plain: /usr/lib/apache2/modules/mod_auth_plain.so
Anything else?
Thanks,
Brian
signature.asc
Description: Digital signature
Re: Bug#589991: mime-support: MIME types needed for x-gzip and x-compress
Dear Apache Maintainers... I'm being petitioned quite strongly to re-add types for gzipped files to the /etc/mime.types file. I originally removed those types from that file because they caused Apache to work incorrectly, namely that Apache would then send a foo.html.gz file as type=application/x-gzip instead of type=text/html;encoding=gzip. If I were to add these types back, what havoc might that wreak on current and previous releases of Apache? Brian bcwh...@pobox.com - Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
Bug#199685: Did u see this
All about the top 3 secrets - I found www.in-grand-ball.cn But copper polish joke showed do you understand? I representative tap will name to spicy you several sums look which will increa -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#286740: Corel Draw
Use addr: babloemka. com (remove space) in your browser Microsoft Windows Vista Ultimate $79 Macromedia Flash Professional 8$49 Adobe Premiere 2.0 $59 Corel Grafix Suite X3 $59 Adobe Il1ustrator CS2 $59 Adobe Photoshop CS2 V9.0 $69 Adobe Photoshop CS3 Extended $89 Macromedia Studio 8$99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2$149 Adobe Creative Suite 3 Premium$269 For Mac: Adobe Acrobat Pro 7$69 Adobe After Effects$49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Premium $49 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 Just copy 'babloemka. com' (w/o space and quotes) in address bar of your browser He nodded, just to placate her Last night, she answered. When Royce remembered and smiled, b -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353484: Removal of /var/run/apache2 causes it to fill disk with logged errors
Package: apache2 Severity: normal Please don't ship subdirectories of /var/run in packages at all. Created them in the init.d script. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.15-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages apache2 depends on: pn apache2-mpm-worker | apache2-Not found. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discount Internet Pharmacy - No Prescriptions needed
I have a bulging disc in my neck and would like pain relief please
Bug#269377: apache: Upgrade broke Apache and PHP
Package: apache Version: 1.3.31-4 Severity: important I just upgraded Apache (among other things.) Now my site, which runs b2evolution (serving up a .php index file), does not display and constantly generates new windows with nothing in them. (It's like an infinite loop.) Or, if Mozilla/your browser is not configured to handle x-html-php files then trying to visit the site just asks you what to do with the file. Something is obviously broken, but I can't figure out what to change to fix it. I selected to keep my old httpd.conf when upgrading. Strangely, all my other virtually-hosted sites work fine. None of them uses PHP, so I looked around and saw that apache-mod-php4 was not installed. It seems to me that it used to be. So, I installed it and still no fix. Any ideas greatly appreciated (to address listed below) as my site (also below) is down until I figure this out! -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.6.040615 Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.31-4 Support files for all Apache webse ii debconf 1.4.30.2 Debian configuration management sy ii dpkg1.10.23 Package maintenance system for Deb ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libdb4.24.2.52-17Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.09-1 File type determination library us ii logrotate 3.7-2Log rotation utility ii mime-support3.28-1 MIME files 'mime.types' 'mailcap ii perl5.8.4-2 Larry Wall's Practical Extraction -- debconf information: * apache/enable-suexec: false apache/server-name: www.sharealike.org apache/document-root: /home/brian/b2evolution/blogs apache/server-port: 80 apache/init: true apache/server-admin: brianwc AT ocf.berkeley.edu
Upgrade to 1.3.31 changes document root
Hi, I run Debian testing. I had Apache 1.3.29 installed and working fine, using name-based virtual hosting to host several websites. I upgraded to 1.3.31 this morning and it changed the default document root back to /var/www because now ALL of my virtual hosts point to the index.html file in /var/www. THIS IS BAD! The strange thing is that /etc/apache/httpd.conf was not altered at all during the upgrade process. The timestamp is still correct and all my virtual hosts are still listed. What file did the upgrade change? I also have apache-ssl and apache-perl installed, but haven't ever tried to use them. Please help me get these websites back online! Thanks.
Re: Upgrade to 1.3.31 changes document root
Hello again, I got the sites back up, but still have a question. Here's what I did. Copied /etc/apache/httpd.conf over every other httpd.conf file I could find, including ones in /usr/share/apache/default-configs/apache-ssl and /usr/share/apache/default-configs/apache-perl as well as /etc/apache-ssl/ and /etc/apache-perl/. Then from /etc/init.d/ I did $ ./apache stop $ ./apache-ssl stop $ ./apache-perl stop and then $ ./apache start and everything came back. Any thoughts on what caused my earlier problem? I realize that I look like a newbie here. It's because I am. Brian On Sun, Aug 01, 2004 at 10:50:38AM -0700, Brian C wrote: Hi, I run Debian testing. I had Apache 1.3.29 installed and working fine, using name-based virtual hosting to host several websites. I upgraded to 1.3.31 this morning and it changed the default document root back to /var/www because now ALL of my virtual hosts point to the index.html file in /var/www. THIS IS BAD! The strange thing is that /etc/apache/httpd.conf was not altered at all during the upgrade process. The timestamp is still correct and all my virtual hosts are still listed. What file did the upgrade change? I also have apache-ssl and apache-perl installed, but haven't ever tried to use them. Please help me get these websites back online! Thanks.
Bug#257228: apache2: FTBFS on kfreebsd-i386/sid; needs update config.{sub,guess}, new libtool
Package: apache2 Severity: wishlist Please update the config.sub and config.guess files, as well as the libtool, in your package. Currently, your package FTBFS on kfreebsd-i386 because of this. -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6-2-k7 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (ignored: LC_ALL set to C)
