Re: Bug#224128: apache: I can repeat this behaviour and can supply a strace -f
Hi, On Mon, 23 Feb 2004 [EMAIL PROTECTED] wrote: RE: http://lists.debian.org/debian-apache/2003/debian-apache-200312/msg00229.html Hey Fabio, Reading this bug you point out that this is a known issue with PHP4. Can you give me a link/URL at bugs.php.net where this is open? I just spent the past hour looking and have yet to find anything related to this problem. If you dont know right off hand n/p. I'm not asking you to spend much time looking this up. I simply cant find where this is being addressed. please do not mail me directly for apache or debian related question, in future use the mailing list where all the maintainers are subscribed. The bug has been hunted down to a problem in libcrypto that for some reason is mapped/unmapped uncorrectly, probably due to a bug in the linker. We are actively working on the problem as well as we can reproduce it on a regular base now. For other references see to http://bugs.debian.org/src:php4 and look for php4-imap. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#234650: Looks like version bit rot
On Wed, 25 Feb 2004, Phil Karn wrote: It seems that things must have changed just enough in apache-ssl for my previous httpd.conf file to stop working. What exactly? This statement is way too generig for me to understand if there is a problem and where is located. In the process I discovered some changes in the currently distributed httpd.conf file that may break existing practices. For example, aliases are provided that remap /icons/ and /images/ to directories under /usr/share; this will break web pages that have their own images and icons directories. These should probably be disabled by default. Configurations are provided as examples. They cannot fit all users. It is simply impossible. The aliases in the examples are there to match FHS. If you use a different setup it is your responsability to change them. (considering that you have reinstalled from scratch) On upgrades these Aliases are not modified and /etc/apache-ssl/suggested_correction will indicate that there is a different between the defaults and your custom setup. Other changes are problematical since they may also break existing practice, but a case can be made for them because of increased default security. E.g., the currently distributed httpd.conf file disables the generation of directory listings. I'm not sure if this should be considered a bug or not. You get promped for the list of modules that you want to load and dir listing is enabled. Still your responsability to configure the modules you need. We cannot guess them and neither we want to enable all of them by default like other distros do. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#234731: /etc/logrotate.d/apache should use invoke-rc.d
tags 234731 + pending stop On Wed, 25 Feb 2004, Loic Minier wrote: Package: apache Version: 1.3.29.0.1-5.0.ipv6.r1 Even if this version is NOT supported by debian, the change was already in our cvs. Next do NOT report bugs against packages that are shipped from other archives. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#235304: apache exits silently without error or deleting /var/run/apache.pid
Are you using php? If you disable it does apache start? Otherwise please send us asap your config files. Thanks Fabio On Sat, 28 Feb 2004, Neil Williams wrote: Package: apache Version: 1.3.29.0.1-5 Severity: grave Tags: sid Justification: renders package unusable After the most recent cron-apt update on testing, apache simply fails to start but gives no error reports. /var/run/apache.pid is not deleted. No syntax changes or errors in httpd.conf. Trying to restart apache complains about existence of the pid file but again exits silently. apachectl start appears to show a successful start but ps waux shows no apache processes. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.23-1-686 Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.29.0.1-5 Support files for all Apache webse ii debconf 1.4.11 Debian configuration management sy ii dpkg1.10.18.1Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-11Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-6 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.25-1 MIME files 'mime.types' 'mailcap ii perl [perl5]5.8.3-2 Larry Wall's Practical Extraction -- debconf information: apache/server-name: localhost apache/document-root: /var/www apache/server-port: 80 * apache/enable-suexec: false apache/init: true apache/server-admin: [EMAIL PROTECTED] (garfield.codehelp is an internal address only, use [EMAIL PROTECTED] or [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#235304: apache exits silently without error or deleting /var/run/apache.pid
reassign 235304 php4 stop Hi Neil, there are some known problems in php4 at the moment. Are you using the php4-imap extension? It is known to have some problems and a workaround is either to disable the extension or to load libapache-mod-ssl even without any https page. If this is not the case Steven (the php4 maintainer in CC) will ask you more specific information. I am reassigning this bug to php4 in the meanwhile. Thanks Fabio On Sat, 28 Feb 2004, Neil Williams wrote: On Saturday 28 February 2004 4:01 pm, Fabio Massimo Di Nitto wrote: Are you using php? If you disable it does apache start? Otherwise please Yes. Commenting out the line: #LoadModule php4_module /usr/lib/apache/1.3/libphp4.so in /etc/apache/modules.conf did allow apache to restart. However, 90% of my apache work is done in PHP. :-) Should I report this as a bug in PHP - or has that been done? Is the problem between the latest apache and php known? Is there a fix? -- Neil Williams = http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Output from gpg gpg: Signature made Sat Feb 28 18:01:44 2004 CET using DSA key ID 28BCB3E3 gpg: Good signature from Neil Williams (CodeHelp) [EMAIL PROTECTED] gpg: aka N Williams (CodeHelp) [EMAIL PROTECTED] gpg: aka Neil Williams (general) [EMAIL PROTECTED] gpg: aka Neil Williams (Linux User Group) [EMAIL PROTECTED] gpg: aka Neil Williams (Devon and Cornwall LUG) [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 4CD4 6644 C105 48ED CA28 EC36 8801 094A 28BC B3E3 -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#235976: apache: Apache overwrites local configuration
Hi Allard, On Wed, 3 Mar 2004, Allard Hoeve wrote: Package: apache Version: 1.3.29.0.1-5 Severity: important Hello All, Whenever apache gets installed, reinstalled, upgraded or reconfigured, it overwrites my configuration in /etc/apache. Yes and this bug is already fixed in our CVS. Perhaps my setup is a bit exotic, so I will explain the situation: I have several Apache servers that have mostly identical configurations. To reduce redundancy, we placed the configuration files on an NFS share. The local directory /etc/apache/ now contains a local.conf that contains any configuration directives that should remain local and a symlink from /etc/shared/apache/httpd.conf to /etc/apache/httpd.conf. The shared configuration file includes the local.conf file and all is well. Thanks for sharing this erotic setup with us.. we never actually considered the possibility to have httpd.conf as a symlink. This raises two questions: a) Should the apache postinst scripts overwrite a configuration file with a new file with identical content? No and this is already fixed in CVS. b) Should the apache postinst scripts remove a symlink and replace it with a plaintext file? No. and this is something we need to consider. To avoid confusions you spotted 2 problems here: a) configuration files are overwritten (that it will be fixed in the next upload) b) if httpd.conf is a symlink it will be replaced (and this require some attention to us). Thanks Fabio PS of course we will keep you informed -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#229000: apache-common: mod_bandwidth directory needs clearing
On Fri, 5 Mar 2004, Jeff Breidenbach wrote: This has been pending for some time now. What can I do to help make an upload happen? You can help up fixing some other bugs and pretesting packages from cvs.raw.no. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#229505: apache-ssl: post-installation script fails (still)
reassign 229505 ssl-cert stop On Sat, 6 Mar 2004, Paul Slootman wrote: reopen 229505 thanks On Sun 25 Jan 2004, Fabio Massimo Di Nitto wrote: this was a bug in ssl-cert that has been fixed in sid already and it should enter testing in a couple of days. It's now March, and when doing a fresh install of testing on a box, I still get this error: 7830:error:0D07A098:asn1 encoding routines:ASM1_mbstring_copy:string too short:a_mbstr.c:147:minsize=1 I left the organisationalUnitName field empty, it doesn't apply. Versions involved: apache-ssl 1.3.29.0.1-3 ssl-cert 1.0-7 As it's still not resolved, I'm reopening this bug now. If it belongs to ssl-cert, fine; reassign (although it's starting to look like using ssl-cert is a bug in itself, if I look at the open bug reports there). Please don't close the bug before it's actually fixed... Paul Slootman -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#236757: apache: postinst script fails
Hi Wolfgang, according to ucf documentation --debconf-ok is supported from version 0.28 and there is a specific dependency on it in apache-common. Can you kindly show us the error you get? Thanks Fabio On Sun, 7 Mar 2004, Wolfgang Sourdeau wrote: Package: apache Version: 1.3.29.0.2-1 Severity: grave Hi, In /usr/share/apache/postinst.common:do_ucf(), there are two calls to ucf --debconf-ok. However it appears the version of ucf available in sid does not support that flag. Making apache unable to install correctly. Wolfgang -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.3 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to fr_CA.ISO8859-1) Versions of packages apache depends on: ii apache-common 1.3.29.0.2-1 Support files for all Apache webse ii debconf 1.4.13 Debian configuration management sy ii dpkg1.10.18.1Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-12Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-2 Larry Wall's Practical Extraction -- debconf information excluded -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#236757: apache: postinst script fails
On Mon, 8 Mar 2004, Wolfgang Sourdeau wrote: La plume légère, vers Mon, Mar 08, 2004 at 06:39:28AM +0100, heure d'inspiration, Fabio Massimo Di Nitto écrivait en ces mots: Hi Wolfgang, according to ucf documentation --debconf-ok is supported from version 0.28 and there is a specific dependency on it in apache-common. Can you kindly show us the error you get? Hi Fabio, I thought I had version 0.30 of ucf installed but for whatever reason, it was version 0.27. So it must have been a problem on my system that caused that error. Closing this bug... Thanks for your prompt answer nonetheless! Please do not close this bug. I don't understand why even if ucf is forced with version = 0.28 apt-get didn't complain about it. In any case -1 still has some problems, expect -2 tomorrow or so. Thanks for reporting! Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: vers 1.3.29.0.2-1
Hi Peter, know problem. It is already fixed in -2 (uploaded this morning) Fabio On Mon, 8 Mar 2004, Peter J Thompson wrote: when upgrading to1.3.29.0.2-1, package writes additional files to /etc/apache/conf.d with .dist attachment preventing apache from starting - removing files makes everything ok -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#135717: severity is incorrect
severity 135717 normal stop Inflating severities when not necessary is quite annoying. The fact that the conf.d scanning code doesn't ignore .dpkg files can cause severe breakage when upgrading. Feel free to provide a patch to support file exclusion. If upstream did not implement it isn't Debian or my fault. (E.g., if you change the mod ssl config file apache will refuse to start the next time you upgrade because it tries to bind to port 443 twice, once in your config file and once in the .dpkg file.) Documenting this as a feature is not a sufficient response for breaking on a normal process (upgrading) within debian. The bug should arguably be critical for breaking unrelated software. (E.g., anything that is provided via the web server.) This is already fixed in -2 that has been uploaded this morning. You are running sid. Things can go wrong even if noone wants it. Waiting for your patch Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#236932: mf typo in /usr/share/apache/postinst.common
tags 236932 + pending Hi Norbert! thanks for spotting it! Fabio On Mon, 8 Mar 2004, Norbert Kiesel wrote: Package: apache Version: 1.3.29.0.2-2 Severity: important Tags: sid Hi, /usr/share/apache/postinst.common has a typo (mf instead of mv) which results in calling metafont. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.4-rc2 Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.29.0.2-2 Support files for all Apache webse ii debconf 1.4.14 Debian configuration management sy ii dpkg1.10.19 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-12Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-2 Larry Wall's Practical Extraction -- debconf information: * apache/enable-suexec: false apache/server-name: localhost apache/document-root: apache/server-port: apache/init: false apache/server-admin: -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#236882: apache-perl: The patch from bug 226131 is the culprit!
tags 236882 + pending stop Ok I am temporary reverting the patch even if it is already upstream for the next release of mod_perl. The submitter of 226131 is in CC but i didn't receive any information from him yet. Fabio On Mon, 8 Mar 2004, Dave Rolsky wrote: Package: apache-perl Version: 1.3.29.0.2-1 Severity: normal Followup-For: Bug #236882 I rebuilt the apache packages from the Debian source without the patch provided in bug report 226131, and it starts up fine. Looking at the code being patched, I have absolutely no idea why it would cause a segfault with the patch applied. However, I think the patch may just be incorrect. It's testing if if RETVAL is SvOK, but _all_ SVs are SvOK, whether they are the Nullsv global, or a new SV created via newSV! The point of calling SvOK is to test if the variable in question is an SV* at all, not to test its value. The code is basically broken, because it needs to check to see if it the per-dir-config table contains the given key. If not, it should look at the server's table, I believe. Frankly, I think the original bug (re: dir_config) is _far_ less severe than a segfault, and should be backed out. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=C, LC_CTYPE=C Versions of packages apache-perl depends on: ii apache-common 1.3.29.0.2-1 Support files for all Apache webse ii debconf 1.4.13 Debian configuration management sy ii dpkg1.10.18.1Package maintenance system for Deb ii libapache-mod-perl 1.29.0.2-1 Integration of perl with the Apach ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-12Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii libperl5.8 5.8.3-2 Shared Perl library. ii mime-support3.26-1 MIME files 'mime.types' 'mailcap -- debconf information: apache-perl/old-pidfile-set: * apache-perl/server-port: 80 * apache-perl/init: true * apache-perl/enable-suexec: false * apache-perl/document-root: /var/www * apache-perl/upgrade-from-apache-conflict: * apache-perl/server-name: localhost * apache-perl/server-admin: [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: trouble with install APACHE-SSL 1.3.290.2-2
Hi Andreas,
there is a typo in the postinst that might be the reasons of all
these troubles. -3 is on the way.
Fabio
On Tue, 9 Mar 2004, Andreas wrote:
Hi there,
Hi
i just installed new apache-ssl 1.3.29.0.2-2
and can not enter into HTTPS site - i was use old config file ...and can`t
i was there use auth files , group users ...
and i stert experimet with new package
first - remove /etc/apache-ssl/
and start install again and i get this :
after enter some parametrs ... was started create pem certificate and ...
Using configuration from /tmp/24251.req
Generating a 1024 bit RSA private key
.++
.++
writing new private key to '/etc/apache-ssl/apache.pem'
/etc/apache-ssl/apache.pem: No such file or directory
24267:error:02001002:system library:fopen:No such file or
directory:bss_file.c:245:fopen('/etc/apache-ssl/apache.pem','w')
24267:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:247:
dpkg: error processing apache-ssl (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
apache-ssl
E: Sub-process /usr/bin/dpkg returned an error code (1)
[EMAIL PROTECTED]:~#
... and No such file or
directory:bss_file.c:245:fopen('/etc/apache-ssl/apache.pem
STart Second time
and i was create /etc/apache-ssl
the process of installing - has not finished success
again has errors :
Can't read /etc/apache-ssl/modules.conf
No such file or directory
Can't read
/etc/apache-ssl/conf.d
No such file or directory
Can't read
/etc/apache-ssl/modules.conf
No such file or directory
Can't read /etc/apache-ssl/conf.d
No such file or directory
Configuration syntax error detected. Not reloading.
fopen: No such file or
directory
apache-ssl: could not open document config file
/etc/apache-ssl/modules.conf
invoke-rc.d: initscript apache-ssl, action start failed.
dpkg: error processing
apache-ssl (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
apache-ssl
E: Sub-process /usr/bin/dpkg
returned an error code (1)
Start at third time :
process to
¦
¦
¦ keep your
currently-installed version ¦
¦ install the package
maintainer's version ¦
¦ show the differences
between the versions ¦
¦ start a new shell to
examine the situation¦
¦
¦
¦
¦
¦Ok
Cancel ¦
¦
¦
Re: Bug#236982: typo mf for mv in apache's /usr/share/apache/postinst.common
tags 236982 + pending stop On Tue, 9 Mar 2004, Stephen J. Turnbull wrote: Package: apache Version: 1.3.29.0.2-1 ... and 1.3.29.0.2-2 it would appear. Severity is grave: it fucks the whole installation process because metafont (!!) wants console input, you have to interrupt dpkg. $ fgrep -n mf /usr/share/apache/postinst.common 132: mf -f /etc/$pkg/httpd.conf.dpkg-inst.queue.dpkg-inst.queue.$$ /etc/$pkg/httpd.conf.dpkg-inst.queue.dpkg-inst.queue Right, but you opened another bug instead of adding information to the other one. Anyway I am uploading in a few minutes -3 with the fix. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: trouble with install APACHE-SSL 1.3.290.2-2
Hi Andres, re-reading your mail... On Tue, 9 Mar 2004, Andreas wrote: Hi there, Hi i just installed new apache-ssl 1.3.29.0.2-2 and can not enter into HTTPS site - i was use old config file ...and can`t i was there use auth files , group users ... and i stert experimet with new package first - remove /etc/apache-ssl/ You shouldn't remove apache-ssl and apache-ssl/conf.d They are configuration directories shipped with the package and apache-ssl expect them to be there. On the other side you can remove all the files inside them. and start install again and i get this : after enter some parametrs ... was started create pem certificate and ... Using configuration from /tmp/24251.req Generating a 1024 bit RSA private key .++ .++ writing new private key to '/etc/apache-ssl/apache.pem' /etc/apache-ssl/apache.pem: No such file or directory This is a consenquence of the above. STart Second time and i was create /etc/apache-ssl the process of installing - has not finished success again has errors : Can't read /etc/apache-ssl/modules.conf [SNIP] These files are created with a certain order during the installation. If you try the second time it might cause this problem because it results to be an upgrade and not an installation (and the postinst behave differently). and get thie : Replacing config file /etc/apache-ssl/modules.conf with new version cp -f /etc/apache-ssl/modules.conf.dpkg-inst.queue /etc/apache-ssl/modules.conf Can't read /etc/apache-ssl/conf.d No such file or directory Can't read /etc/apache-ssl/conf.d No such file or directory Configuration syntax error detected. Not reloading. Same as the first problem. httpd.conf has an Include for conf.d that if it is not there fails. Either you comment it out from httpd.conf or you create the directory. try at 4 time : now i was create /etc/apache-ssl/conf.d/ dir and now all is ok i get Starting web server: apache-ssl. so ? what u think ? so installing is realy good ? i do not think so ... The major issue is that you removed apache-ssl in the beginning but yes i agree that can be improved to be more user experimentation safe. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#237151: apache-ssl SID
tags 237151 + pending stop The problem is that upstream has changed the loadmodule order sequence. Until -4 is out you can use this workaround: cd /usr/lib/apache/1.3 mv 220mod_auth_ssl.info 420mod_auth_ssl.info modules-config apache-ssl and let modules-config install the new configuration file with the correct LoadModule order, otherwise edit /etc/apache-ssl/modules.conf so that it will look like: LoadModule apache_ssl_module /usr/lib/apache/1.3/libssl.so LoadModule auth_module /usr/lib/apache/1.3/mod_auth_ssl.so (of course remember to remove the other instance of mod_auth_ssl.so) Fabio On Wed, 10 Mar 2004, [iso-8859-2] Meretei Balázs wrote: Package: apache-ssl Version: 1.3.29.0.2-3 since I updated with the last two versions, comes with sid dist-upgrade (8. marc and 9. marc) , I can not be able to use the AuthConfig. Before I have installed the updates, it worked fine. I chechked the httpd.conf file but everything is OK (modules, config lines) But with the upgraded apace it works fine.. maybe mod_auth_ssl.so has this bug.. apache-ssl/error.log: [Wed Mar 10 00:52:04 2004] [notice] Apache/1.3.29 Ben-SSL/1.53 (Debian GNU/Linux) PHP/4.3.4 configured -- resuming normal operations [Wed Mar 10 00:52:04 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) [Wed Mar 10 00:52:32 2004] [error] [client 193.224.222.20] user not found: / [Wed Mar 10 00:52:32 2004] [error] [client 193.224.222.20] user not found: / [Wed Mar 10 00:54:01 2004] [error] [client 193.224.222.20] user not found: / [Wed Mar 10 00:54:04 2004] [error] [client 193.224.222.20] user not found: / [Wed Mar 10 00:54:07 2004] [error] [client 193.224.222.20] user not found: / .htaccess file: AuthType Basic AuthName users AuthUserFile /storage/web/htmlpass_users AuthGroupFile /dev/null Limit GET POST PUT require valid-user /Limit With acces files everything is ok, because it they works fine with apache. == Meretei Balázs [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#236882: apache-perl: New patch from mod_perl maintainer
On Tue, 9 Mar 2004, Dave Rolsky wrote: Package: apache-perl Version: 1.3.29.0.2-1 Severity: normal Followup-For: Bug #236882 the patch has been updated and reenabled in -4 uploaded a couple of hours ago. Sorry but i forgot to add this bug to the Changelog. I am closing it manually. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#237377: apache: Apache parent process dies at reload
Hej Rasmus, On Thu, 11 Mar 2004, Rasmus Bøg Hansen wrote: Package: apache Version: 1.3.26-0woody3 Severity: important Tags: woody [SNIP] I have loaded PHP4 and mod_ssl; no other external modules are configured nor installed. A log snippet from this morning: [Thu Mar 11 07:00:31 2004] [notice] SIGUSR1 received. Doing graceful restart accept_mutex_on: Identifier removed [Thu Mar 11 07:00:36 2004] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2 mod_ssl/2.8.9 OpenSSL/0.9.6g configured - - resuming normal operations [Thu Mar 11 07:00:36 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache/suexec) [Thu Mar 11 07:00:36 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) [Thu Mar 11 07:00:36 2004] [alert] Child 31317 returned a Fatal error... Apache is exiting! No other logs tell anything about where the problem comes from. Logrotate just runs /etc/init.d/apache reload. The server is not busy in any way; nor does it serve large files. It runs a simple web page and some php webmail (IMP2) over ssl; nothing fancy. Unfortunatly this is a known problem that seems to be caused by several different factors (php4, ssl, libcrypto and libc) and it can't be fixed in woody. We are still waiting for a fix in sid (where bugs have been filed towards the relevant packages). A possible workaround could be to change the restart with a stop and start but this behaviour is unpredictable and not always reproducible. Mange Tak Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#237763: apache-ssl: SIGSEGV on connect
On Sat, 13 Mar 2004, simon raven wrote: yes, with and without php4 enabled it SEGVs. mod-perl is: ii libapache-mod-perl 1.29.0.2-4 php is currently enabled in the conf. attaching gzipped httpd.conf from /etc/apache-ssl. Unfortunatly this is not enough for me and i see that your config is pretty complex. Please stop apache-ssl and do: strace apache-ssl -X -F and send me the full output after the first client connects at that point apache-ssl should crash in the same way you see in the error logs. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#237946: apache-common: /etc/apache/modules.conf is not modified
reassign 237946 ucf stop Hi Oliver, unfortunatly there are 2 typos in ucf. See: http://lists.debian.org/debian-apache/2004/debian-apache-200403/msg00199.html for reference. Fabio On Sun, 14 Mar 2004, Oliver Zimmermann wrote: Package: apache-common Version: 1.3.29.0.2-4 Severity: normal When I try to install an apache module with modules-config, the new version of /etc/apache/modules.conf is not installed. The new version only exists as modules.conf.dpkg-dist or real_file. For example: /etc/apache# /usr/sbin/modules-config apache enable mod_perl Replacing config file /etc/apache/modules.conf with new version Not saving /etc/apache/modules.conf, since it was unmodified cp -f /etc/apache/modules.conf.dpkg-inst.queue real_file testix:/etc/apache# l total 103 drwxr-xr-x3 root root 368 Mar 14 15:39 . drwxr-xr-x 72 root root 5328 Mar 14 10:59 .. -rw-r--r--1 root root 285 Sep 13 2003 access.conf drwxr-xr-x2 root root 48 Mar 10 19:14 conf.d -rw-r--r--1 root root33863 Mar 14 11:02 httpd.conf -rw-r--r--1 root root35895 Mar 14 10:08 httpd.conf.zi.sav lrwxrwxrwx1 root root 15 Sep 13 2003 mime.types - /etc/mime.types -rw-r--r--1 root root 1291 Mar 14 14:14 modules.conf -rw-r--r--1 root root 1346 Mar 14 15:39 modules.conf.dpkg-dist -rw-r--r--1 root root 1346 Mar 14 15:39 real_file -rw-r--r--1 root root 297 Sep 13 2003 srm.conf -rw-r--r--1 root root 316 Mar 14 10:06 suexec.limits The mod_perl did not exist in the modules.conf before and after the installation with modules-config. Regards, Oliver -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.20 Locale: LANG=C, LC_CTYPE=C Versions of packages apache-common depends on: ii apache-utils1.3.29.0.2-4 Utility programs for webservers ii debconf 1.4.16 Debian configuration management sy ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-14Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-6 XML parsing C library - runtime li ii mime-support3.25-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-2 Larry Wall's Practical Extraction ii sed 4.0.7-4 The GNU sed stream editor ii ucf 0.32 Update Configuration File: preserv -- debconf information: * apache-common/confignotes: apache-common/old-logrotate-exists: apache-common/logs: apache-shared/debconf-modules: mod_userdir, mod_unique_id, mod_status, mod_setenvif, mod_rewrite, mod_negotiation, mod_mime_magic, mod_mime, mod_log_config, mod_info, mod_expires, mod_dir, mod_cgi, mod_autoindex, mod_auth, mod_alias, mod_access, mod_php4, mod_perl apache-shared/restart: false -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#237763: (no subject)
On Mon, 15 Mar 2004 [EMAIL PROTECTED] wrote: Le Sun, Mar 14, 2004 at 07:22:04 +0100, Fabio Massimo Di Nitto a écrit: severity 237763 important stop After a round robin of tests on 4 different ppc installations, we still cannot reproduce this bug that seems to be pretty specific to something on your machine/setup. We used the default apache-ssl config with the usual suspects installed (php4 and perl). In all cases we were able to get pages out of it without segfaults. excuse me? you're closing this without even giving me a chance to do the strace? WTF do you think you're doing ? um, you're not the only one who's busy you know. FFS. Sorry?? the bug is open. Noone has been closing it. I only downgraded the severity to important. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#237763: (no subject)
Hi Ralf, On Mon, 15 Mar 2004 [EMAIL PROTECTED] wrote: ??? Do you actually _read_ Fabio's mails (as opposed to just glance at it)? It's ok don't worry.. I also did my mistake in the paste flaming at people for mistakes or misunderstandings or not completely reading their mails and Simon apologized immediatly after. And for everyone: Please guys let's not start another flamewar for nothing, ok? Let's keep the crap out of debian-apache. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#238607: apache: upgrade problem
tags 238607 + pending stop Hi all, On Thu, 18 Mar 2004, Thom May wrote: I don't know about the ucf error though, if you would like, i can downgrade back down, and then re-upgrade with the different file names in conf.d to see how it responds. Known bug in UCF. Will be fixed soon/now. I am tagging this bug pending since there were a couple of lines in apache at fault too. Just FYI i have send a patch to Manoj that should fix this specific problem but I am waiting for his upload before considering this bug closed Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#238996: apache: instalation scripts broken
You have an old version of ucf installed that had a typo. Please upgrade ucf. apache isn't at fault. Fabio On Sat, 20 Mar 2004, Primoz Bratanic wrote: Package: apache Version: 1.3.29.0.2-4 Severity: grave Tags: sid Justification: renders package unusable apt-get install apache Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: apache-common apache-utils libkeynote0 mime-support Suggested packages: apache-doc apache-ssl apache-perl libapache-mod-auth-mysql libapache-mod-auth-pgsql The following NEW packages will be installed: apache apache-common apache-utils libkeynote0 mime-support 0 upgraded, 5 newly installed, 0 to remove and 58 not upgraded. Need to get 1500kB of archives. After unpacking 4481kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.at.debian.org unstable/main mime-support 3.26-1 [28.6kB] Get:2 http://ftp.at.debian.org unstable/main libkeynote0 2.3-10 [28.2kB] Get:3 http://ftp.at.debian.org unstable/main apache-utils 1.3.29.0.2-4 [258kB] Get:4 http://ftp.at.debian.org unstable/main apache-common 1.3.29.0.2-4 [817kB] Get:5 http://ftp.at.debian.org unstable/main apache 1.3.29.0.2-4 [368kB] Fetched 1500kB in 14s (102kB/s) Preconfiguring packages ... Selecting previously deselected package mime-support. (Reading database ... 67499 files and directories currently installed.) Unpacking mime-support (from .../mime-support_3.26-1_all.deb) ... Selecting previously deselected package libkeynote0. Unpacking libkeynote0 (from .../libkeynote0_2.3-10_i386.deb) ... Selecting previously deselected package apache-utils. Unpacking apache-utils (from .../apache-utils_1.3.29.0.2-4_i386.deb) ... Selecting previously deselected package apache-common. Unpacking apache-common (from .../apache-common_1.3.29.0.2-4_i386.deb) ... Selecting previously deselected package apache. Unpacking apache (from .../apache_1.3.29.0.2-4_i386.deb) ... Setting up mime-support (3.26-1) ... Setting up libkeynote0 (2.3-10) ... Setting up apache-utils (1.3.29.0.2-4) ... Setting up apache-common (1.3.29.0.2-4) ... Setting up apache (1.3.29.0.2-4) ... Creating config file /etc/apache/httpd.conf with new version cp -f /etc/apache/httpd.conf.dpkg-inst.queue real_file /etc/apache/httpd.conf: No such file or directory Creating config file /etc/apache/srm.conf with new version cp -f /etc/apache/srm.conf.dpkg-inst.queue real_file /etc/apache/srm.conf: No such file or directory Creating config file /etc/apache/access.conf with new version cp -f /etc/apache/access.conf.dpkg-inst.queue real_file /etc/apache/access.conf: No such file or directory Creating config file /etc/apache/modules.conf with new version cp -f /etc/apache/modules.conf.dpkg-inst.queue real_file /etc/apache/modules.conf: No such file or directory Can't open config file /etc/apache/httpd.conf. No such file or directory Can't open config file /etc/apache/httpd.conf. No such file or directory /var/lib/dpkg/info/apache.postinst: line 7: /etc/apache/httpd.conf: No such file or directory /var/lib/dpkg/info/apache.postinst: line 7: /etc/apache/httpd.conf: No such file or directory /var/lib/dpkg/info/apache.postinst: line 7: /etc/apache/httpd.conf: No such file or directory /var/lib/dpkg/info/apache.postinst: line 7: /etc/apache/httpd.conf: No such file or directory grep: /etc/apache/httpd.conf: No such file or directory Configuration syntax error detected. Not reloading. fopen: No such file or directory apache: could not open document config file /etc/apache/httpd.conf invoke-rc.d: initscript apache, action start failed. dpkg: error processing apache (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: apache E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get install -f Reading Package Lists... Done Building Dependency Tree... Done 0 upgraded, 0 newly installed, 0 to remove and 58 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up apache (1.3.29.0.2-4) ... /etc/apache/httpd.conf: No such file or directory /etc/apache/srm.conf: No such file or directory /etc/apache/access.conf: No such file or directory /etc/apache/modules.conf: No such file or directory Replacing config file /etc/apache/modules.conf with new version cp -f /etc/apache/modules.conf.dpkg-inst.queue real_file /etc/apache/modules.conf: No such file or directory Can't open config file /etc/apache/httpd.conf. No such file or directory Can't open config file /etc/apache/httpd.conf. No such file or directory /var/lib/dpkg/info/apache.postinst: line 7: /etc/apache/httpd.conf: No such file or directory /var/lib/dpkg/info/apache.postinst: line 7: /etc/apache/httpd.conf: No such file or directory /var/lib/dpkg/info/apache.postinst:
Re: Bug#239416: apache: Apache 1.3.29.0.2-4 failling to upgrade
Hi Nelson, there might be several reasons why it is not starting. I think the easiest way for me to see the problem is if you can send me a tar of /etc/apache. Thanks Fabio PS since i consider this an important problem please provide me information as soon as possible. On Mon, 22 Mar 2004, Nelson A. de Oliveira wrote: Package: apache Version: 1.3.29.0.2-4 Severity: important Tags: sid Hi people When doing an apt-get dist-upgrade, I got: Instalando apache (1.3.29.0.2-4) ... Starting web server: apache failed invoke-rc.d: initscript apache, action start failed. dpkg: erro processando apache (--configure): subprocesso post-installation script retornou código de saída de error 1 (...) Erros foram encontrados durante processamento de: apache E: Sub-process /usr/bin/dpkg returned an error code (1) Just translating: Installing apache (1.3.29.0.2-4) ... Starting web server: apache failed invoke-rc.d: initscript apache, action start failed. dpkg: error processing apache (--configure): subprocess post-installation script returned code of exit error 1 (...) Errors were found during the processes of: apache E: Sub-process /usr/bin/dpkg returned an error code (1) Well... that is always happening to me. If I install any package, I got this. If uninstall, the same thing. If upgrades some package, got that too. What is wrong with Apache? Apache keeps running with no problems (maybe the old version is running). Thank you -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.4-rc1-mm2 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (ignored: LC_ALL set to pt_BR) Versions of packages apache depends on: ii apache-common 1.3.29.0.2-4 Support files for all Apache webse ii debconf 1.4.16 Debian configuration management sy ii dpkg1.10.20 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-15Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-2 Larry Wall's Practical Extraction -- debconf information: * apache/enable-suexec: true * apache/server-name: biolinux.df.ibilce.unesp.br * apache/document-root: /var/www * apache/server-port: 80 * apache/init: true * apache/server-admin: [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#239416: apache: Apache 1.3.29.0.2-4 failling to upgrade
Hi Nelson, On Mon, 22 Mar 2004, Nelson A. de Oliveira wrote: Hello Fabio It's attached the /et/apache as you said. Please, take a look. Yes and you attached a bit too much. Please consider changing user name and passwords ;) But one thing that is strange: If I reboot the computer, restart apache, whatever, it loads OK. But it just don't upgrade to the new version. Old version of apache loads ok the configs. The only think i can spot is the php4 module. What happens if you disable php4 and upgrade apache? Or otherwise just try to install libapache-mod-ssl, load it into the apache (there is no need to configure it) and than do an upgrade?. Also be sure that you have ucf 0.33 installed.. I am afraid you are hitting the well known php4 problem that sometimes shows up.. other times no but the configuration is clean... Please let me know Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#239416: apache: Apache 1.3.29.0.2-4 failling to upgrade
Ok let's try another approach... apt-get install apache-common this should bring apache-common to the latest version. Add set -x to /usr/share/apache/postinst.common apt-get install apache (to trigger again it's postinst script, be aware that it will produce quite a lot of output and we need to see all of it). I really can't see where the problem is... Thanks Fabio On Mon, 22 Mar 2004, Nelson A. de Oliveira wrote: The error old error was better than that: :-) Starting web server: apache failed invoke-rc.d: initscript apache, action start failed. dpkg: error processing apache (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of libapache-mod-ssl: libapache-mod-ssl depends on apache (= 1.3.29.0.1-4) | apache-perl (= 1.3.29.0.1-4); however: Package apache is not configured yet. Package apache-perl is not installed. dpkg: error processing libapache-mod-ssl (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: apache libapache-mod-ssl E: Sub-process /usr/bin/dpkg returned an error code (1) I don't know what could be. I always upgraded Apache with apt-get dist-upgrade and never touched it config files. But since 1.3.29.0.1-4 was released, that error keeps. Nelson -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#239416: apache: Apache 1.3.29.0.2-4 failling to upgrade
Hi Nelson, On Tue, 23 Mar 2004, Nelson A. de Oliveira wrote: Is there a way to get older versions of some package? A repository of every version of the packages? I had another machine that ad Apache 1.3.29.0.2-3, but it just upgraded without problems. I made a diff between /usr/share/apache from 1.3.29.0.2-3 and 1.3.29.0.2-4. It's attached. But the only solution that I see is to get the older version and install it. But I don't know how to get older versions... You can grab them from http://snapshot.debian.net/ I will be on vac a few days now and I will check my emails as soon as i will be back.. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#239829: apache: ReadmeName and HeaderName ignored, nothing displayed
Hi Robert, mod_autoindex was not very well documentented at that time. Here is a snapshot of you might need: # # ReadmeName: the name of the README file the server will look for by # default, and append to directory listings. # # HeaderName: the name of a file which should be prepended to # directory indexes. # # The module recognize only 2 kind of mime-types, text/html and # text/*, but the only method it has to identify them is via # the filename extension. The default is to include and display # html files. # ReadmeName README.html HeaderName HEADER.html # Otherwise you can comment the 2 lines above and uncomment # the 2 below in order to display plain text files. # # ReadmeName README.txt # HeaderName HEADER.txt Please let me know if it helps. Fabio PS I don't have a woody system handy to test sorry.. if someone can give it a shot I would be very very glad On Wed, 24 Mar 2004, SZOKOVACS Robert wrote: Package: apache Version: 1.3.26-0woody3 Severity: normal Whatever I set to ReadmeName and HeaderName, nothing gets displayed in the directory listing -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux ies-hungary 2.4.25 #3 Fri Feb 20 13:59:24 CET 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.26-0woody3 Support files for all Apache webse ii dpkg 1.9.21 Package maintenance system for Deb ii libc6 2.2.5-11.5 GNU C Library: Shared libraries an ii libdb22:2.7.7.0-7The Berkeley database routines (ru ii libexpat1 1.95.2-6 XML parsing C library - runtime li ii logrotate 3.5.9-8Log rotation utility ii mime-support 3.18-1.3 MIME files 'mime.types' 'mailcap ii perl 5.6.1-8.6 Larry Wall's Practical Extraction ii perl [perl5] 5.6.1-8.6 Larry Wall's Practical Extraction -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#240425: apache-utils: ab segfaults on big -n's
severity 240425 minor tags 240425 upstream stop On Sat, 27 Mar 2004, Dmitry V. Sabanin wrote: Package: apache-utils Version: 1.3.29-1 Severity: normal # /usr/sbin/ab -n 1 -c 2 http://localhost/ This is ApacheBench, Version 1.3d $Revision: 1.70 $ apache-1.3 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Segmentation fault With -n lower, everything is fine. I guess error message could be showed instead of segfaulting. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.0 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R Versions of packages apache-utils depends on: ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.14.1.25-16Berkeley v4.1 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libssl0.9.7 0.9.7c-5 SSL shared libraries ii perl [perl5]5.8.3-2 Larry Wall's Practical Extraction -- no debconf information -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#239416: apache: Problem with suexec upgrading woody - sarge
Hi Florian, Hi! I upgraded from woody to sarge and dpkg exited while configuration: --- Setting up apache (1.3.29.0.2-4) ... Starting web server: apache failed invoke-rc.d: initscript apache, action start failed. dpkg: error processing apache (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of libapache-mod-ssl: libapache-mod-ssl depends on apache (= 1.3.29.0.1-4) | apache-perl (= 1.3.29.0.1-4); however: Package apache is not configured yet. Package apache-perl is not installed. dpkg: error processing libapache-mod-ssl (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: apache libapache-mod-ssl E: Sub-process /usr/bin/dpkg returned an error code (1) -- Then I tried to start apache (using apachectl start) and got an error, that suexec isn't configured right. After dpkg-divert --local --divert /usr/lib/apache/suexec --rename /usr/lib/apache/suexec.disabled this problem was solved and the apache starts. [SNIP] Now there's no suexec or suexec.disabled file inside /usr/lib/apache and I had to disable every suexec (user/group) directive in my virtual hosts. Perhaps this helps? It can be the reason.. yes.. I will try to look at it as soon as i can put my hands on a woody box. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#240961: apache segfaults on start
Hi David,
On Mon, 29 Mar 2004, David Stipp wrote:
stat64(/dev/urandom, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9),
...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 11374 detached
There was a bug where someone else encountered a SEGV (#230539) caused
by recursively including the config files. I purged all of my config
files and clean installed the package, and the problem persists.
Not only. Which modules are you loading? (usual bunch of questions) did
you try to disable php4? did you try to disable mod_perl?
I have had this problem occur for the past few months, and it has
happened on 2.4.21-xfs and 2.4.23-xfs.
I don't think it's a kernel problem.. or i hope not at least.
Please let me know
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#240961: apache segfaults on start
hi David,
On Mon, 29 Mar 2004, David Stipp wrote:
On Tue, Mar 30, 2004 at 07:08:47AM +0200, Fabio Massimo Di Nitto wrote:
On Mon, 29 Mar 2004, David Stipp wrote:
stat64(/dev/urandom, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9),
...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 11374 detached
There was a bug where someone else encountered a SEGV (#230539) caused
by recursively including the config files. I purged all of my config
files and clean installed the package, and the problem persists.
Not only. Which modules are you loading? (usual bunch of questions) did
you try to disable php4? did you try to disable mod_perl?
Well, I seem to have traced down this problem here. When apache started
working once I disabled php4, I started to twiddle with the php4 modules
that were being loaded. I traced down the problem to the php4-imap
module.
Looks like this ticket should get bounced over that way.
Thanks for your fast response.
It is a well known problem that goes way down to libc6. A temporary
workaround is to install libapache-mod-ssl and load it. There is no need
to configure it.
I am closing this bug since all the maintainers from php4 down to libc6
are aware and working actively on this problem. You can check the progress
directly from the BTS on the php4 page.
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Bug#239416: Re: Bug#239416: apache: Apache 1.3.29.0.2-4 failling to upgrade
Hi, On Wed, 31 Mar 2004, Csaba Nemeth wrote: I realized the invoke-rc.d apache start line. At the time of the apt-get update, my apache was running, after I stopped it, the apt-get update worked out fine. Maybe that should be checked (if apache is running), and use invoke-rc.d apache restart in that case? This is really strange. apache does that check to be sure that it is not running but i will recheck again as soon as i can.. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#241957: woody to sid apache upgrade hang
On Sun, 4 Apr 2004, Fabio Massimo Di Nitto wrote: Which frontenf are you using? Sorry I meant to ask which version of ucf you have installed?? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#242225: /etc/init.d/apache reload kills apache
Hi, did you add any module recently? did you try to disable php4? In case does it work? Thanks Fabio On Mon, 5 Apr 2004, Laurent Martelli wrote: Package: apache Version: 1.3.29.0.2-4 Severity: normal It looks like all went fine, error.log says: [Mon Apr 5 15:19:24 2004] [notice] SIGUSR1 received. Doing graceful restart but there's no more apache process running. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.24-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages apache depends on: ii apache-common 1.3.29.0.2-4 Support files for all Apache webse ii debconf 1.4.16 Debian configuration management sy ii dpkg1.10.19 Package maintenance system for Deb ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii libdb4.24.2.52-8 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-4 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-7 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.23-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-2 Larry Wall's Practical Extraction -- debconf information: * apache/enable-suexec: false * apache/server-name: aopsys.aopsys * apache/document-root: /var/www * apache/server-port: 80 * apache/init: true * apache/server-admin: [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#241957: woody to sid apache upgrade hang
Hi guys, the problem has been hunted down in ucf and fixed in version 1.02 of ucf it self. Have fun! Fabio On Sun, 4 Apr 2004, Bill Allombert wrote: Package: apache Version: 1.3.29.0.2-4 Severity: important Hello Debian Apache maintainers, During the latest woody to sid upgrade test I performed (under user-mode-linux, the upgrade process get stalled: Setting up apache (1.3.29.0.2-4) ... Configuration file `/etc/apache/httpd.conf' == File on system created by you or by a script. == File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a new shell to examine the situation The default action is to keep your current version. *** httpd.conf (Y/I/N/O/D/Z) [default=N] ? Whatever optionI choose, the upgrade process hang. Doing a ^Z and ps auwwx I get: root 6926 0.0 2.8 8836 7228 tty1 T18:17 0:00 apt-get install apache-common root 6930 0.0 7.0 19292 17808 tty1T18:17 0:00 /usr/bin/dpkg --configure apache root 6931 0.0 2.5 8252 6420 tty1 T18:17 0:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/apache.postinst configure 1.3.26-0woody3 root 6938 0.0 0.5 2480 1288 tty1 T18:17 0:00 /bin/bash /var/lib/dpkg/info/apache.postinst configure 1.3.26-0woody3 root 7890 0.0 0.4 2400 1208 tty1 T18:17 0:00 /bin/bash /usr/bin/ucf --debconf-ok /etc/apache/httpd.conf.dpkg-inst.queue /etc/apache/httpd.conf So maybe it is related to ucf/debconf. There is the definite possibility I have a poorly configured user-mode-linux system, but I perform regularly such upgrading test and it is the first time it hangs there. Cheers, -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#239416: Re: Bug#239416: apache: Apache 1.3.29.0.2-4 failling to upgrade
Guys let's not confuse stuff around. There were 2/3 problems running around. One was ucf 1.00 that has been fixed in ucf 1.02 and the other one appears to be suexec. There is the possibility that apache does not get stopped across upgrades even if there is a specific entry for it and I don't understand why (yet). The random warning i saw around from update-rc.d: warning: /etc/rc3.d/S20apache is not a link to ../init.d/apache are not an apache problem and I am sure about it 100% since that code hasn't changed since 1.3.29.0.2-1 and noone has been complaining about it before, so i somehow doubt that all of a sudden that stuff broke down. Now the only problem(s) left are the suexec and the possible stop of apache before upgrades. If you have any possibility to perform tests in these areas it would be extremely important for me to have the reports back.. together with configfiles and so on. Patches are even more welcome :-) Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#242499: libapache-mod-perl and request-tracker3 randomly sends html to error log instead of browser
tags 242499 + moreinfo stop Hi Andre, please i need you to do some testing for me. I have never seen this kind of behaviour and i find it really really strange. Please create a simple perl page like hello world, disable everything that is not required to run it (php4, mod_jk and so on..) and than use ab to poll that script several thousands of times for a few hours. If there is no segafult or no errors i suspect that one of the other modules or request tracker3 do something that corrupts things around. Thanks Fabio On Tue, 6 Apr 2004, Andre wrote: [Tue Apr 6 17:42:50 2004] [notice] child pid 9885 exit signal Segmentation fault (11) But this only happens after randomly sending request-tracker(perl) pages directly to the apache error log instead of the web-browser. This has affected my php pages as well although I have not noticed the php html in the log files I now occasionally get empty responses from apache. In an attempt to fix this problem I did the changed following in /usr/share/request-tracker3/libexec/webmux.pl #use Carp; use CGI::Carp qw(fatalsToBrowser); After restarting apache it worked fine for several hours. Now it won't display a page from the request-tracker (perl pages) in the browser instead all the pages are going to error log instead. -- snip from error log --- [Mon Apr 5 06:44:49 2004] [notice] Apache/1.3.29 (Debian GNU/Linux) mod_jk/1.2.5 PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.7c mod_perl/1.29 configured -- resuming normal operations [Mon Apr 5 06:44:49 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache/suexec) [Mon Apr 5 06:44:49 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) HTTP/1.1 200 OK^M Date: Mon, 05 Apr 2004 12:46:05 GMT^M Server: Apache/1.3.29 (Debian GNU/Linux) mod_jk/1.2.5 PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.7c mod_perl/1.29^M Expires: +30m^M Connection: close^M Content-Type: text/css^M --- end snip -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.23 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages libapache-mod-perl depends on: ii apache-common 1.3.29.0.2-4 Support files for all Apache webse ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdevel-symdump-perl 2.03-3 Perl module for inspecting perl's ii libperl5.8 5.8.3-3 Shared Perl library. ii liburi-perl 1.30-1 Manipulates and accesses URI strin ii libwww-perl 5.76-2 WWW client/server library for Perl ii perl [libmime-base64-perl] 5.8.3-3 Larry Wall's Practical Extraction -- no debconf information -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#242985: Requires valid-user is not being honored
On Sat, 10 Apr 2004, James Blackwell wrote: Package: apache Version: 1.3.29.0.2-4 I am attempting to use libapache-mod-perl to perform a custom configuration. However it appears that apache is not honoring the directory stanza for the virtual host. I believe this is a bug in apache and not in libapache-mod-perl because libapache-mod-perl is returning fails to the apachesubsystem. At this time I do not think this is user error because I've checked against half a dozen examples (including perl.apache.org) and I seem to be right in line. Can you kindly post your modules.conf? Do you have any other auth module loaded? Which one is loaded first? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#243354: apache: init script refs unfile
severity 242367 minor tags 243354 + pending merge 243354 242367 stop Fabio On Mon, 12 Apr 2004, Marc Haber wrote: Package: apache Version: 1.3.29.0.2-4 Severity: minor # The variables below are NOT to be changed. They are there to make the # script more readable. Look in /etc/defaults/apache for editable variables. This says the init script. (1) It's /etc/default, not /etc/defaults (2) Neither /etc/default/apache nor /etc/defaults/apache is shipped with the package. (3) Neither file is sourced by the init.d scipt, so setting variables there would be ignored by the initialization process. Most likely, this comment is a legacy from earlier days and should be removed. Greetings Marc -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.25-darren Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.29.0.2-4 Support files for all Apache webse ii debconf 1.4.21 Debian configuration management sy ii dpkg1.10.20 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-16Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-17 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-3 Larry Wall's Practical Extraction -- debconf information excluded -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#243536: apache: Fails to restart on SIGUSR1
Hi Adam, can you atleast include the configuration files? It works here and for most of us. I assume that one external module has been upgraded and apache not reloaded immediatly after. That could have lead to a crash (possibly php4/perl related) at logrotate time. Fabio On Tue, 13 Apr 2004, Adam Hupp wrote: Package: apache Version: 1.3.29.0.2-4 Severity: normal After upgrading to testing I noticed (after a few days) that my apache process was not running. The last thing in the error logs is: [notice] SIGUSR1 received. Doing graceful restart If I start apache and then do a apachectl graceful or killall -SIGUSR1 apache Apache will no longer be running, with that entry in the log file. It may be useful to know that this server is a user-mode-linux virtual host. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.25-5um Locale: LANG=C, LC_CTYPE=C Versions of packages apache depends on: ii apache-common 1.3.29.0.2-4 Support files for all Apache webse ii debconf 1.4.16 Debian configuration management sy ii dpkg1.10.20 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-15Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-15 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-2 Larry Wall's Practical Extraction -- debconf information: apache/server-name: www.erinspottery.com apache/document-root: /var/www apache/server-port: 80 * apache/enable-suexec: false apache/init: true apache/server-admin: [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: I meesed up big time
Hi Steve, ok there are 2 things you can do to simplify your life. Edit /usr/sbin/modules-config and edit it to look like: #!/bin/bash exit 0 this will avoid the Error: entries you see. (this problem is already fixed in our CVS and waiting for upload) backup your configs and do: apt-get --purge remove apache-utils. At this point all the packages should be removed correctly. Now you can reinstall apache without any problem. Fabio On Wed, 14 Apr 2004, Steve Reiger wrote: I somehow, managed to screw up my whole apache install, any help would be appreciated When I try to remove it to do a fresh install I get the following message -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#243536: apache: Fails to restart on SIGUSR1
Hi Adam, I am closing this bug since it is a very well known problem in php4 - libcrypto - libc6 problem and there are several (hundreds now?) duplicates in the BTS. A possible workaround is to load libapache-mod-ssl without even configuring it and it would solve the problem. In any case it is not an apache error. Thanks Fabio On Wed, 14 Apr 2004, Adam Hupp wrote: On Tue, Apr 13, 2004 at 08:12:22PM +0200, Fabio Massimo Di Nitto wrote: Hi Adam, can you atleast include the configuration files? It works here and for most of us. I assume that one external module has been upgraded and apache not reloaded immediatly after. That could have lead to a crash (possibly php4/perl related) at logrotate time. This is a persistant problem, not a one time thing. I've found through some trial and error that the cause is php4 4.3.3-4. The httpd.conf is attached. -Adam -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Apache errors
On Thu, 15 Apr 2004, Steve Reiger wrote: Error: 510mod_cgi_debug.info does not have a valid LoadModule entry. Error: 510mod_gzip.info does not have a valid LoadModule entry. Error: 510mod_mp3.info does not have a valid LoadModule entry. Error: 510mod_random.info does not have a valid LoadModule entry. The Upgrade cgi_debug, mod_gzip, mod_mp3 and mod_random too. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#243993: apache-common: load order for mod_auth_cache should be set 500
tags 243993 + pending stop Hi Chris, thanks for spotting this error. It is fixed in our CVS and included for the next upload Fabio On Thu, 15 Apr 2004, Chris Davies wrote: Package: apache-common Version: 1.3.29.0.2-4 Severity: normal With the new apache system and the module configuration being done within dpkg-reconfigure, mod_auth_cache which needs to be the first auth handler needs to have a number greater than the authorization schemes enabled. To do this, 500mod_auth_cache.info should probably be named 505mod_auth_cache.info or some number greater than 500. This will force mod_auth_cache to be loaded AFTER all of auth modules in modules.conf, thus assuring it will be the first module in the authorization chain. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.5-mm1 Locale: LANG=C, LC_CTYPE=C Versions of packages apache-common depends on: ii apache-utils1.3.29.0.2-4 Utility programs for webservers ii debconf 1.4.22 Debian configuration management sy ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-16Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-3 Larry Wall's Practical Extraction ii sed 4.0.9-1 The GNU sed stream editor ii ucf 1.02 Update Configuration File: preserv -- debconf information: * apache-common/confignotes: apache-common/old-logrotate-exists: * apache-common/logs: apache-shared/debconf-modules: mod_log_config, mod_mime, mod_negotiation, mod_include, mod_autoindex, mod_dir, mod_cgi, mod_alias, mod_rewrite, mod_access, mod_auth, mod_iprot, mod_php4 apache-shared/restart: false -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#243918: apache adds webmaster alias but forget newaliases
tags 243918 + pending stop Ok I found a reasonable compromise to fix this bug. Thanks for spotting the problem. Fabio On Thu, 15 Apr 2004, Erwan David wrote: Package: apache Version: 1.3.29.0.2-4 Severity: normal When installing apache, an alias webmaster: root is added to /etc/aliases. However, newaliases is not done, causing mismatch in mail system. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.25-1-k7 Locale: LANG=C, [EMAIL PROTECTED] Versions of packages apache depends on: ii apache-common 1.3.29.0.2-4 Support files for all Apache webse ii debconf 1.4.22 Debian configuration management sy ii dpkg1.10.20 Package maintenance system for Deb ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libdb4.24.2.52-16Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libmagic1 4.07-2 File type determination library us ii libpam0g0.76-19 Pluggable Authentication Modules l ii logrotate 3.6.5-2 Log rotation utility ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.3-3 Larry Wall's Practical Extraction -- debconf information: * apache/enable-suexec: false apache/server-name: localhost apache/document-root: /var/www apache/server-port: 80 apache/init: true apache/server-admin: [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#242543: apache: PATH_INFO not set for !--#include virtual=page.html/path?query --
tags 242543 + help stop hi guys, On Wed, 7 Apr 2004, Carl Johnstone wrote: That's the main request. #include is supposed to perform an internal sub-request for the new URL, with the environment setup accordingly. If I wanted the *original* query string and path_info I would be using #exec-cgi rather than #include virtual. The second section of this email : http://www.mail-archive.com/dev@httpd.apache.org/msg17597.html on the apache-dev mailing list, suggests that what I've tested should work. I am really not sure what is at fault here and I would appreciate some help in hunting down this bug. thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Summary for #242985
Hi all, after a long discussion/debugging session with James it seems that mod_perl auth* directives can conflicts with other mod_auth directives. Since this can be strictly dependent on user specific setting there is no way we can ensure that they will always work together and it seems that the problem is not related to the LoadModule order of mod_auth/mod_perl but a more generic case (at least this is what we were able to understand after our tests). The bug will be closed with the next apache upload, that contains a short summary and a reference to this bug in the README.Debian, so that these information will not be lost in time. I encourage anyone familiar to this setup to provide more information if we missed something obvious in our tests/summary. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#247011: Broken dependency - apache requires perl 5.8.4-0 which is unavailable
On Sun, 2 May 2004, Artur R. Czechowski wrote: Package: apache Version: 1.3.29.0.2-5 Severity: serious Easy with severities please. Tags: sid The apache package has dependency on perl 5.8.4-0 but perl 5.8.4-1 hit unstable today. The reason why we are now enforcing strict dependency towards perl is to avoid the recent numbers of problems perl gave to apache. We are tracking sid as well as everyone does. Give us at least the minimum time to upload. We are active maintainers. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#247103: apache-dev: cannot be installed
Hi, this is fixed already in -6. You will have to wait tomorrow that it will hit the mirrors. Fabio On Mon, 3 May 2004, Ralf Hildebrandt wrote: Package: apache-dev Version: most recent Severity: normal Tags: sid # apt-get install apache-dev Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: apache-dev: Depends: apache-common (= 1.3.29.0.2-5) but it is not going to be installed Depends: apache-common ( 1.3.30-0) but it is not going to be installed E: Broken packages -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: sparc (sparc64) Kernel: Linux 2.4.24-sparc64 Locale: LANG=C, LC_CTYPE=C -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#247140: apache: Uninstallable in sid
Please check the BTS before reporting bugs. Fabio On Mon, 3 May 2004, Martin Pitt wrote: Package: apache Version: 1.3.29.0.2-5 Severity: grave Tags: sid Justification: renders package unusable Hi Debian apache team! After today's dist-upgrade (via dselect), I got a surprising boot message that apache was not executable. 'dpkg -L apache' showed that the package was essentially empty (just two or three directories and config files), apache-common was completely empty. So I purged the packages and tried to reinstall them, but that is impossible: apache depends on perl ( 5.8.4-0), but perl is at 5.8.4-1. I'm not sure whether this is the reason why the package was not unpacked properly (I did not read dselect output since it exited cleanly and did not prompt for anything). Nevertheless this dependency makes apache uninstallable in sid. Thanks for sorting that out and for your efforts! Martin -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Kernel: Linux 2.6.5-grsec Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#247154: apache-common: The following packages have unmet dependencies
This is already fixed in -6 that it is in incoming. Please check the BTS before filing bugs against apache. On Mon, 3 May 2004, Koning, Jeroen wrote: Package: apache-common Version: 1.3.29.0.2-5 Severity: grave Tags: experimental Justification: renders package unusable The error message is : The following packages have unmet dependencies: apache-common: Depends: perl ( 5.8.4-0) but 5.8.4-1 is to be installed Depends: apache-utils (= 1.3.29.0.2-5) but it is not going to be installed -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (900, 'experimental'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.5 Locale: LANG=C, LC_CTYPE=C Versions of packages apache-common depends on: pn apache-utils Not found. ii debconf 1.4.25 Debian configuration management sy ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii libdb4.24.2.52-16Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii mime-support3.26-1 MIME files 'mime.types' 'mailcap ii perl5.8.4-1 Larry Wall's Practical Extraction ii sed 4.0.9-3 The GNU sed stream editor ii ucf 1.06 Update Configuration File: preserv Kind regards Jeroen -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: missing LoadModule php4
On Tue, 1 Jun 2004, Maurizio Marini wrote: Hi i've just installed apache 1.3.31-1 and php4; i note that in modules.conf is missing lsomething like: LoadModule php4_module /usr/lib/apache/1.3/libphp4.so should i add it by hand? No. apache-modconf apache and you will get prompted for the modules you want to load. php4 should do that automatically. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#156972: Tagging
severity 156972 wishlist tag 156972 wontfix stop This bug is now fixed in apache2 upstream cvs right now. Upstream will not backport this feature to apache1.3. The only way to get 4GB support is to upgrade to apache2. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#252678: apache: apache: can't install in sid
tags 252678 moreinfo tags 252678 unreproducible merge 252678 251175 stop Hi Marcelo, On Fri, 4 Jun 2004, Marcelo Toledo wrote: Package: apache Version: 1.3.31-1 Severity: serious As Jerome reported I am also having the same problem: see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251175 Instead of opening another bug, it would have been more useful to report information to the same bug. Setting up apache (1.3.31-1) ... dpkg: error processing apache (--configure): subprocess post-installation script returned error exit status 10 This bug is tagged as: moreinfo, unreproducible; If Fabbione or anyone else would like to use this machine I can fix it up so it can be reproducible. I am not in any related mailing list so please remember to CC me. It would be enough to know why it fails. I asked the other guy to check /var/log/apache/error.log and got no reply. Can you do that? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#252678: apache: apache: can't install in sid
On Fri, 4 Jun 2004, Marcelo Toledo wrote:
It would be enough to know why it fails. I asked the other guy to check
/var/log/apache/error.log and got no reply.
Can you do that?
The script does not reach apache, so there is no log, the bug is
probably here:
kali:/var/log/apache# . /usr/share/debconf/confmodule
Can't exec -su: No such file or directory at
/usr/share/perl/5.8/IPC/Open3.pm line 168.
open2: exec of -su failed at /usr/share/perl5/Debconf/ConfModule.pm line
44
-- cut --
167 local($)=( );
168 exec @cmd # XXX: wrong process to croak from
169 or croak $Me: exec of @cmd failed;
-- cut --
That file can't be sourced from bash. It needs to be executed in a script.
Please do the following:
apt-get --purge remove apache
rm -rf /etc/apache
vi /usr/share/apache/postinst.common and at the bottom:
do_all() {
if [ $# -ne 1 ]; then
echo Wrong number of arguments to do_all
return
fi
pkg=$1
set -x
add the set -x
apt-get install apache
and save all the logs in a file and send it to [EMAIL PROTECTED]
Thanks
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#253054: apache-ssl doesn't follow the TLS protocol
On Sun, 6 Jun 2004, Pedro Corte-Real wrote: Package: apache-ssl Severity: important Version: 1.3.31-1 I'm having problems connecting to an apache-ssl server using gnutls. The gnutls developers tell me this is because apache isn't following the TLS protocol. apache-ssl does not support TLS at all. You might want to play with apache + libapache-mod-ssl, where the latter claims supports for TLS. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#252678: apache: apache: can't install in sid
On Mon, 7 Jun 2004, Marcelo Toledo wrote: I have a working apache version in this machine so I need to have a webserver running, thats why I will have to try it in another machine that I get the same error, so I will take a little bit more time then usual... but hang on... or, do you have any other idea, or maybe where I could get an older working package of apache for sid? No I need these information otherwise these bugs for me are useles. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#253203: apache will not start due to syntax error
On Mon, 7 Jun 2004, William R. McDonough wrote: Package: apache Version: 1.3.31-1 Sometime in the last 24 hours, probably after an upgrade... not sure... Apache died and will not restart. The error given is not enough information for me to find which file apache is complaining about: [EMAIL PROTECTED]: ~]$ apachectl start Bareword found where operator expected at /dev/null line 1, near /usr/sbin (Missing operator before bin?) Number found where operator expected at /dev/null line 1, near line 68 (Do you need to predeclare line?) syntax error at /dev/null line 1, near /usr/sbin Execution of /dev/null aborted due to compilation errors. parse: Success /usr/sbin/apachectl start: httpd could not be started I'm looking for help to findout which file Apache is complaining about so I can fix the syntax. Uhao... never seen an error like this. I guess i will need your help to track this problem down. Please run the following commands for me: /etc/init.d/apache stop to be sure nothing is running. apachectl configtest that will check if there are obviuos errors in the config files and repeat the same test executing: apache -t If there are errors in the config file please indicate which ones otherwise you will see a Sintax OK, but remember that it does not mean that the config is 100% valid, only the sintax. try to start apache again and keep an eye on /var/log/error.log. Try first with /etc/init.d/apache start (and see if it starts) stop it again and try apachectl start. Thanks Fabio PS I would really appreciate if you can provide me info back asap. -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#253203: apache will not start due to syntax error
On Tue, 8 Jun 2004, Fabio Massimo Di Nitto wrote: try to start apache again and keep an eye on /var/log/error.log. oops /var/log/apache/error.log Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#252067: more info?
On Tue, 8 Jun 2004, Matthew Palmer wrote:
Whoops, sorry about that. I thought it did.
no problem. i wasn't upset.. just a note ;)
My best guess is that, since installing php4-sqlite that depends on
php4api that is provided by 2 packages that pulls in apache and apache2,
There are only two packages that I can find in unstable that provide
phpapi-20040918: php4 and php4-cgi. Nothing is providing zendapi-20020429.
libapache2-mod-php4 does too and it pulls in apache2-mpm-prefork.
php4 depends on apache-common. I'm not quite sure how that qualifies as a
dependency nightmare, nor am I sure how php4-sqlite would manage to pull in
apache2. I can't find a dependency link on it.
Basically in this setup apache2 and apache-common are pulled in. Nothing
bad until now, but if a user wants only apache1.3, he or she will endup
with both a1.3 and a2 installed.
apache2 was running before apache. Both of them listening on port 80. As a
result apache failed to start.
But if /etc/init.d/apache{,-ssl} doesn't call apachectl, how did we manage
to end up with the apachectl help message, no matter what might have already
been running?
That is my point. I have no idea. I have been rechecking all the cvs
history to be sure that was not introduced and removed for a mistake.
Matthew btw php4-sqlite call to apache restart seems ok even if
force-reload is not required (and your prerm script is broken ;)).
reload fails if apache isn't already running. I feel that's probably a bug
in apache, even though Policy doesn't forbid it (we really need an
initscript argument that says restart if already running, or succeed with
no action if not already running). The only way to reload without a
possible failure is force-reload.
Ok this has been discussed already with Joey H. as part of dh_installinit.
force-reload is an alias to reload atm and this can be fixed.
In anycase i can't reproduce the problem here. Can anybody provide me with
more info?
I can't reproduce it either. Personally, the only way I can manage to
rationalise it is that someone has done an ln -sf /usr/sbin/apachectl
/etc/init.d/apache. Nothing else makes the slightest sense.
I agree. I can't see any other way around it.
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#253306: apache-dev apt-get dependency problem
On Tue, 8 Jun 2004, John Bradshaw wrote: Package: apache-dev Version: 1.3.26-0wo Dependencies cannot be satisfied when installing apache-dev, see below... You have messed up your system, backporting packages that are not supposed to be in woody. ii apache 1.3.29.0.2-4 Versatile, high-performance HTTP server like this one. apache-dev: Depends: apache-common ( 1.3.27-0) but 1.3.29.0.2-4 is to be installed Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#253413: /etc/apache-perl not purged
On Wed, 9 Jun 2004, Alejandro Exojo wrote: Package: apache-perl Version: 1.3.31-1 Severity: normal When purging apache-perl, dpkg complained about /etc/apache-perl, because it isn't empty. The same applies to apache-ssl: --8 Removing apache-perl ... Purging configuration files for apache-perl ... dpkg - warning: while removing apache-perl, directory `/etc/apache-perl' not empty so not removed. Removing apache-ssl ... Purging configuration files for apache-ssl ... dpkg - warning: while removing apache-ssl, directory `/etc/apache-ssl' not empty so not removed. -8-- This is not a bug. If there are files in /etc/apache-perl or apache-ssl that do not belong to the package the directories must NOT be removed. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Re: Bug#247140: apache: Please fix this soon
On Wed, 9 Jun 2004, Martinelli Thomas wrote: hi, is this fixed now or not ? Yes. at least with the newest installation for debian unstable (done yesterday), the problem still exists. Impossible that is the same problem. Which problem are you having? logs? errors? Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#253203: apache will not start due to syntax error
On Thu, 10 Jun 2004 [EMAIL PROTECTED] wrote: On Thu, Jun 10, 2004 at 10:16:34AM -0400, William R. McDonough wrote: I have removed the following lines from my httpd.conf I have no idea why they were in there... but everything works fine without them. Do you have mod_perl installed (dpkg --status libapache-mod-perl) ? # If the perl module is installed, this will be enabled. ##IfModule mod_perl.c ## Alias /perl/ /var/www/perl/ ## Location /perl ##SetHandler perl-script ##PerlHandler Apache::Registry ##Options +ExecCGI ## /Location ##/IfModule Lets close this bug then. Why close it? Iff these configuration options alone cause a startup problem there shure _is_ a bug. Maybe reasign it to libapache-mod-perl. I did test an apache + libapache-mod-perl installation. It works here. It was the first step i did after your mail about perl. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#252678: downgrading severity
Please keep [EMAIL PROTECTED] in CC. On Fri, 11 Jun 2004, Marcelo Toledo wrote: I am going to do this today. But you have to answer me something please. As I said in the last email I have a working version of apache going on. And after apt-get remove apache --purge and apt-get install apache it will not work (probably) but we're going to have the info we need, done. I send you the logs and thats all. Ok. But the current version of apache I had was working so, I would like to have it back, I would like to know where I can get this old version, is there a repository or something like this? I need to get packages so I can downgrade after grabbing your logs. Take a backup of /etc/apache and you can use snapshot.debian.net to retrive older version of the packages. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: mod_proxy Apache potential issue
On Wed, 23 Jun 2004, Matt Zimmerman wrote: On Wed, Jun 23, 2004 at 03:24:13PM +0200, Marc SCHAEFER wrote: it seems there is a potential buffer overflow in Apache's mod_proxy. Are you aware of it ? What I believe I heard from our Apache maintainers was that this would only crash the child servicing the request (which isn't even a DoS, really), and did not actually permit the execution of code, but the description in CVE is quite explicit that it is a code execution vulnerability. Can someone confirm? I read the same advisory and we are ready to upload in sid. This is a url to the sid patch: http://cvs.raw.no/cgi-bin/viewcvs.cgi/debian-apache/debian/patches/000_stolen_from_HEAD_CAN-2004-0492?rev=1.1view=markup It is not intrusive. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#255930: apache-modconf fails to disable modules
tag 255930 moreinfo tag 255930 unreproducible stop Hi, On Wed, 23 Jun 2004, C.Y.M. wrote: Package: apache-common Version: 1.3.31-1 Change Request: apache-modconf fails to disable modules in apache and apache-ssl For Example: When I type apache-modconf apache-ssl disable mod_proxy_add_forward, the module is not removed from the modules.conf file. Even though I was able to use apache-modconf apache-ssl enable mod_proxy_add_forward to insert the module successfully. I cannot reproduce this problem here. Can you show me what is the output on console using these few commands: cat /etc/apache-ssl/modules.conf apache-modconf apache-ssl enable mod_imap cat /etc/apache-ssl/modules.conf apache-modconf apache-ssl disable mod_imap cat /etc/apache-ssl/modules.conf and tell me which questions are you asked during this process? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
RE: Bug#255930: apache-modconf fails to disable modules
On Thu, 24 Jun 2004, C.Y.M. wrote: I have followed your instructions and first listed the contents of modules.conf in apache-ssl. Then I added mod_imap. Next, I listed the new contents of modules.conf (and mod_imap was there). Finally, I was able to remove mod_imap and it was no longer in the modules.conf. But, this appears to only work with specific modules. If I attempt the same test with mod_proxy_add_forward, then nothing happens. This is a feature and not a bug! if you add invalid lines to apache config, apache will never work. That's why only valid modules (installed on the system) are allowed to enter modules.conf. Fabio PS I am closing this bug. -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#256713: Apache security update made my website disappear
On Mon, 28 Jun 2004, Ian Jackson wrote: Package: apache Version: 1.3.26-0woody5 The security update to apache changed my httpd.conf and srm.conf in a way that meant my system's website disappeared. I did get offered `Save these changes to the configuration files? [Y/n]' and said yes, but: You accepted a new configuration without checking it. It is exactly the same as many other tools to handle configurations. * Security updates should be safe. In particular, security updates should be doable with less care, checking, presence of mind, etc. etc. than an elective upgrade. Negative. Security updated fix a bit of the code. The rest of the package stays the same. Please check: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security for more information. * The default should not be to override a user-changed configuration. You asked for it once you told the script Yes. You have been prompeted and warned. * The default should not be to disable an existing website by changing the DocumentRoot to the Debian default. Same as above. * The question was preceded by a large amount of largely irrelevant messages. This is not true in sarge/sid anymore. In any case there is nothing left as a bug in here. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#257108: apache: /var/lib/apache/mod-bandwidth/ is world writable
This has been discussed before several time. Here is one: http://lists.debian.org/debian-apache/2004/02/msg00045.html On Thu, 1 Jul 2004, Javier Fernández-Sanguino Peña wrote: Package: apache-common Version: 1.3.31-1 Priority: important Tags: security I cannot really understand why this is needed: $ ls -la /var/lib/apache/mod-bandwidth/ total 16 drwxrwxrwx4 www-data www-data 4096 2003-10-20 21:53 . drwxr-xr-x3 root root 4096 2003-10-20 21:53 .. drwxrwxrwx2 www-data www-data 4096 2003-10-14 14:38 link drwxrwxrwx2 www-data www-data 4096 2003-10-14 14:38 master README.mod_bandwidth just says: No documentation available! It is in the source code. So, is there any reason why mod-bandwith files should be writable by all users? * 3) Create the following directories with rwx permission to everybody : */tmp/apachebw */tmp/apachebw/link */tmp/apachebw/master * * Note that if any of those directories doesn't exist, or if they can't * be accessed by the server, the module is totaly disabled except for * logging an error message in the logfile. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#257775: AddDefaultCharset default setting is misleading
Hi Marc, On Tue, 6 Jul 2004, [utf-8] Marc Dequènes wrote: Package: apache Severity: minor Coin, Default setting is on by default, so apache force a specific encoding. Most users, and some not complete newbie, are unable to understand why their site is not working as expected, and some (kov) may wonder why their browser is not rendering it properly. As activating this setting is pretty much unuseful for a large majority of users, i suggest deactivating it in future release. This thing has been discussed over and over. This is the last reference to it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211889archive=yes Since setting AddDefaultCharset off can imply security problem we will never switch it to off. For more information please check the previous URL and the apache documentation on httpd.apache.org Thanks Fabio PS I am closing this bug. -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#257775: AddDefaultCharset default setting is misleading
On Tue, 6 Jul 2004, [utf-8] Marc Dequènes wrote: Coin, Since setting AddDefaultCharset off can imply security problem we will never switch it to off. For more information please check the previous URL and the apache documentation on httpd.apache.org I'm OK with all this. May i suggest you add a small note in 'README.Debian' with links (especially http://httpd.apache.org/info/css-security/encoding_examples.html) so as people to understand and not reopen a bug when the old ones are archived ? sure.. that's actually a good idea... Thx for this explanation. no problem... BTW, thanks a lot for your work on IPv6 enabled apache. eh if i only had the time to give them the love they deserve :( Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#257775: AddDefaultCharset default setting is misleading
On Tue, 6 Jul 2004, Matthew Wilcox wrote: On Tue, Jul 06, 2004 at 07:10:10AM +0200, Fabio Massimo Di Nitto wrote: This thing has been discussed over and over. This is the last reference to it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211889archive=yes Since setting AddDefaultCharset off can imply security problem we will never switch it to off. For more information please check the previous URL and the apache documentation on httpd.apache.org I think the real bug here is in the html specification -- it says the server's setting overrides the document's setting, which just seems daft. My understanding of the security problem is that you need to always set _some_ charset encoding. So I think it'd be a good idea to always set utf-8 rather than latin1 in new installations. The reason why i didn't change default setting is because all the internal error pages uses latin1 (AddDefaultCharset on) and i didn't want to create a discrepancy between the config and the internal pages. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#257775: AddDefaultCharset default setting is misleading
On Tue, 6 Jul 2004, Fabio Massimo Di Nitto wrote: On Tue, 6 Jul 2004, [utf-8] Marc Dequènes wrote: Coin, Since setting AddDefaultCharset off can imply security problem we will never switch it to off. For more information please check the previous URL and the apache documentation on httpd.apache.org I'm OK with all this. May i suggest you add a small note in 'README.Debian' with links (especially http://httpd.apache.org/info/css-security/encoding_examples.html) so as people to understand and not reopen a bug when the old ones are archived ? It's now added to the README.Debian and it will be part of the next apache upload. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#257566: [INTL:tr] Turkish po-debconf translation
tag 257566 pending stop On Sun, 4 Jul 2004, Recai Oktas wrote: Package: apache Severity: wishlist Tags: patch l10n Hi, Please find attached the Turkish po-debconf translation. Thanks Deniz Bahadir Gur. Regards, Hi, thanks for the translation! It is included in our CVS now and it will be part of the next upload. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#256982: Upgrade of Apache fails due to configuration syntax error.
On Wed, 30 Jun 2004, David Grant wrote: Can you kindly post the relevant bits of the configuration? otherwise tar them all up and send them to me. Just rebooted to take advantage of kernel 2.6.6 and the problem is resolved. It would seem pointless to send the conf. now, but I can if you would like. Hi David, i couldn't reproduce the problem here. I am closing this bug but please feel free to reopen it if you encounter the same problem again. Thanks a lot for your help. Too bad we couldn't see what was wrong. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#258113: apache upgrade bug
On Wed, 7 Jul 2004, Rafi Rubin wrote: Package: apache Version: 1.3.31-2 While upgrading: Setting up apache (1.3.31-2) ... Starting web server: apache failed invoke-rc.d: initscript apache, action start failed. dpkg: error processing apache (--configure): I needed to stop apache before update to make it install. From which version of apache were you upgrading? Do you start apache automatically at boot time? Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: apache suexec, non-standard docroot
On Thu, 8 Jul 2004, R.M. Evers wrote: dear list, today i wanted to enable apache's suexec mechanism on one of our debian woody webservers, so that our customers can use cgi more securely. but in my infinite wisdom, i created all user accounts under /home/domains, instead of /var/www.. this means that, when suexec is enabled for a vhost, running a cgi script will result in an internal server error since debian's apache is configured with --suexec-docroot=/var/www. changing my configuration to conform to this standard is way too much work. and i really, really don't want to recompile apache.. so, does anyone know of a way to use suexec with a non-standard docroot for vhosts? or is this just simply impossible? You need to recompile suexec with proper patching. There is no other way around it other than changing your setup. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: apache suexec, non-standard docroot
On Thu, 8 Jul 2004, R.M. Evers wrote: thanks for your speedy reply. so it's possible to only recompile suexec? or do you mean i have to recompile apache with proper patching? suexec is compiled together with apache. It is possible to compile suexec on its own but it is much more complicate than compiling it together with apache, because suexec links with 2 libraries that are created while apache builds. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#258602: apache: /usr/local/bin not included in PATH environment
tag 258602 pending stop Hi Fredrik On Sat, 10 Jul 2004, Fredrik Åslund wrote: /usr/local/bin or /usr/local/sbin is not included in the default PATH environment for apache. Aren't those common enough to be considered default? Any CGI-script that uses programs not shipped with Debian requires their own PATH environment to be set (or a hard-coded path to the program). The PATH environment should be set to something like PATH=/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/sbin:/usr/sbin Thanks for spotting this problem that evolved in more than that. Actually the PATH is completely wrong since none of the sbin entries should be required for apache. In any case a fix is pending in our CVS that will include /usr/local/bin as well. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#258951: Cannot install apache-ssl
On Mon, 12 Jul 2004, Michael Still wrote: Package: apache-ssl Version: 1.3.31-2 Severity: normal After asking configuration information, the package fails to configure, and therefore doesn't start... If perhaps you can show us the error and the config files in /etc/apache-ssl that would help. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#259211: apache segfault after upgrade from woody
On Tue, 13 Jul 2004, SALVETTI Djoume wrote: Package: apache Version: 1.3.29.0.2-4 Severity: grave Justification: renders package unusable Good day, After upgrading from woody to sarge, apache doesn't start anymore. In /var/log/apache/error.log I can see : [Tue Jul 13 14:38:01 2004] [error] (2)No such file or directory: mod_mime_magic: can't read magic file /etc/apache/share/magic and apache -X give me a segfault (see attached strace). Can you try to disable php4? Thanks Fabio
Re: Bug#259211: apache segfault after upgrade from woody
reassign 259211 libc6 stop On Tue, 13 Jul 2004, Djoumé SALVETTI wrote: Le mardi 07/13/04 Fabio Massimo Di Nitto [EMAIL PROTECTED] a écrit : and apache -X give me a segfault (see attached strace). Can you try to disable php4? Indeed, if I comment : # LoadModule php4_module /usr/lib/apache/1.3/libphp4.so in httpd.conf, apache start fine (but without php support, of course). Hi all, we are back to the old problem again :/ Djoumé this is a very old and known problem, the only known workaround to it is to enable libapache-mod-ssl, even if unconfigured. We are all waiting for the libc6 maintainer to fix this issue. Jeff please it's time to fix this issue. This bug has to stay RC since it breaks unreleated packages. thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Processed: Re: Bug#259211: apache segfault after upgrade from woody
On Wed, 14 Jul 2004, GOTO Masanori wrote: Djoum this is a very old and known problem, the only known workaround to it is to enable libapache-mod-ssl, even if unconfigured. We are all waiting for the libc6 maintainer to fix this issue. Jeff please it's time to fix this issue. This bug has to stay RC since it breaks unreleated packages. What's problem? What's bug do you say about? We already added conflicts: old php. Both Jeff and Steve know all the details about it and they have been working on this problem. Please talk to them directly. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#262582: apache-common: apache-modconf doesn't accept correct syntax. dpkg reported error status 128 when installing libapache-mod-perl
retitle 262582 BASH3.0 BREAKS APACHE! THANKS BASH MAINTAINER. stop On Sun, 1 Aug 2004, Fabio Massimo Di Nitto wrote: Hi Philipp, On Sat, 31 Jul 2004, Philipp Bliedung wrote: Package: apache-common Version: 1.3.31-2 Severity: serious Justification: apache-modconf doesn't accept correct syntax *** Please type your report below this line *** apache-common: apache-modconf doesn't accept correct syntax. dpkg reported error status 128 when installing libapache-mod-perl Nothing has been changed in apache-modconf for a long while, so i am a little bit puzzled about this report tho it's the second one. Can edit apache-modconf and add a set -x in the second line and try installing libapache-mod-perl again? Never mind. This is bash3.0 that breaks the hell out of debian. Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: modules-config apache enable mod_ssl Exits w/ 128
On Thu, 29 Jul 2004 [EMAIL PROTECTED] wrote: Sorry to bother, but I'm having trouble with modules-config. Recently, I couldn't update libapache-mod-ssl. I tracked the problem down to it's postinst script, which calls modules-config apache enable mod_ssl. When I try running modules-config apache enable mod_ssl, modules-config prints the current / working directory twice, and exits with code 128 (same problem as with the postinst script). I couldn't find a bug against apache-common regarding this. I had a glance at modules-config, but it's big, I'm not experienced, and I haven't any error messages to go by; I thought I'd ask the pros before I wasted time searching for the problem. For all I know, I'm invoking it wrong. I'm running apache-common 1.3.31-2. Can someone identify the problem I'm having with modules-config? We just figured that the problem is related to bash3.0. A fix will be uploaded asap. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bulgarian translation
On Tue, 31 Aug 2004, Ivan Dimitrov wrote: Hello I've translated apache-1.3.31-1 debian/po/ file to Bulgarian, it is called bg.po, please reply to me where should I send the file, as I'm not subscribed to this list. Please send it to me or to the list. Thanks for your translation effort! Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#269377: apache: Upgrade broke Apache and PHP
tag 269377 moreinfo severity 269377 normal stop On Wed, 1 Sep 2004, Brian C wrote: 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.) This is a bit too generic. What if some other packages are at fault? Please provide us with at least the configuration file. 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. You need to enable the php4 module manually with something like: LoadModule php4_module /usr/lib/apache/1.3/libphp4.so otherwise php4 isn't used at all. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#269377: apache: Upgrade broke Apache and PHP
Please keep the bug number in CC. On Wed, 1 Sep 2004 [EMAIL PROTECTED] wrote: You need to enable the php4 module manually with something like: LoadModule php4_module /usr/lib/apache/1.3/libphp4.so otherwise php4 isn't used at all. Such a line is in my modules.conf after using dselect to install the module. /etc/apache/modules.conf looks like: [SNIP] Which other config files would be useful? I'd be glad to provide them. Also, it's hard to describe what the site does, but you can see it yourself at http://sharealike.org Check if httpd.conf loads either modules.conf or the php4 modules. Before you stated that you didn't accept the configuration, so if you are using an old one youwill have to maintain it manually Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#269377: apache: Upgrade broke Apache and PHP
On Wed, 1 Sep 2004 [EMAIL PROTECTED] wrote: Ok. I'll try to attach the index.php. Which config files would help? All of them. I need to reproduce your environment here. Also, the same problem occurs no matter which .php file I try to view on the site. regular .html files work no problem. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#269499: apache-ssl: SSL log directives don't work?
tag 269499 moreinfo
stop
On Wed, 1 Sep 2004, Rafael D'Halleweyn wrote:
Package: apache-ssl
Version: 1.3.31-5
Severity: important
The SSL log directives don't work for me, I only get a '+' in the logs.
Looking at the source in src/modules/standard/mod_log_config.c, I see
that the '%{clientcert}c' log directive is actually handled by
log_connection_status since it appears in the log_item_keys array before
log_ssl_info (and find_log_func matches on the first entry).
So, as far as I understand, the '+' in the logs is the 'status of the
connection'.
Since '%c' is the same as '%X', the '%c' directive should probably be
removed.
please attach you config files.
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#242543: More information
On Fri, 3 Sep 2004, Carl Johnstone wrote:
I've managed to track down why QUERY_STRING works and PATH_INFO doesn't.
In src/modules/standard/mod_include.c around line 2181 mod_include fixes up
the QUERY_STRING. If I add similar code to fixup PATH_INFO ie:
if (r-path_info) {
ap_table_setn(r-subprocess_env, PATH_INFO, r-path_info);
}
Then it fixes my problem with PATH_INFO not being set correctly.
I think what's happening is that mod_include is setting up the subrequest
using the values from the parent (main?) request. Then code has been
specifically added to correct the QUERY_STRING based on the subrequest, but
not the PATH_INFO.
If I setup a mod_perl that looks up a URI and then runs the subrequest, it
behaves as I expect with the QUERY_STRING and PATH_INFO set according to the
subrequest.
Carl
Can you give us the patch directly since you have it working?
Thanks
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#269757: apache-common: missing .info for mod_macro.so error during libapache-mod-php4 setup
On Fri, 3 Sep 2004, Jonathan Ah Kit wrote: I'm loathe to send in bug reports, but I've been asked to resubmit this as apache-common or post to the debian-apache list (see #269738), and seeing lists.debian.org says 'It is neither for submitting bug reports (please use the BTS for that), nor for support requests', I'm resubmitting it. OK, here's the short of it: Setting up libapache-mod-php4 (4.3.8-9) ... Error: mod_macro.so does not have a corresponding .info file. apache-common does not ship mod_macro.so or the info file. mod_macro is compiled in. Please check /usr/lib/apache/1.3/ for any mod_macro.so and move them somewhere. In any case that is a warning and not an error. It has been converted as such, a long time ago. I get the same error message when installing the latest apache 1.3.31-4 sarge package, *however* an error isn't reported by apache's setup. But as per above libapache-mod-php4 does, so setup doesn't complete. This is perhaps another bug related to php4 and i can't see why apache is at fault. In anycase the php4 maintainer reads the list. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#270214: httpd.conf issues with mod_backtrace and mod_whatkilledus
On Mon, 6 Sep 2004, Marc Haber wrote: Package: apache Severity: minor Hi, the httpd.conf in later apache packages configures mod_backtrace.c and mod_whatkilledus.c. The comment introducing that part of configuration contains an English error: +# They must NOT used in production environment if not for debugging! I am not a native speaker, but that looks like a be is missing here. Thanks for noticing it. Additionally, the following lines are not commented. Either even the IfModule and EnableExceptionHook lines should be commented as well, or the comments should state that the uncommented lines won't do any harm. Like in all the other part of the configuration. The configuration file is not a man page on how each directive works. The apache-doc package exists for this reason. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#270224: LogFormat directive probably incorrect
On Mon, 6 Sep 2004, Marc Haber wrote:
Package: apache
Version: 1.3.29.0.2-5
Severity: minor
LogFormat %h %l %u %t \%r\ %s %b \%{forensic-id}n forensic
This looks like we're missing a \ between the %{forensic-id}n and the
quote.
good catch.
Thanks for reporting
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: Bug#270418: apache: Apache initscript ignores system locale
severity 270418 wishlist tag 270418 wontfix stop On Tue, 7 Sep 2004, Ian Eure wrote: Package: apache Version: 1.3.31-5 Severity: important Tags: l10n From /etc/init.d/apache: -- snip -- ENV=env -i LANG=C PATH=/bin:/usr/bin:/usr/local/bin ... APACHECTL=$ENV $APACHECTL -- snip -- This renders PHP unable to display UTF-8 text with gettext; all non-ASCII characters are changed to question marks. LANG should be set from locales/default_environment_locale in debconf. Setting LANG to anything != C breaks at least another 200 things, like user configurations. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
