Fwd: apache2_2.4.43-1~bpo9+1_amd64.changes is NEW
Hi, let's wait for release team review Message transféré Sujet : apache2_2.4.43-1~bpo9+1_amd64.changes is NEW Date : Sun, 10 May 2020 20:20:12 + De : Debian FTP Masters Pour : Xavier Guimard , Debian Apache Maintainers binary:apache2 is NEW. binary:apache2-bin is NEW. binary:apache2-data is NEW. binary:apache2-dev is NEW. binary:apache2-doc is NEW. binary:apache2-ssl-dev is NEW. binary:apache2-suexec-custom is NEW. binary:apache2-suexec-pristine is NEW. binary:apache2-utils is NEW. binary:libapache2-mod-md is NEW. binary:libapache2-mod-proxy-uwsgi is NEW. binary:libapache2-mod-md is NEW. binary:apache2-doc is NEW. binary:apache2-suexec-pristine is NEW. binary:apache2 is NEW. binary:apache2-dev is NEW. binary:apache2-ssl-dev is NEW. binary:libapache2-mod-proxy-uwsgi is NEW. binary:apache2-data is NEW. binary:apache2-suexec-custom is NEW. binary:apache2-bin is NEW. binary:apache2-utils is NEW. source:apache2 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Bug#916375: Fwd: Bug#916375: apache2: Segmentation fault when mod_perl.so is loaded
Cc: libapache2-mod-perl2 Message Subject : Bug#916375: apache2: Segmentation fault when mod_perl.so is loaded Date : Thu, 13 Dec 2018 19:09:02 + >From : h.thien To : debian-bugs-d...@lists.debian.org Cc : t...@security.debian.org, Debian Apache Maintainers Package: apache2 Version: 2.4.25-3+deb9u6 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, For communication with our customers we use the OTRS Ticket System. The server was reinstalled about a year ago and worked fine until it was rebooted three days ago. Since then the Apache web server crashes reproducibly as soon as it has to process a request. Here is a stacktrace: cd /etc/apache2 . envvars gdb /usr/sbin/apache2 gdb> set args -X gdb> run # ... now use the webbrowser to send an http request to the apache2 server: http://otrs-testing/otrs/index.pl?Action=Admin gdb> Thread 1 "/opt/otrs/bin/cgi-bi" received signal SIGSEGV, Segmentation fault. gdb> bt #0 0x7fffdcd290c7 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #1 0x7fffdcd29422 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #2 0x7fffdcd29461 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #3 0x7fffdcd29637 in free_defaults () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #4 0x7fffdccf5868 in mysql_options4 () from /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 #5 0x7fffdd2cabc8 in mysql_dr_connect () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #6 0x7fffdd2ccc69 in ?? () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #7 0x7fffdd2ccd71 in mysql_db_login () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #8 0x7fffdd2d9651 in ?? () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so #9 0x73901950 in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #10 0x738f9e96 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #11 0x73879d5b in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #12 0x7fffea84c2e9 in XS_DBI_dispatch () from /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBI/DBI.so #13 0x73901950 in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #14 0x738f9e96 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #15 0x7387a10e in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.24 #16 0x73c32c68 in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #17 0x73c33606 in modperl_callback_run_handlers () from /usr/lib/apache2/modules/mod_perl.so #18 0x73c33d9f in modperl_callback_per_dir () from /usr/lib/apache2/modules/mod_perl.so #19 0x73c2e0fb in ?? () from /usr/lib/apache2/modules/mod_perl.so #20 0x73c2e32c in modperl_response_handler_cgi () from /usr/lib/apache2/modules/mod_perl.so #21 0x555abc40 in ap_run_handler () #22 0x555ac1d6 in ap_invoke_handler () #23 0x555c3e13 in ap_process_async_request () #24 0x555c3f20 in ap_process_request () #25 0x555bffdd in ?? () #26 0x555b5ab0 in ap_run_process_connection () #27 0x740686bf in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #28 0x740688f2 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #29 0x74069e37 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so #30 0x5558f00e in ap_run_mpm () #31 0x55587c4d in main () We are using unattended upgrades (security only), and we suspect that an automatic system update has installed a new Perl version that now causes these problems. We have a second OTRS fallback system that hasn't been restarted for 94 days, and everything is still working fine there. If we compare the shared libraries loaded by apache on these two systems (/proc//maps) we can see that the following .so files have been renewed. 484 -rw-r--r-- 1 root root 489960 Nov 29 20:45 /usr/lib/x86_64-linux-gnu/libtiff.so.5.2.6 2008
Fwd: Re: [php-maint] Bug#791902: libapache2-mod-php5.postinst: 291: [: !=: unexpected operator
-- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server - Original message - From: Ondřej Surý ond...@sury.org To: Andreas Beckmann a...@debian.org, 791...@bugs.debian.org, debian-ap...@lists.debian.org Subject: Re: [php-maint] Bug#791902: libapache2-mod-php5.postinst: 291: [: !=: unexpected operator Date: Thu, 09 Jul 2015 16:10:08 +0200 Hi Andreas, https://qa.debian.org/developer.php?email= we pull /usr/share/apache2/apache2-maintscript-helper, so that error probably comes from there. I am Ccing apache2 maintainers, they might have some insight on that... Cheers, Ondrej On Thu, Jul 9, 2015, at 13:59, Andreas Beckmann wrote: Package: libapache2-mod-php5 Version: 5.6.9+dfsg-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package reported a postinst error upon installation but did not fail on it. I noticed this while analyzing the failure log from testing fusionforge-plugin-gravatar. From the attached log (scroll to the bottom...): Setting up libapache2-mod-php5 (5.6.9+dfsg-1) ... Creating config file /etc/php5/apache2/php.ini with new version There is more than one MPM loaded. Do not proceed due to undefined results There is more than one MPM loaded. Do not proceed due to undefined results There is more than one MPM loaded. Do not proceed due to undefined results /var/lib/dpkg/info/libapache2-mod-php5.postinst: 291: [: !=: unexpected operator apache2_switch_mpm prefork: No action required apache2_invoke: Enable module php5 invoke-rc.d: policy-rc.d denied execution of restart. That postinst script has only 78 lines, no idea where this error comes from. cheers, Andreas ___ pkg-php-maint mailing list pkg-php-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint Email had 1 attachment: + fusionforge-plugin-gravatar_6.0.2+20150708-1.log.gz 67k (application/gzip) -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1436451786.1841141.319485033.2ab81...@webmail.messagingengine.com
Fwd: Re: Apache2 stuck in state Built ?
For your information Forwarded Message Subject: Re: Apache2 stuck in state Built ? Date: Thu, 7 May 2015 22:48:26 +0200 From: Kurt Roeckx k...@roeckx.be To: Jean-Michel Nirgal Vourgère jmv_...@nirgal.com CC: i...@buildd.debian.org On Thu, May 07, 2015 at 07:58:03PM +, Jean-Michel Nirgal Vourgère wrote: Hi Package apache2 has been in state Built and not Installed on i386 for more than 2 days. [1] For some reason the upload kept failing. It's been uploaded now. Kurt signature.asc Description: OpenPGP digital signature
Bug#739614: Fwd: Re: Bug#739614: [apache2] unable to execute apache2
Original Message From: marco.ri...@gmail.com Fri Feb 21 09:50:06 2014 Return-Path: marco.ri...@gmail.com X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id 5362C16419A; Fri, 21 Feb 2014 09:50:06 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smart.knallkopp.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 X-policyd-weight: using cached result; rate: -5.5 Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id B18AD164178 for deb...@toell.net; Fri, 21 Feb 2014 09:50:00 +0100 (CET) Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]) by muffat.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from marco.ri...@gmail.com) id 1WGlny-0002UE-Jp for deb...@toell.net; Fri, 21 Feb 2014 08:49:59 + Received: by mail-ee0-f42.google.com with SMTP id b15so1451736eek.1 for a...@debian.org; Fri, 21 Feb 2014 00:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MnCfXMdLIR8yfrFpVOsC73jng1WPi2xW1MQ0+AGzT2Y=; b=FlCUSqX90YmXIVCaTpes6szFuydunoaEmZTyIBe0w06rBj/p7fqTiFz+f6+pdtFyGs asQeTAIph/zaIR5F/aFZM222ZWkWJvPotko/1KECj9cvzCLZmi76dIxwZOWBOVKFML2Z +OzdQ6GnV+Yepph4qALDfwhnJzMapwbnHu+TLKKBU9bw6Y57kRK8falB0QI7eRr8VAms SFFomsT1rM0BHI+NztKIoQReas4eyEu7Zb6ORDTG5uCK3OS5ZaRftDcz1WH0xUFcx0EW zdCH0cyZGn3nxKW6QdXLwH05DL+bZJ1pF1zJf9wKUpjxlpDnu3k7mcg+svOWQZrr2kvt IFMw== X-Received: by 10.14.175.2 with SMTP id y2mr6817847eel.75.1392972590781; Fri, 21 Feb 2014 00:49:50 -0800 (PST) Received: from [146.48.81.142] (pc-thesaurus1.isti.cnr.it. [146.48.81.142])by mx.google.com with ESMTPSA id 46sm24014582ees.4.2014.02.21.00.49.50for a...@debian.org (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);Fri, 21 Feb 2014 00:49:50 -0800 (PST) Message-ID: 5307132d.8030...@gmail.com Date: Fri, 21 Feb 2014 09:49:49 +0100 From: Marco Righi marco.ri...@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Arno Töll a...@debian.org Subject: Re: Bug#739614: [apache2] unable to execute apache2 References: 53060663.7050...@gmail.com 5306157d.6020...@debian.org In-Reply-To: 5306157d.6020...@debian.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit apachectl start Command 593 of 97 #apachectl start sh: 0: getcwd() failed: No such file or directory AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 2a00:1620:c0:50:f66d:4ff:fe74:f12c. Set the 'ServerName' directive globally to suppress this message (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down AH00015: Unable to open logs Action 'start' failed. The Apache error log may have more 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/530716e7.8060...@debian.org
Bug#717476: Fwd: Re: updates lost Alias modules
On Do, 01 Aug 2013, Jean-Michel Vourgère wrote: Can you check if you auto-purge packages on updates? No idea ... at least I cannot find anything under /etc/apt/ ... Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- 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/20130802025828.gd27...@gamma.logic.tuwien.ac.at
Bug#711117: Fwd: Anacron job 'cron.daily' on tglase.lan.tarent.de
tags 77 + patch
thanks
Hi,
please see the attached patch. (The initscript is ugly,
but I tried to keep the changes relatively minimal.)
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke
-- Forwarded message --
From: Anacron r...@tglase.lan.tarent.de
Message-ID: 20130602053545.90c13702...@tglase.lan.tarent.de
To: r...@tglase.lan.tarent.de
Date: Sun, 2 Jun 2013 07:35:45 +0200 (CEST)
Subject: Anacron job 'cron.daily' on tglase.lan.tarent.de
/etc/cron.daily/logrotate:
error: error running shared postrotate script for '/var/log/apache2/*.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1From b47a2167c32559885d7cff6d72f83301aa67bfc6 Mon Sep 17 00:00:00 2001
From: Thorsten Glaser t...@debian.org
Date: Wed, 5 Jun 2013 11:04:59 +0200
Subject: [PATCH] The init script exits 0 unless an error occured. Closes:
#77
Signed-off-by: Thorsten Glaser t...@debian.org
---
debian/apache2.init | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/debian/apache2.init b/debian/apache2.init
index a9f215f..78f84cc 100755
--- a/debian/apache2.init
+++ b/debian/apache2.init
@@ -206,7 +206,9 @@ do_stop()
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
-if $APACHE2CTL configtest /dev/null 21; then
+ $APACHE2CTL configtest /dev/null 21
+ APACHE2_INIT_CONFIGTEST_STATUS=$?
+ if test $APACHE2_INIT_CONFIGTEST_STATUS = 0; then
if ! pidofproc -p $PIDFILE $DAEMON /dev/null 21 ; then
APACHE2_INIT_MESSAGE=Apache2 is not running
return 2
@@ -282,6 +284,7 @@ case $1 in
[ $VERBOSE != no ] log_end_msg 1
[ -n $APACHE2_INIT_MESSAGE ] echo $APACHE2_INIT_MESSAGE 2
log_failure_msg
+ exit 1
;;
esac
;;
@@ -305,15 +308,25 @@ case $1 in
[ $VERBOSE != no ] log_end_msg $?
fi
+ case $RET_STATUS in
+ (0|1)
+ ;;
+ (*)
+ exit 1
+ ;;
+ esac
+
;;
status)
- status_of_proc -p $PIDFILE apache2 $NAME exit 0 || exit $?
+ status_of_proc -p $PIDFILE apache2 $NAME
+ exit $?
;;
reload|force-reload|graceful)
log_daemon_msg Reloading $DESC $NAME
do_reload
log_end_msg $?
[ $VERBOSE != no ] [ x$APACHE2_INIT_MESSAGE != x ] log_warning_msg $APACHE2_INIT_MESSAGE
+ test $APACHE2_INIT_CONFIGTEST_STATUS = 0 || exit 1
;;
restart)
log_daemon_msg Restarting $DESC $NAME
@@ -322,14 +335,15 @@ case $1 in
0|1)
do_start
case $? in
- 0) log_end_msg 0 ;;
- 1) log_end_msg 1 ;; # Old process is still running
- *) log_end_msg 1 ;; # Failed to start
+ 0) log_end_msg 0 ;;
+ 1) log_end_msg 1; exit 1 ;; # Old process is still running
+ *) log_end_msg 1; exit 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
+ exit 1
;;
esac
;;
@@ -348,3 +362,4 @@ case $1 in
exit 3
;;
esac
+exit 0
--
1.8.3
Processed: Fwd: Anacron job 'cron.daily' on tglase.lan.tarent.de
Processing commands for cont...@bugs.debian.org: tags 77 + patch Bug #77 [apache2] apache2: /etc/init.d/apache2 reload always returns 1 Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 77: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13704232032884.transcr...@bugs.debian.org
Bug#701117: Fwd: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing
forwarded 701117 https://issues.apache.org/bugzilla/show_bug.cgi?id=50823 retitle 701117 Should respond with HTTP/1.x when talking http to a https port thanks On Friday 22 February 2013, Arno Töll wrote: telnet alioth.debian.org 443 Trying 217.196.43.134... Connected to alioth.debian.org. Escape character is '^]'. GET / HTTP/1.1 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN This is https://issues.apache.org/bugzilla/show_bug.cgi?id=50823 -- 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/201302231207.27453...@sfritsch.de
Bug#701117: Fwd: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing
Original Message From: christo...@guilloux.info Fri Feb 22 00:16:41 2013 Return-Path: christo...@guilloux.info X-Original-To: deb...@toell.net Delivered-To: deb...@toell.net Received: by smart.knallkopp.de (Postfix, from userid 6061) id DBAA4164090; Fri, 22 Feb 2013 00:16:40 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smart.knallkopp.de X-Spam-Level: * X-Spam-Status: No, score=1.3 required=3.0 tests=RDNS_NONE autolearn=disabled version=3.3.1 X-policyd-weight: using cached result; rate: -5.5 Received: from master.debian.org (unknown [82.195.75.110]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smart.knallkopp.de (Postfix) with ESMTPS id 442F0164059 for deb...@toell.net; Fri, 22 Feb 2013 00:16:39 +0100 (CET) Received: from srv002.dedinux.com ([46.105.37.180]) by master.debian.org with esmtp (Exim 4.80) (envelope-from christo...@guilloux.info) id 1U8fNW-0006tv-Tn for deb...@toell.net; Thu, 21 Feb 2013 23:16:38 + Received: from localhost (localhost.localdomain [127.0.0.1]) by srv002.dedinux.com (Postfix) with ESMTP id 6A38E2C0579 for a...@debian.org; Fri, 22 Feb 2013 00:16:33 +0100 (CET) X-Virus-Scanned: spam virus filtering at Received: from srv002.dedinux.com ([127.0.0.1]) by localhost (srv002.dedinux.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OzGGWBjbcLBs for a...@debian.org; Fri, 22 Feb 2013 00:16:33 +0100 (CET) Received: from srv002.dedinux.com (localhost.localdomain [127.0.0.1]) by srv002.dedinux.com (Postfix) with ESMTP id 085152C376C for a...@debian.org; Fri, 22 Feb 2013 00:16:33 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 22 Feb 2013 00:16:33 +0100 From: Christophe GUILLOUX christo...@guilloux.info To: Arno Töll a...@debian.org Subject: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing In-Reply-To: 51268e3f.7090...@debian.org References: 0f6a07fa3ffe54e44a2738c4f5071...@srv002.dedinux.com 51268e3f.7090...@debian.org Message-ID: d800d1731c1c623625e05e6af1c6e...@srv002.dedinux.com X-Sender: christo...@guilloux.info User-Agent: Roundcube Webmail/0.7.1 Le 2013-02-21 22:14, Arno Töll a écrit : On 21.02.2013 20:26, Christophe GUILLOUX wrote: This bug is affecting debian wheezy, some browser can be affected and other not (because they interpret the page as a html by default) : https://issues.apache.org/bugzilla/show_bug.cgi?id=48357 I am not sure how your description matches the bug you mentioned. The bug you linked is about custom error page handling when clients violating the HTTP 1.1 protocol are requesting pages. Do you mind to explain? Sorry, I don't understand the entire second sentence. I think apache should respond with header even if the client sent a bad request. RFC is too long but i suppose they write that server must respond : HTTP/1.1 400 Bad Request ... and not directly the html or text. For example, i do : telnet alioth.debian.org 443 Trying 217.196.43.134... Connected to alioth.debian.org. Escape character is '^]'. GET / HTTP/1.1 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title400 Bad Request/title /headbody h1Bad Request/h1 pYour browser sent a request that this server could not understand.br / Reason: You're speaking plain HTTP to an SSL-enabled server port.br / Instead use the HTTPS scheme to access this URL, please.br / blockquoteHint: a href=https://alioth.debian.org/;bhttps://alioth.debian.org//b/a/blockquote/p hr addressApache/2.2.16 (Debian) Server at alioth.debian.org Port 443/address /body/html Connection closed by foreign host. I think it miss this before the html response: HTTP/1.1 400 Bad Request Date: Thu, 21 Feb 2013 23:13:29 GMT Server: Apache/2.2.16 (Debian) Vary: Accept-Encoding Content-Length: 309 Connection: close Content-Type: text/html; charset=iso-8859-1 It seems that the problem appear only when client do a clear request on a SSL port. -- Cordialement, Christophe GUILLOUX -- 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/5126b0e2.2070...@debian.org
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Fri, 2012-10-26 at 13:18 +0200, Ondřej Surý wrote: + It is also advised that + you check your custom configuration whether it's not vulnerable to + foo.php.jpeg attacks. The php5_cgi configuration snippet can be used + as base - it's important to use FilesMatch or Files directive to + limit the handling to the last extension. Can we perhaps explain a bit more, what the foo.php.jpeg attack is? The last sentence hints it already a bit,... but I guess without clear explanation people may simply skip it. I think it became clear that we are stuck with no solution which would work for anyone Do you agree... that we should work on some hopefully general-everything-works framework for jessie? Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: Hi Ondřej, I also cannot think of any configuration that would make everyone happy. At the moment, I fear this can only be solved by more documentation. Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5, e.g. before The standard configuration now also... : WARNING: The new configuration may override other configuration directives you may have added locally for the .php extension, for example for FastCGI processing. This behavior is caused by FilesMatch configuration sections overriding directives appearing in global server or VirtualHost scope. You should review and test your configuration and verify that your php scripts work as expected. In the end I have used slightly different text with a warning to check the existing setup foo.php.jpeg vulnerability. Improvements welcome (as a patch, not as a rant). + The new (dummy) php5_cgi configuration uses SetHandler directive and + thus it might interfere with your existing custom configuration like + FastCGI (mod_fcgid or mod_fastcgi). In that case please disable + php5_cgi module (a2dismod php5_cgi) to reenable the existing + functionality of your custom configuration. It is also advised that + you check your custom configuration whether it's not vulnerable to + foo.php.jpeg attacks. The php5_cgi configuration snippet can be used + as base - it's important to use FilesMatch or Files directive to + limit the handling to the last extension. I think it became clear that we are stuck with no solution which would work for anyone, so this is the minimal variant of what we should do in PHP package. If somebody comes with better solution (or just tests the non-magic mime-types as written down by sf in http://wiki.debian.org/Apache/WheezyMimeTypes), I think we can still change that before release. But now we at least need more test in php5-cgi.NEWS. O. -- Ondřej Surý ond...@sury.org -- 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/caljhhg9sermgxmzpyi0da+kjkj_nbsc_9s0x6aseyv5gps-...@mail.gmail.com
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Thursday 11 October 2012, Charles Plessy wrote: Le Mon, Oct 08, 2012 at 03:38:10PM +0200, Ondřej Surý a écrit : Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. And remove the php-cgi.conf completely, right? So this would introduce a different fix for the multi-views problem. Are you sure that there is no other problem that we would re-introduce? Maybe it's worth a try. Hello Ondřej, Stefan, and everybody, Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? There is at least no solution that is obviously right. I fear that regardless what we do, we will break some configs. Besides removing the media types from /etc/mime.types, one could add a RemoveType php ... to the apache config (but where?). Or maybe, one could also set AddHandler default-handler php The latter is an idea I just had, I have not thought it through or tested it. I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Of course, it is even better if there is an easy way to adjust the priority of the SetHandler statement of php5_cgi.conf in a way that does not break FastCGI configurations. I think there are rather too many possibilities and the pros/cons of each one get lost in this thread. (Well, that is partially my fault because I take so long to respond, but I have been busy :-( ) Maybe it would be better to create a single document with all possible solutions and pro and cons? I have started to create such an overview at http://wiki.debian.org/Apache/WheezyMimeTypes but it is not finished yet. Feel free to add more infos/solutions/pros/cons. The page may come in handy for the Jessie, too. Christoph: For mod-fastcgi/mod-fcgid, the file.fcgi.foo problem is somewhat mitigated that they require Options ExecCGI, too. And AFAICS that is not set by default. Any opinions if this is good enough for wheezy? I lean towards yes, but maybe I am missing something. Besides, it would be interesting to check how mod_action behaves... Cheers, Stefan -- 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/201210160016.04486...@debian.org
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hey folks. On Tue, 2012-10-16 at 00:16 +0200, Stefan Fritsch wrote: And remove the php-cgi.conf completely, right? So this would introduce a different fix for the multi-views problem. Are you sure that there is no other problem that we would re-introduce? Maybe it's worth a try. There is at least no solution that is obviously right. I fear that regardless what we do, we will break some configs. I'd say we should sit together after wheezy however,... searching for some best-as-possible-overall-framework ;) Besides removing the media types from /etc/mime.types, one could add a RemoveType php ... to the apache config (but where?). I proposed that previously to Ondřej but only as a poor-man's guarantee... I wouldn't want to see that we really rely on it,... cause it may easily break... One never knows what upstream changes... e.g. at some day there might be a change in the order of evaluation from RemoveType and TypesConfig... or evil things like that... Or maybe, one could also set AddHandler default-handler php The latter is an idea I just had, I have not thought it through or tested it. Sounds like it could work,... and actually a nice idea ;) ... but it seems somewhat ugly to me... you know adding handlers and assigning stuff just for hackings something into... We cannot know how much something like this breaks... just imagine if a user has already his own default-handler defined. Maybe it would be better to create a single document with all possible solutions and pro and cons? I have started to create such an overview at http://wiki.debian.org/Apache/WheezyMimeTypes but it is not finished yet. Feel free to add more infos/solutions/pros/cons. The page may come in handy for the Jessie, too. Good idea... I hope I'll find some time into looking at it... But in general... I'm a bit scared that we clash into the release of wheezy with neither a perfect nor an at-least-somewhat-secure solution. So question the the group is: Should we continue with investigating in a perfect solution (and that wiki seems to somewhat go into that direction)... or should we simply admit there's a shitty situation for wheezy... add the necessary release notes with big fat exclamation marks... and shame ourselves till we come up with the uber-solution in jessie? ;-) Christoph: For mod-fastcgi/mod-fcgid, the file.fcgi.foo problem is somewhat mitigated that they require Options ExecCGI, too. And AFAICS that is not set by default. Any opinions if this is good enough for wheezy? I lean towards yes, but maybe I am missing something. Well... phew... I mean don't get me wrong... nearly all what we do here is about teaching users and/or helping them not to shoot themselves... so in theory you're right and this is enough... on the other hand: Practise looks like this that users often have merely an idea what they do... and I'd feel better, if both mods also place some Files block around. Actually,... I'd even feel better if they stop automatically enabling things. And this is not my usual security-paranoid installed-packages-shouldn't-enable-their-stuff-automatically talking... it's rather that in this special cases (namely Apache)... they enable things globally for the whole server... which is (to my experience) rarely needed. We could help users from potential security troubles,... if we force them to decide in which context they want to enable things. But how to proceed now? In general, if we secure these two mods from the evil.fcgi.jpeg issue, we have the same problem as with PHP (there Ondřej added a according entry to NEWS and README.Debian) namely that we potentially break some setups (those from such devilish admins coming straight from hell and used http content negotiation in some way with their interpreted stuff. I personally think it's definitely worth! Then we have the options: a) Either just secure it with Files blocks around the diretives that add the handlers... b) or disable global per-default activation but still document in each of the two packages how to do it right. I'd vote for (b). Depending on what you guys from the Apache Maintainer group say... I'd open respective bugs, and help Tatsuik and Taku with documentation and stuff... Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hi Charles. On Thu, 2012-10-11 at 09:06 +0900, Charles Plessy wrote: Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? I would say no, well at least not if we also want to use these media types later on in Apache to select something for interpretation. The problem with using /etc/mime.types via the TypesConfig directive in Apache is the usual with Apache: Most mod_mime directives (and maybe also others) will assign a media type if just any extension (i.e. also the foo in file.foo.bar) matches. The usual way around this is to place these directives in e.g. Files ?*.bar /Files or FilesMatch ^.+\.bar$ /FilesMatch TypesConfig however is a server wide scope directive, so this won't work here. As I mentioned previously, I think it's very dangerous to use TypesConfig per default. It's evil by design and people should need to intentionally enable it (and then hopefully know what they're doing). I really think we should not fiddle around with mime-types anymore, or better: I think we should stop using it to enable files for interpretation, even if that may break now some setups. Of course we should provide release notes hints on how to make them work again, which is usually quite easy. Also, please consider that people using advanced stuff like FastCGI can be expected to know what they're doing. I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. It would of course be nice, if we could postpone this to jessie, but... I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Right now I see no way to prevent the evil.php.jpeg issue otherwise. And note especially, that also FastCGI is in principle vulnerable to this. Though I haven't checked right now, how they actually select the PHP files for interpretation (which may or may not prevent the issue). easy way to adjust the priority of the SetHandler statement of php5_cgi.conf I think it's determined by the loading order... which makes it basically impossible IMHO to really make sure it gets loaded as we want it to. in a way that does not break FastCGI configurations. Even then we need to check whether fastcgi or fcgid are vulnerable to the evil.php.jpeg isseu. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Oh and one more thing (even though this is PHP unrelated): Maybe I misunderstand something but it seems both: libapache2-mod-fcgid, which uses: IfModule mod_fcgid.c AddHandlerfcgid-script .fcgi FcgidConnectTimeout 20 /IfModule and libapache2-mod-fastcgi, which uses: IfModule mod_fastcgi.c AddHandler fastcgi-script .fcgi #FastCgiWrapper /usr/lib/apache2/suexec FastCgiIpcDir /var/lib/apache2/fastcgi /IfModule are highly vulnerable to the evil.fcgi.jpeg issue... Can you confirm this? Cause then we need to open some critical bugs. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: This sucks. In hindsight, maybe the mime.types change should have been deferred until we ugrade to apache 2.4 and people have to adjust their configs anyway. But I think it's too late now to go back. And leaving the *.php.foo problem there for yet another release cycle would not have been a good solution either. Le Mon, Oct 08, 2012 at 03:38:10PM +0200, Ondřej Surý a écrit : Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. Hello Ondřej, Stefan, and everybody, Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Of course, it is even better if there is an easy way to adjust the priority of the SetHandler statement of php5_cgi.conf in a way that does not break FastCGI configurations. What do you think ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20121011000648.gc27...@falafel.plessy.net
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Stephan, thanks for the input. Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. O. On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: Hi Ondřej, I also cannot think of any configuration that would make everyone happy. At the moment, I fear this can only be solved by more documentation. Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5, e.g. before The standard configuration now also... : WARNING: The new configuration may override other configuration directives you may have added locally for the .php extension, for example for FastCGI processing. This behavior is caused by FilesMatch configuration sections overriding directives appearing in global server or VirtualHost scope. You should review and test your configuration and verify that your php scripts work as expected. The README.Debian or the wiki page you are already pointing to should then list likely candidates for problematic local configurations, like AddHandler fcgid-script .php. Maybe it could also say, that if all else fails and the user is willing to live with the *.php.foo problem, the old behavior can be restored by replacing etc/apache2/mods-available/php5_cgi.conf with something like AddType application/x-httpd-php phtml pht php php3 php4 php5 AddType application/x-httpd-php-source phps to get the old behavior back. What do you think? This sucks. In hindsight, maybe the mime.types change should have been deferred until we ugrade to apache 2.4 and people have to adjust their configs anyway. But I think it's too late now to go back. And leaving the *.php.foo problem there for yet another release cycle would not have been a good solution either. Cheers, Stefan -- Ondřej Surý ond...@sury.org -- 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/caljhhg-kehf6oknxwww_tq-trho+eqz+sod4479tcn9sum1...@mail.gmail.com
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hi, Ondřej Surý: Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? IMHO that would be a good idea. (Subject to testing …) -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, 2012-10-08 at 15:38 +0200, Ondřej Surý wrote: Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? I'm a bit unsure how/why that would fix the general problem? Perhaps you can elaborate a bit more on what your ideas are :) I haven't looked into absolute details but I think the main problem here is, that different SAPIs use different fixed handler-names. And even if all would use the same,... we'd have a problem, namely how to select the right one. That I think would justify change in the mime-support package. Too much breakage on every front now. Well... I think it's quite dangerous to again play around at mime-support. I mean we all know the problems arising from there,... not only the security issues like foo.php.jpeg, but also that we are again quite dependant on some other package. Admittedly, we're in quite a shitty situation now, so close to wheezy, but I somewhat agree to Stefan, in better just adding some more release notes. The next step would/could be to think about post-wheezy release goals for the overall PHP framwork in Debian. Which includes IMHO: - unifying as much (apache) configs as possible for the different SAPIs - other packages (i.e. packaged PHP programs) should not rely on PHP being activated by the php packages (especially not globally), but should rather give the user a debconf option on where (which webserver) to activated it how (always only local scope,... and questioning which SAPI) - make the different SAPIs co-exist more out-of-the-box...which i.e. also addresses this very bug The ideal state would be that one can enable all SAPIs in one Apache instance and even use them in the same vhost... differentiating per Directory (well at least as far as this is possible for all the SAPIs). Maybe this requires that we patch things like mod_f(ast)cgid ... to use other handler names. I have not yet an idea how all this could be achieved. But back to this very bug: If we say we solve this for now, by just adding release notes as Stefan proposed... then there is still one important thing left. Namely those I asked in the mails from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#59 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#69 May we run into the problem, that again, files are accidentally served (as files)? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, 2012-10-08 at 22:42 +0200, Ondřej Surý wrote:
Basically it would bring the old behaviour back while not mangling
with custom Set/AddHandler directives in the apache. Remember the
php5_cgi.{load,conf} hack was introduced after decision to fix this
only in Apache - which in turn caused more breakage in custom setups
then expected.
Ah... so you mean adding e.g. application/x-php (or whatever) but don't
use this with mod_php or normal CGI (where we'd still keep the
php5_cgi.{load,conf} then?)
Not sure about that...
I mean these types were removed for good reasons... and especially in
Apache people should at best stop using /etc/mime.types at all.
I somehow fear a bit,... that we might just end up with other new
(security?) issues being added.
Putting parts of PHP configuration (well I know it's not really that)
in other packages seems problematic to me IMHO the cleanest solution
would be, if PHP-packages add the necessary basic configuration to
installed webservers (ideally not only to Apache)... without activating
PHP.
The later then being done manually by the admin, or (more or less)
automagically by other packages.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Bug#671260: Fwd: Re: seriously
[forwarding to #671260, that's better than #669796] Hi, On 02.05.2012 21:13, Nicholas Bamber wrote: P.S. It is slightly odd that to *build* a package containing a pure perl CGI script I should need to install an actual apache2 instance. If apache2-dev could be split so that dh_apche2 and the debhelper stuff were in a separate arch:all package that does NOT depend on apache2 that would be good I think. that's on our list already. This is why we ask people to build-depend on dh-apache2 explicitly. For now that's a virtual package provided by apache2-dev but this might change in future. We may even try to include it in debhelper proper if Joey agrees with. We didn't yet because we still need to think how dh_apache2 should get its information from if no apache package is installed. signature.asc Description: OpenPGP digital signature
[Fwd: Bug#666828: libapache2-mod-rivet: sourceful transition towards Apache 2.4]
Hi
a few days after libapache2-mod-rivet had been uploaded to 'experimental'
bug #666828 filed to force a rebuild from source was reopened.
Andreas Beckmann ran a piuparts test and the package
postinst script failed because a2enmod (shipped with apache2) was missing,
apparently contradicting one of the transition recommendations
* Do NOT depend on apache2, apache2-common or any other real apache2
package in your binary module package. Depend on our virtual
apache2-api-20120211 package only!
libapache2-mod-rivet binary package depends on ${misc::Depends} as stated
in the Debian Apache policy
The package builds on every architecture except for mipsel (still
uncompiled and waiting in BD-Unistallable status) and hurd-i386 where
it doesn't compile for a problem to be investgated and apparently
connected with the autotools toolchain specific to the experimental
distribution for that architecture.
regards
-- Massimo
Forwarded Message
From: Andreas Beckmann deb...@abeckmann.de
Reply-to: Andreas Beckmann deb...@abeckmann.de, 666...@bugs.debian.org
To: Debian Bug Tracking System 666...@bugs.debian.org
Subject: Bug#666828: libapache2-mod-rivet: sourceful transition towards
Apache 2.4
Date: Sat, 21 Apr 2012 14:43:51 +0200
Package: libapache2-mod-rivet
Version: 2.0.4-2
Followup-For: Bug #666828
Hi,
during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.
From the attached log (scroll to the bottom...):
Selecting previously unselected package libapache2-mod-rivet.
(Reading database ... 10186 files and directories currently installed.)
Unpacking libapache2-mod-rivet (from
.../libapache2-mod-rivet_2.0.4-2_amd64.deb) ...
Setting up libapache2-mod-rivet (2.0.4-2) ...
/var/lib/dpkg/info/libapache2-mod-rivet.postinst: 48:
/var/lib/dpkg/info/libapache2-mod-rivet.postinst: a2enmod: not found
dpkg: error processing libapache2-mod-rivet (--configure):
subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
libapache2-mod-rivet
cheers,
Andreas
--
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/1335137106.6377.20.ca...@pokemon.bandasalute.it
Bug#476580: Fwd: Re: apache2 segfault on start
forwarding to the bug report -- Forwarded Message -- Subject: Re: apache2 segfault on start Date: Freitag, 18. April 2008 From: Vitaliyi [EMAIL PROTECTED] To: Stefan Fritsch [EMAIL PROTECTED] suddenly problem disappeared and I cannot reproduce it. If you haven't done an upgrade since then, you can just use the core dump you attached to the bug report. Just install the packges and run gdb as described in README.backtrace. No need to create another core dump. gdb /usr/sbin/apache2 /tmp/core GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu... warning: Can't read pathname for load map: Input/output error. warning: .dynamic section for /usr/lib/libaprutil-1.so.0 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /usr/lib/libapr-1.so.0 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /usr/lib/libsqlite3.so.0 is not at the expected address (wrong library or version mismatch?) Reading symbols from /usr/lib/libpcre.so.3...done. Loaded symbols for /usr/lib/libpcre.so.3 Reading symbols from /usr/lib/libaprutil-1.so.0...Reading symbols from /usr/lib/debug/usr/lib/libaprutil-1.so.0.2.11...done. done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /usr/lib/libapr-1.so.0...Reading symbols from /usr/lib/debug/usr/lib/libapr-1.so.0.2.12...done. done. Loaded symbols for /usr/lib/libapr-1.so.0 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libldap_r.so.2...done. Loaded symbols for /usr/lib/libldap_r.so.2 Reading symbols from /usr/lib/liblber.so.2...done. Loaded symbols for /usr/lib/liblber.so.2 Reading symbols from /usr/lib/libdb-4.4.so...done. Loaded symbols for /usr/lib/libdb-4.4.so Reading symbols from /usr/lib/libpq.so.5...done. Loaded symbols for /usr/lib/libpq.so.5 Reading symbols from /usr/lib/libsqlite3.so.0...done. Loaded symbols for /usr/lib/libsqlite3.so.0 Reading symbols from /usr/lib/libexpat.so.1...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libgnutls.so.13...done. Loaded symbols for /usr/lib/libgnutls.so.13 Reading symbols from /usr/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libldap_r-2.4.so.2...done. Loaded symbols for /usr/lib/libldap_r-2.4.so.2 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Reading symbols from /usr/lib/libgpg-error.so.0...done. Loaded symbols for /usr/lib/libgpg-error.so.0 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libgcrypt.so.11...done. Loaded symbols for /usr/lib/libgcrypt.so.11 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /usr/lib/liblber-2.4.so.2...done. Loaded symbols for /usr/lib/liblber-2.4.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from
Bug#397239: [Fwd: Re: apache2: Since ugrading to 2.2.3-3, webdav doesn't work: Invalid command 'AuthDigestFile']
Hi Andreas ThX for your hint ! In Apache2.2, the directives for mod_auth_digest have changed: You have to define a Provider |AuthDigestProvider (i.e file) and then you have to use the AuthUserFile directive to tell the (file-)provider where the file is. I also needed to add the links of the mod's: authn_file.load authz_user.load ...to the mods-enabled directory to complete the upgrade to 2.2. All the people that are using the auth_digest module will have problems with their upgrade. | (see also: http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html) Cheers Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383615: Fwd: Bug#383615: split out libaprutil1-dev sqlite, pgsql, ldap dependencies
-- Forwarded message -- From: gmu 2k6 [EMAIL PROTECTED] Date: Aug 19, 2006 1:50 PM Subject: Re: Bug#383615: split out libaprutil1-dev sqlite, pgsql, ldap dependencies To: debian-apache@lists.debian.org On 8/19/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: * gmu 2k6 | I would like some of the libaprutil1-dev dependencies to be split | out to additional packages ala php-mysql so that the following | dependencies are optional and only installed by those who need. Why? I'm not inclined to do it for just a few files; disk space is cheap and even more so on development systems. it's not about disk space, it's about installing as few packages as possible to have a clean selection with a minimum of update needs/problems. if Debian is the universal OS then it should allow clean installs without falling back to apt-build. one of the major reasons I'm using Debian out of the binary distros is that it allows me to install a minimal system and let me decide which packages I want, most of the time. although we are much better than RPM based distros which don't seem to have a Suggest field some packages are not done right regarding the features one can to enable/disable during runtime. just take the libwxgtk packages which requires esound, this is only so because the packager did not split the package in -base, -sound, etc. the point here is that wxWindows is most likely used for the GUI abstraction and not for sound. insert `apt-cache depends xchm` here. I'm using libaprutil1-dev to build Subversion =1.3.x/1.4(rc) and the dependency I saw with it is similar to installing some font or graphics libs which require the whole Xorg baselibs chain. I build Subversion, because Apache 2.2 is not in etch/sid yet and so it is built against APR 1.0.x right now my own -DLARGEFILE aka APR 1.2.x Subversion. btw, this does not mean I'm using mod_dav_svn, svnserve is all I need as of know. so what do you think? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: Do apache modules need an RPATH?
I asked this question on apache-modules, but havent gotten an answer yet.. how does debian deal with this? Do we add an override for the lintian warning, or do something else? I was suprised to find that the debianized apxs2 adds the -rpath option... I'm wondering if it's actually needed by httpd... Thanks, Tyler - Forwarded message from Tyler MacDonald [EMAIL PROTECTED] - My apache module is being compiled with an RPATH by APXS: W: libapache2-mod-bt: binary-or-shlib-defines-rpath ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib Is that needed? Is there any way to tell APXS to remove -rpath from it's libtool arguments? Thanks, Tyler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - End forwarded message - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(fwd) Invitation to ApacheCon US, San Diego, 12-14 December [EMAIL PROTECTED]
Hi! Anyone interested to be at the ApacheCon US for Debian, maning a booth, answering questions? I might add, that we had a Debian booth at the ApacheCon Europe this summer [1] and it was considered to be a usefull and easy job [2]. Links: 1: http://www.debian.org/events/2005/0718-apachecon 2: http://www.debian.org/events/2005/0718-apachecon-report Yours sincerely, Alexander - Forwarded message from Lars Eilebrecht [EMAIL PROTECTED] - From: Lars Eilebrecht [EMAIL PROTECTED] Subject: Invitation to ApacheCon US, San Diego, 12-14 December To: [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 14:04:36 +0100 Hi, I'm with the Apache Software Foundation and the ApacheCon planning team. On behalf of the ASF I would like to invite the Debian project to take part in the Open-Source area at the ApacheCon expo (12-14 December, San Diego). See http://apachecon.com for further details. I know there isn't much time left, but it would be really great if you have people available to staff a booth at the conference. We had a Debian booth at ApacheCon Europe in Stuttgart this year and people really liked it! Please contact [EMAIL PROTECTED] if you are interested. You can reply to me as well, but please note that I'm more or less offline next week. Best Regards... -- Lars Eilebrecht [EMAIL PROTECTED] --- [ CIPHIRE DIGITAL SIGNATURE ] --- Q2lwaGlyZSBTaWcuAjhldmVudHNAZGViaWFuLm9yZwBsYXJzQGFwYWNoZS5vcmcAZW1ha WwgYm9keQBIAgAAfAB8AQAAAOdohENIAgAA3QIAAgACAAIAIKMPuCOhdTAug+ZGVU qkEC40y5gGdtqyJ0l2WKqQw8iiAQAHJK/YDQoj00AWlzpnM/IrUXeXVBOhEqZUGME3QPa z4ynJytugpUNQv7qXZ4nb+0PnFmkc0R1eUqcFmsqqf3cDPalvU2lnRW5k - [ http://www.ciphire.com/verify ] - - End forwarded message - signature.asc Description: Digital signature
(fwd) Debian-Projekt auf der ApacheCon? [EMAIL PROTECTED]
Hi! For those who don't understand german: Lars got in contact with us during LinuxTag last week, offering Debian a booth at the upcoming Apachecon in Stuttgart. I'm wont be able to do this myself. Any volunteers? - Forwarded message from Lars Eilebrecht [EMAIL PROTECTED] - From: Lars Eilebrecht [EMAIL PROTECTED] Subject: Debian-Projekt auf der ApacheCon? To: [EMAIL PROTECTED] Date: Sat, 25 Jun 2005 15:26:12 +0200 Hi Alexander, Deine Adresse war mir auf dem Debian-Stand auf dem LinuxTag genannt worden. Also, ich bin von der Apache Software Foundation und im Planungsteam fuer die ApacheCon Europe 2005, die vom 18-22 Juli in Stuttgart stattfindet (siehe www.apachecon.com). Wir wuerde Euch gerne einladen dort einen Messestand zu machen um das Debian-Projekt zu praesentieren. Der Stand waere natuerlich fuer Euch kostenlos. Die Expo der ApacheCon findet vom 20-22 Juli statt. Wuerde mich freuen, wenn das trotz der etwas kurzfristigen Anfrage noch klappen wuerde. ciao... -- Lars Eilebrecht [EMAIL PROTECTED] - End forwarded message - Yours sincerely, Alexander signature.asc Description: Digital signature
Bug#307567: [Fwd: [Fwd: Re: Bug#307567: apache2-common: Apache2 consumes 100% CPU after a few requests]]
[Sorry, I posted with the wrong email account] I'm not familiar with apache internals, nor LDAP, but I can try to help begin diagnosis. Thanks. Could you provide a strace of the process when it is in that state? (strace -p pid)? Maybe also a strace of the process beginning before it is in that state, and ending sometime after it has gone into that state. Here it is. I'm not familiar with bug reporting w/ Debian: I've gzipped the log, to keep this email small. If I should have sent it as plain ASCII, please let me know. Here's what I did to obtain this trace: /etc/init.d/apache2 start # use prefork ps ax | grep apache2 # to get the PIDs - 23224 to 23229 sudo strace -p 23224 ... -p 23229 21 | tee ~/apache2.strace I then run a small script that use wget to stress the webserver from another console, until the script got deadlocked (as the server does not answer the request when it consumes 100% CPU), then broke the strace execution (Ctrl+C) top # to get the PID of the process eating up the CPU time grep [pid] ~/apache2.strace | gzip -c apache2.strace.23229.gz I then restarted strace -p 23229, but strace does not show any other trace for this process. I'll come back later in another email with the GDB trace, if I manage to get it. Thanks for your support, Emmanuel apache2.strace.23229.gz Description: Binary data
Bug#231450: PHP 5 'make install' of Apache 2 SAPI fails to prepend module path with leading slash (fwd)
Please see the forwarded message below; the PHP development team says that this error is indeed caused by apxs2 and not by PHP 5 or its 'make install'. Best regards, Björn -- Forwarded message -- Date: Wed, 14 Jul 2004 18:18:16 +0200 From: PHP Bug Database php-bugs@lists.php.net To: [EMAIL PROTECTED] Subject: Bug #29157 [Opn-Bgs]: 'make install' of Apache 2 SAPI fails to prepend module path with leading slash ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=29157edit=2 ID: 29157 Updated by: [EMAIL PROTECTED] Reported By: bjorn dot wiberg at home dot se -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Debian GNU/Linux 3.0.0r2 (mixed) PHP Version: 5.0.0 New Comment: This is an apxs2 problem, not ours. Previous Comments: [2004-07-14 18:09:51] bjorn dot wiberg at home dot se Description: When running 'make install', the directive added to /etc/apache2/apache2.conf misses a leading slash (/) to the PHP 5 module. I do not know if this is due to an error in apxs2 or in the way PHP 5's 'make install' calls it, but it has been around for quite some time now. Furthermore, at least one other LoadModule directive must be present in /etc/apache2/apache2.conf before running 'make install', or apxs2 will fail to insert the line (it doesn't know where to put it), and the 'make install' fails. For this purpose I use: # Commented-out dummy LoadModule directive to give apxs2 a hint # about where to place new LoadModule directives (e.g. PHP) # # LoadModule dummy_module /usr/lib/apache2/modules/mod_dummy.so That way, the PHP 5 LoadModule directive gets inserted right after the (commented-out) dummy line. Reproduce code: --- 1. Configure PHP 5. I use the following directives: ./configure --enable-bcmath --enable-calendar --enable-dba --enable-dio --enable-embedded-mysqli --enable-exif --enable-ftp --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --enable-memory-limit --enable-pcntl --enable-shmop --enable-soap --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-wddx --enable-yp --enable-zend-multibyte --with-apxs2=/usr/bin/apxs2 --with-bcmath --with-bz2 --with-curl --with-db4 --with-freetype-dir=/usr/lib --with-gd --with-gettext --with-gmp --with-iconv --with-inifile --with-jpeg-dir=/usr/lib --with-ldap --with-libxml-dir=/usr/lib --with-mime-magic --with-mysql --with-mysql-sock --with-ncurses --with-openssl --with-png-dir=/usr/lib --with-pspell --with-snmp --with-tiff-dir=/usr/lib --with-ttf --with-xmlrpc --with-xpm-dir=/usr/lib --with-xsl --with-zlib --with-zlib-dir=/usr/lib 2. Compile PHP 5 with 'make'. 3. Run 'make install'. 4. View /etc/apache2/apache2.conf. Expected result: LoadModule php5_module /usr/lib/apache2/modules/libphp5.so Actual result: -- LoadModule php5_moduleusr/lib/apache2/modules/libphp5.so
reply to Ralf's questions (fwd)
If I comment out all the perl references in all the configs... apache loads... So now I just need to findout which perl section of my configs it's choking on. Why only after an upgrade? Maybe it's not apache... but a perl library or something? -- Forwarded message -- Date: Tue, 8 Jun 2004 13:00:21 -0400 (EDT) From: William R. McDonough [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], debian-apache@lists.debian.org Subject: reply to Ralf's questions Hmm, something seems to feed '/usr/sbin' to a perl interpreter. Do you by any chance have mod_perl installed and maybe a 'PerlRequire' that loads the wrong file? httpd.conf:IfModule mod_perl.c httpd.conf: Alias /perl/ /var/www/perl/ httpd.conf: Location /perl httpd.conf:SetHandler perl-script httpd.conf:PerlHandler Apache::Registry httpd.conf:Options +ExecCGI httpd.conf: /Location httpd.conf:/IfModule mime.types:application/x-perl pl pm modules.conf:LoadModule perl_module /usr/lib/apache/1.3/mod_perl.so
Re[6]: Fwd: 3
. , . 100 .. : .. : ; ; ; ; ; ; . .. : , , ; . www.listening.ru ! E-mail: [EMAIL PROTECTED] /: 8-390-42-3-32-32 blanketing equalizers obstacles Edmonton unwilling denouncing debugging Frederick Milan Can
Fwd: !
, 3-. . 250 - 12:00 18:00 ( 16:00) .
[RHSA-2003:405-01] Updated apache packages fix minor security vulnerability (fwd)
Dear Sir/Madam, I didn't see an updated from debian regarding this issue, did I miss it? or does the problem not apply to debian installations? Floris -- Forwarded message -- Date: Thu, 18 Dec 2003 04:28 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], bugtraq@securityfocus.com, full-disclosure@lists.netsys.com Subject: [RHSA-2003:405-01] Updated apache packages fix minor security vulnerability Red Hat Security Advisory Synopsis: Updated apache packages fix minor security vulnerability Advisory ID: RHSA-2003:405-00 Issue date:2003-12-18 Updated on:2003-12-18 Product: Red Hat Linux Keywords: Apache httpd ASF Cross references: Obsoletes: CVE Names: CAN-2003-0542 - 1. Topic: Updated Apache packages that fix a minor security issue are now available for Red Hat Linux 7.1, 7.2, and 7.3. 2. Relevant releases/architectures: Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 3. Problem description: The Apache HTTP server is a powerful, full-featured, efficient, and freely-available Web server. An issue in the handling of regular expressions from configuration files was discovered in releases of the Apache HTTP Server version 1.3 prior to 1.3.29. To exploit this issue an attacker would need to have the ability to write to Apache configuration files such as .htaccess or httpd.conf. A carefully-crafted configuration file can cause an exploitable buffer overflow and would allow the attacker to execute arbitrary code in the context of the server (in default configurations as the 'apache' user). The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0542 to this issue. All users of the Apache HTTP Web Server are advised to upgrade to the applicable errata packages, which contain back-ported fixes correcting this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. If up2date fails to connect to Red Hat Network due to SSL Certificate Errors, you need to install a version of the up2date client with an updated certificate. The latest version of up2date is available from the Red Hat FTP site and may also be downloaded directly from the RHN website: https://rhn.redhat.com/help/latest-up2date.pxt 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 108639 - CAN-2003-0542 Local buffer overflow in mod_alias, mod_rewrite 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/apache-1.3.27-3.7.1.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/apache-1.3.27-3.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/apache-devel-1.3.27-3.7.1.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/apache-manual-1.3.27-3.7.1.i386.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/apache-1.3.27-3.7.2.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/apache-1.3.27-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/apache-devel-1.3.27-3.7.2.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/apache-manual-1.3.27-3.7.2.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/apache-1.3.27-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/apache-devel-1.3.27-3.7.2.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/apache-manual-1.3.27-3.7.2.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/apache-1.3.27-4.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/apache-1.3.27-4.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/apache-devel-1.3.27-4.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/apache-manual-1.3.27-4.i386.rpm 7. Verification: MD5 sum Package Name -- 818f5bd5242b4f953e6b0829a80e1e3b 7.1/en/os/SRPMS/apache-1.3.27-3.7.1.src.rpm 2f3f4e3613065582f20c5d246f8f8ded 7.1/en/os/i386/apache-1.3.27-3.7.1.i386.rpm 852848c76748a17e8915ba5bf63cd161 7.1/en/os/i386/apache-devel-1.3.27-3.7.1.i386.rpm 2203e87dc9c7822dbc6c3ae46fb22142 7.1/en/os/i386/apache-manual-1.3.27-3.7.1.i386.rpm
Fwd: libapache-mod-perl in 'Testing'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Begin forwarded message: From: Daniel Jacobowitz [EMAIL PROTECTED] Date: January 02, 2004 18:35:13 EST To: Branden Moore [EMAIL PROTECTED] Subject: Re: libapache-mod-perl in 'Testing' On Fri, Jan 02, 2004 at 04:55:58PM -0500, Branden Moore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan, With perl 5.8.2 moving into 'testing', mod_perl.so seems to be segfaulting. My solution was to build libapache-mod-perl from the debian sources, and apache seems to be working find now. My apologies if you already knew about this. Sorry, I don't maintain mod_perl any more - try [EMAIL PROTECTED] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/9gF+0HulGszUTxERAoP2AJ0ez+uFJFQWnZTPout66JjVqq7CbQCgvuNg s8jB3P9Y0nvwc2Ht2Pj/1oI= =54Ek -END PGP SIGNATURE-
Re: Fwd: libapache-mod-perl in 'Testing'
On Fri, Jan 02, 2004 at 06:40:43PM -0500, Branden Moore wrote: With perl 5.8.2 moving into 'testing', mod_perl.so seems to be segfaulting. My solution was to build libapache-mod-perl from the debian sources, and apache seems to be working find now. this bug's been reported a dozen times over by now. it's not our fault. perl got pushed into testing and the corresponding mod_perl didn't. once it migrates the problem will be solved. until then we can expect hordes of people using testing to treat the BTS as write-only. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
