Bug#368225: please don't!
Toni Mueller wrote: Hello, I'd say that making a LAMP package that includes a lot of PHP stuff and not much else is sort of hijacking a good name for a bad purpose. If anything, packages like lamp-python (best language) lamp-perl (original definition of LAMP) lamp-php (in order of decreasing preference) should be created, but I'd also argue that replacing MySQL with PostgreSQL is a Good Thing (TM) in many cases. In any case, I think that also probably libapache-mod-chroot should be included and configured in any standard Apache install, and that the BTS probably isn't the best place to discuss such policy questions... What about creating a source called lamp that will create all these little tiny lamp-* packages (arch: all) that can be updated as you like indipendently from apache and leave apache on its own? Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368225: please don't!
Thom May wrote: I don't see there's any benefit in doing this _at all_, to be honest. It'll just turn into a whine fest when people don't get exactly what they want installed, and it then just becomes an unmaintainable mess. -Thom That's exactly why i don't want it in apache, and somebody can do it externally and take the blame ;) Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350683: FTBFS: wrong dependency on libapr1-dev
Roberto Pariset wrote: Package: apr-util Version: 1.2.2-3 Severity: important Justification: fails to build from source Hi, apr-util seems to FTBFS on everything but i386 because dependencies cannot be satisfied: E: Couldn't find package libapr1-dev. Maybe you should replace libapr1-dev with either libapr0 or libapr1.0. Thanks, Roberto Did you actually consider to build apr before apr-util? Fabio -- I'm going to make him an offer he can't refuse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
Olaf van der Spek wrote: Fabio Massimo Di Nitto wrote: David N. Welton wrote: Olaf van der Spek wrote: Hi, Do you mind if a NMU is done to fix this issue? No, go ahead - thanks! Perhaps waiting an answer from the maintainer would be better. Aren't you one of the maintainers? Yes. and the comment was not directed to you. David is not one of the maintainers and allowing NMU's for apache is not exactly polite without waiting an answer from the maintainers. I've been waiting for 1 year and 16 days already and this is not the only bug. Like some other bugs.. debian is based on volunteers that works in their spare time.. and so on... and so on.. stuff happens when it is possible, As Adam already said it is in his tree/queue for the next upload. He said so at 2005-11-25. At 2006-01-16 he uploaded 2.0.55-4 which did not contain a fix. That's because we are working on 2.2 as i am writing and 2.0 will be obsoleted sometime during next week Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
David N. Welton wrote: Fabio Massimo Di Nitto wrote: David N. Welton wrote: Olaf van der Spek wrote: Hi, Do you mind if a NMU is done to fix this issue? No, go ahead - thanks! Perhaps waiting an answer from the maintainer would be better. As Adam already said it is in his tree/queue for the next upload. Uhrm... oops. I thought this was one of mine - didn't realize it was addressed to debian-apache. Sorry. eheh no problem :) nobody is going to die ;) fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
Olaf van der Spek wrote: There are five maintainers listed in the maintainers field. Are you saying that none of them had time to post a reply that none of them have time to work on most of the bugs for the past/next year? Since i don't dig into the other 4 maintainer private lifes and I can only speak fr myself, yes, I had no time to look at apache for a while with a house to finish and a pregnant wife that can barely stand up (common pregnancy symptomps) and needs baby sitting more than apache. fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
Olaf van der Spek wrote: Fabio Massimo Di Nitto wrote: Olaf van der Spek wrote: There are five maintainers listed in the maintainers field. Are you saying that none of them had time to post a reply that none of them have time to work on most of the bugs for the past/next year? Since i don't dig into the other 4 maintainer private lifes and I can only speak fr myself, yes, I had no time to look at apache for a while with a house to finish and a pregnant wife that can barely stand up (common pregnancy symptomps) and needs baby sitting more than apache. I understand you have no time, and that's no problem, but wouldn't you notify other project members of that so they know? they do know. Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289868: NMU?
David N. Welton wrote: Olaf van der Spek wrote: Hi, Do you mind if a NMU is done to fix this issue? No, go ahead - thanks! Perhaps waiting an answer from the maintainer would be better. As Adam already said it is in his tree/queue for the next upload. Thanks Fabio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304785: Include /etc/apache/conf.d/*.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 304785 wishlist stop Piotr Roszatycki wrote: Package: apache Version: 1.3.33-4 Severity: important Please convert Include /etc/apache/conf.d to the: Include /etc/apache/conf.d/*.conf The files in this directory are handled by dpkg and i.e. ucf so there are problems after upgrades. Well perhaps a bit of explanation of the problem would help. Given that changing the default would simply make apache unuseable for several users that relies on the actual behaviour... Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX9njhCzbekR3nhgRAtuNAJ49hLqdu6mbidpD3qKsZ4KCIPpl6QCfYKOS CbwkRK0C/YSV4j4REO6mQhg= =lSXc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Package: apache-ssl | Version: 1.3.33-3 | Severity: important | | When I just upgraded apache-ssl, the postinst script did these modifications | without asking me: This is sounds quite impossible because apache uses debconf via ucf to ask if it is allowed to modify configurations or not and the level of interaction is decided by the user via dpkg-reconfigure debconf. If you have set it to non-interactive than of course things do not get asked. Please let me know if i missed something and if you can kindly check the above values. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9gphhCzbekR3nhgRAjCtAJsGJxKuoGSZixTgfGl4GjRmrOFrgwCggLpY MV9x6ADi2z3cDVjwdWBNXYU= =5ttB -END PGP SIGNATURE-
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Fabio Massimo Di Nitto [EMAIL PROTECTED] writes: | | |Bjørn Mork wrote: || Package: apache-ssl || Version: 1.3.33-3 || Severity: important || || When I just upgraded apache-ssl, the postinst script did these modifications || without asking me: | |This is sounds quite impossible because apache uses debconf via ucf to ask if it is |allowed to modify configurations or not and the level of interaction is decided |by the user via dpkg-reconfigure debconf. | |If you have set it to non-interactive than of course things do not get asked. | | | I don't think I have, but I have been wrong once before ;-) Can't | find any evidence of it though: | they look ok... | Anything else I should check? If you can efford to do a test break it would be great if you can rever the changes to the old config and do: dpkg-reconfigure apache-ssl and see if for some reason it happens again. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9hUchCzbekR3nhgRAq2bAJ4kh9eegmSk1v1TGP6xn5g61ZBKuQCghMb9 pW1cWHjFHvwlVyypWKansjc= =IRPA -END PGP SIGNATURE-
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Fabio Massimo Di Nitto [EMAIL PROTECTED] writes: | |Bjørn Mork wrote: | || Anything else I should check? | |If you can efford to do a test break it would be great if you can rever the changes |to the old config and do: | |dpkg-reconfigure apache-ssl | |and see if for some reason it happens again. | | | No, that didn't provoke it. I got the questions I already had | answered but /etc/apache-ssl/httpd.conf was not changed. That | includes the | | Include /etc/apache-ssl/conf.d | | which was not added either this time. | | Then I tried downgrading to 1.3.33-2 and upgrading again, but that | didn't change the config either. | | Hmm, seems I can't reproduce the error so it should probably be | archived as a bogus report. Please feel free to do so if you like. | | I am still wondering how the file got changed, though... | | | Bjørn Ah hold on.. one more test please.. i forgot about the md5sum check. Put the old config in place and edit (very carefully!) /var/lib/ucf/hashfile with the proper md5sum for /etc/apache-ssl/httpd.conf and test the upgrade again. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9h8whCzbekR3nhgRAn9JAJ9CA8RrtJyZXtiADCHUGo8q1JNeAACbBp+5 d8FmBY0hv6af8SfdwQrpucM= =dvn7 -END PGP SIGNATURE-
Bug#292122: /etc/apache-ssl/httpd.conf is modified without questions on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjørn Mork wrote: | Fabio Massimo Di Nitto [EMAIL PROTECTED] writes: | | |Ah hold on.. one more test please.. i forgot about the md5sum check. | |Put the old config in place and edit (very carefully!) /var/lib/ucf/hashfile |with the proper md5sum for /etc/apache-ssl/httpd.conf |and test the upgrade again. | | | | Yup, that's it: | | canardo:/etc/apache-ssl# md5sum -vc /var/lib/ucf/hashfile | /etc/logrotate.d/clamav-daemon FAILED | /etc/clamav/clamav.confmd5sum: can't open /etc/clamav/clamav.conf | /etc/papersize OK | /etc/nagios/checkcommands.cfg FAILED | /etc/clamav/freshclam.conf OK | /etc/clamav/clamd.conf OK | /etc/fonts/local.conf OK | /etc/apache-ssl/modules.conf OK | /etc/sensors.conf OK | /etc/apache-ssl/httpd.conf OK | md5sum: 2 of 9 file(s) failed MD5 check | canardo:/etc/apache-ssl# grep Port httpd.conf | Port 80 | SSLCacheServerPort /var/run/gcache_port | canardo:/etc/apache-ssl# apt-get dist-upgrade | Reading Package Lists... Done | Building Dependency Tree... Done | Calculating Upgrade... Done | The following packages will be upgraded: | apache-common apache-ssl apache-utils | 3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. | Need to get 0B/1599kB of archives. | After unpacking 0B of additional disk space will be used. | Do you want to continue? [Y/n] | Preconfiguring packages ... | (Reading database ... 61097 files and directories currently installed.) | Preparing to replace apache-utils 1.3.33-2 (using .../apache-utils_1.3.33-3_i386.deb) ... | Unpacking replacement apache-utils ... | Preparing to replace apache-common 1.3.33-2 (using .../apache-common_1.3.33-3_i386.deb) ... | Unpacking replacement apache-common ... | Preparing to replace apache-ssl 1.3.33-2 (using .../apache-ssl_1.3.33-3_i386.deb) ... | Stopping web server: apache-ssl. | Stopping web server: apache-sslNo process in pidfile `/var/run/apache-ssl.pid' found running; none killed. | . | Unpacking replacement apache-ssl ... | Setting up apache-utils (1.3.33-3) ... | Setting up apache-common (1.3.33-3) ... | | Setting up apache-ssl (1.3.33-3) ... | Replacing config file /etc/apache-ssl/httpd.conf with new version | Starting web server: apache-ssl[Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] VirtualHost www.mork.no:443 overlaps with VirtualHost www.mork.no:443, the first has precedence, perhaps you need a NameVirtualHost directive | [Tue Jan 25 11:46:24 2005] [warn] NameVirtualHost www.mork.no:80 has no VirtualHosts | . | | canardo:/etc/apache-ssl# grep Port httpd.conf | Port 443 | SSLCacheServerPort /var/run/gcache_port | | | Bjørn All right, i know remember exactly what the problem was/is. Basically older versions of apache-ssl had some problems to work properly with the default port != 443 and that was somehow hardencoded in the config manager for the port. We need to relax it and make it configurable as the other apache flavours. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9iXVhCzbekR3nhgRAra9AJ44glG+5S2hCvC+FMWzjRYZfw5KmgCgjuz3 6fTA42Y1MLY7uRt+sL/m7hk= =kA29 -END PGP SIGNATURE-
Bug#289493: apache-common: Where is mod_proxy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Low wrote: | Package: apache-common | Version: 1.3.33-2 | Severity: normal | | | It seems that mod_proxy is not (no longer) provided? | dpkg -c /mirrors/debian.org/pool/main/a/apache/apache-common_1.3.33-2_i386.deb |grep proxy - -rw-r--r-- root/root 304 2003-09-16 21:16:23 ./usr/lib/apache/1.3/260libproxy.info - -rw-r--r-- root/root 85768 2004-11-18 11:13:14 ./usr/lib/apache/1.3/libproxy.so It was never removed. Please for the next time do not submit bugs for questions. Use instead the mailing list. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4UpEhCzbekR3nhgRAlGvAJ922A+PJCwvahR4P4EuZKn9Unc7CQCfWLcc 01z9/CGV97fmOT78hiSmtTc= =d7WI -END PGP SIGNATURE-
Bug#288627: apache-ssl, logrotate.d file errors when reloads if apache is not running
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 288627 woody severity 288627 minor tag 288625 woody severity 288625 minor stop George Georgalis wrote: | Package: apache-ssl | Version: 1.3.26.1+1.48-0woody3 | | see: 288625 | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+288625 | | This will cause a problem on any box with apache-ssl installed but not | running, logrotate will error when it issues a reload for a not running | apache-ssl. | | | --- /root/logrotate.d.apache-ssl.orig Sat Oct 26 08:30:34 2002 | +++ /etc/logrotate.d/apache-ssl Tue Jan 4 14:02:42 2005 | @@ -8,6 +8,6 @@ | create 640 root adm | sharedscripts | postrotate | - /etc/init.d/apache-ssl reload /dev/null | + [ ! -f /var/run/apache-ssl.pid ] || /etc/init.d/apache-ssl reload /dev/null | endscript | } | | | | // George | Thanks for the reports, but we cannot fix these bug in the stable release. For stable release we can only fix security problems and bugs that makes the system completely unuseable. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB2wAxhCzbekR3nhgRAu69AKCbjwOlXLnMlz9aKEEQVIvPITTnnQCgjvPr qDW+fHfwWaAlYutiXp1WrK0= =lLqI -END PGP SIGNATURE-
Bug#286975: apache: FTBFS - x86/testing (31mrule: command not found)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Dowland wrote: | On Thu, Dec 23, 2004 at 01:18:06PM +0100, Fabio Massimo Di Nitto wrote: | | |I know for sure that configure explicitly requires bash, did you replace |/bin/bash with another |shell? Can you verify the bash md5sum? | | | ~$ md5sum `which sh` `which bash` | 6a01accdaa1baad9b2af1bcda2d80769 /bin/sh | 6a01accdaa1baad9b2af1bcda2d80769 /bin/bash | | |This is my best guess atm.. otherwise would it be possible for you to test |the same |in a fresh sarge/sid chroot? that would really help to isolate the problem |between your installed system and my build-test env. | | | I'd be happy to help in any way possible, although things might be | delayed over the christmas break as my machine will most likely be off. | Can I achieve this using pbuilder? | | Jon, nobody has been able to reproduce this problem. Can you kindly test again as we agreed? Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB14yxhCzbekR3nhgRAgywAJ9QuodnPZLwaiSI4IH2iriqnBKzMQCfYKIN BPJcrxMtmbUBGKXv8zUR1qc= =0Jbt -END PGP SIGNATURE-
Re: libapache-mod-perl : libperl.so does not have a corresponding .info file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathieu Jondet wrote: | Hi, | i've just run a apt-get dist-upgrade on my machine on debian/testing, | everything went well except for the mod_perl upgrade, here are the | information: | | mathieu:/home/mathieu# apt-get dist-upgrade | Reading Package Lists... Done | Building Dependency Tree... Done | Calculating Upgrade... Done | The following packages have been kept back: | eterm libdirectfb-dev pstoedit | 0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. | 1 not fully installed or removed. | Need to get 0B of archives. | After unpacking 0B of additional disk space will be used. | Do you want to continue? [Y/n] | Setting up libapache-mod-perl (1.29.0.2-16) ... | Error: libperl.so does not have a corresponding .info file. | The above errors might cause apache to not work properly or start | Please refer to the documentation on how to fix it or report it to | Debian Apache Mailing List debian-apache@lists.debian.org if in doubt | on how to proceed | dpkg: error processing libapache-mod-perl (--configure): | subprocess post-installation script returned error exit status 20 | Errors were encountered while processing: | libapache-mod-perl | E: Sub-process /usr/bin/dpkg returned an error code (1) | mathieu:/home/mathieu# | | Can someone point me to any direction in solving this issue ? | Thanks. | | Mathieu | | You need to upgrade libapache-mod-perl as well. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB14wZhCzbekR3nhgRAt0KAJ94TrE+aK9FXzJ26XUTJ57p5gGuigCgnfR6 xxpENVQv8TmTe95+f6nSNME= =NYID -END PGP SIGNATURE-
Bug#286975: apache: FTBFS - x86/testing (31mrule: command not found)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jon, Jon Dowland wrote: | Package: apache | Version: 1.3.33-2 | Severity: serious | Justification: no longer builds from source | | Hi, I'm sorry to be filing this as I'm finding it hard to believe that | this could be a problem for anyone but me. Unfortunatly i cannot reproduce it here at all, neither on sarge or sid. | | cd build-tree-apache/apache_1.3.33 LDFLAGS= CFLAGS=-O1 -g -Wall -D_LARGEFILE_SOURCE - -D_FILE_OFFSET_BITS=64 ./configure --suexec-logfile=/var/log/apache/suexec.log --target=apache - --with-layout=Debian --enable-suexec --suexec-caller=www-data --suexec-docroot=/var/www - --includedir=/usr/include/apache-1.3 --without-confadjust --without-execstrip --enable-shared=max - --enable-rule=SHARED_CHAIN --enable-module=most --enable-module=status --enable-module=auth_digest - --enable-module=log_referer --enable-module=log_agent --enable-module=auth_db - --activate-module=src/modules/extra/mod_macro.c | Configuring for Apache, Version 1.3.33 | ../configure: line 1: rule_[01: command not found I know for sure that configure explicitly requires bash, did you replace /bin/bash with another shell? Can you verify the bash md5sum? This is my best guess atm.. otherwise would it be possible for you to test the same in a fresh sarge/sid chroot? that would really help to isolate the problem between your installed system and my build-test env. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByrd8hCzbekR3nhgRAnyMAJ9oj0YrLvR9q/e/yPTbxEp/FmFPLQCgjsCZ nqqFxdUNeMKZrnq5c2qq7vo= =LhWo -END PGP SIGNATURE-
Bug#286975: apache: FTBFS - x86/testing (31mrule: command not found)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Dowland wrote: |This is my best guess atm.. otherwise would it be possible for you to test |the same |in a fresh sarge/sid chroot? that would really help to isolate the problem |between your installed system and my build-test env. | | | I'd be happy to help in any way possible, although things might be | delayed over the christmas break as my machine will most likely be off. | Can I achieve this using pbuilder? Yes. I did test with pbuilder too and i still can't reproduce the bug. Perhaps something related to your user environment? Fabio PS i will leave for xmas holydays in a few hours too... so if we don't manage to figure out the problem, don't worry.. we will work on it on monday. - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByrxhhCzbekR3nhgRAi13AJ9YCnU7i3MG/8MuscUHCWhkEV9P5ACggS21 7zDLuTqmzp81QLhc88NIgN0= =q/mw -END PGP SIGNATURE-
Bug#286740: apache: log directory should have same permissions as logfiles (possible information disclosure)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Minar wrote: | On Wed, Dec 22, 2004 at 09:57:13AM +0100, Fabio Massimo Di Nitto wrote: | |tag 286740 - security |thanks | |Jan Minar wrote: || Package: apache || Version: 1.3.33-2 || Severity: minor || Tags: security || || Hi. || || /var/log/apache is world-readable, so users can e.g. check whether || certain operation triggered an error. And given that the error strings || are pretty standardized, they can guess what string has been added to || the logfile, judging by the number of bytes that was appended to the || log. || || As this is not very obvious to the system administrator, and as there is || no use of /var/log/apache directory being readable and searchable while || the files in it are not, apart from the information disclosure described || above, I think it should be chmod-ed 750, just as the logs in it are || chmod 640. || | |There is no point in such operation. If a user have a local account |it also has at least a few other thousands options to make a DoS on apache. | | | Apples and pears. Information disclosure and DoS. And BTW, fix the | DoSes too. Oh GREAT.. so let see... i should go around the world changing all the hardware on the planet because each user on a machine can use ab or any kind of tool that can telnet to port 80 generating millions of requests on the localhost server? Therefor slowing down the machine? You are welcome to provide me the money to do so, together with patches to each config file for each apache server out there so that there will be always available resources. | | IMVHO, You should at least read the bugreports before You are closing | them... | So let see.. provide me a PoC that i can use to gather information out of this theorerical bug that can lead to DoS or privilege escalations and i will fix this bug immediatly. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByVAkhCzbekR3nhgRAgbPAKCR8mO8qJ6QVeQckIbXrFnHWnW5TwCeNbqF m0InhwqL4T0+geIvD1jCqNw= =nHUG -END PGP SIGNATURE-
Bug#286740: apache: log directory should have same permissions as logfiles (possible information disclosure)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | On Wed, Dec 22, 2004 at 11:44:54AM +0100, Fabio Massimo Di Nitto wrote: | | |There is no point in such operation. If a user have a local account | |it also has at least a few other thousands options to make a DoS on | apache. | | | | | | Apples and pears. Information disclosure and DoS. And BTW, fix the | | DoSes too. | | Oh GREAT.. so let see... i should go around the world changing all the | hardware | on the planet because each user on a machine can use ab or any kind of tool | that can telnet to port 80 generating millions of requests on the localhost | server? therefor slowing down the machine? | | No, No one ever asked you to do so. But please read your original statement - | are you _seriously_ suggesting that you won't fix a potential problem only | because there might be other problems as well? So, are your really saying that | apache can'T be used in a professional ISP environment (where customers share | servers and have local accounts)? Hmm, i should have a serious talk with our | providers then. This is a more than common problem on every kind of servers you run. There is nothing new about it. It can be apache, it can be whatever other service. On a network environment the situation can be slightly different since you are limited (somehow) to the available bw to provide a DoS. or to scan the network.. etc. The fact that you already have access to the box will give you many otherways to do whatever you want (or almost) on the machine. So if we really want to be paranoid, why that user have local access in the first place? If the user for example can write .htaccess file, it is enough for him to write wrong entries in there to make the server generates errors, without even the need of checking the log file. | BTW, your reply is rather murky on the technical side: the bug report doesn't | talk about a DOS, it mentions information leakage which is a differnt kind | of thread (and i hope you consider privacy important). The example the OP has done about monitor error logs doesn't provide you any vital information from the running server and even if you can barely guess what has been written to the log file, there almost no use of these info. Remember that you are not monitoring access.log that can contain real sensible data. | you are welcome to provide me | the money to do so, together with patches to each config file for each | apache server out there so that there will be always available resources. | | | The OP just asked for a change of permission on the directory - what's so time- | consuming about that? ~ When i learned system administration one of the key points | was to keep all configuration and logging data as private as possible. Can you | provide any reason for the logging directories _not_ having 750 permission? | It is pointless since you cannot read the files. | | | | | IMVHO, You should at least read the bugreports before You are closing | | them... | | | | So let see.. provide me a PoC that i can use to gather information out | of this theorerical bug that can lead to DoS or privilege escalations | and i will fix this bug immediatly. | | | Apache does write to logfiles in buffered blocks. By monitoring the file | io of the log file one can get a pretty good picture of the traffic amount | and access patterns for the corresponding server. Some of my customers _would_ | consider this bussiness-confidential data ... checking the file size doesn't provide enough information about the traffic or access patterns. Your server could get one request for TeraByte of data or 10 request for nothing and the log entries would change in size anyway according to the requested URL. Therefor there is no match between amount and size of the requests. | One can also monitor whether a certain scan/exploit etc. triggers logging to | the error log - this is pretty much like a login program that tells you that | a user doesn't exist :-) If a user has access to the machine, he/she doesn't need to look at apache logs to gather these information. | | BTW, why is it that a lot of bug reporters are greeted with irony/sarcasm | or neglectance here? A security bug as it claims to be is either serious or is not a security bug. I have never heard of minor security bug. Did you? Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByVqHhCzbekR3nhgRAsZoAKCKwSX0Os6BXBW6LgDuAaK7jJwseACeIU+e xHrCoEoNYQbukfCjaOqhakM= =rNEp -END PGP SIGNATURE-
Re: Bug#286740: apache: log directory should have same permissions as logfiles (possible information disclosure)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Ce jour Wed, 22 Dec 2004, Fabio Massimo Di Nitto a dit: | | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |[EMAIL PROTECTED] wrote: || On Wed, Dec 22, 2004 at 11:44:54AM +0100, Fabio Massimo Di Nitto wrote: || | | | it's funny, 'cause both of you have made good points. thing is, i've | already chmodded my apache* log dirs 750 =;). | | this situation is different here though. only people allowed shell | access are trusted people, therefore it doesn't matter much. | | the thing about security is to layer it. the more layers you have, the | better. eheh see.. people here are mumbling about /var/log/apache - and talking about layers, why do they have access to /var/log in the first place? ;) | | say an attacker breaks through one layer, there is yet another few or | several layers they have get through to actually do any real harm. chmod | 750 a log dir may or may not be a part of that. seems it's a touchy | subject... but privacy concerns - for both individuals and organisations | - are important too. It is a very touchy argument, specially when people want more tight permissions while others want them more relax to be able to run their favourite apache log parser to generate stats. We had a neutral position for ages to avoid to move the balance towards one or another side and we are not going to change it. | | how about: either having a short debconf question about chmod 750 | /var/log/apache*, and asking yes or no; another debconf question would be overkilling. ~ or, a mention in README.Debian | about it. an admin that wants to do that anyway will do it, and for | others it might give them something to think about. | | (yes this is a proposal *grin*). | see that's another point.. an admin that install services should always check them. For how sane we can provide certain defaults, there will be always thing that will not work for someone in one way or another. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByXjyhCzbekR3nhgRAqBtAJ0cGC4W2ECNKO8cMXqCagfFWwKF8QCfXfNW WBS+segxptigxDcXdhzEXNg= =z07S -END PGP SIGNATURE-
Bug#286604: apache using large amounts of CPU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
severity 286604 important
reassign 286604 php4
thanks
PaulWB wrote:
|
|
| package: apache
| version: 1.3.33-2
| severity: critical
|
|
| A module or package has been upgraded recently and is creating large
| problems for apache
if a module has been upgraded that creates problems for apache, it is not
an apache fault.
|
| Process 10487 attached - interrupt to quit
| --- SIGALRM (Alarm clock) @ 0 (0) ---
| sigreturn() = ? (mask now [])
| --- SIGPROF (Profiling timer expired) @ 0 (0) ---
| setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={240, 0}}, NULL) = 0
| rt_sigaction(SIGPROF, {0xb7708830, [PROF], SA_RESTART}, {0xb7708830,
| [PROF], SA_RESTART}, 8) = 0
| rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
| mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
| -1, 0) = 0xb7249000
| munmap(0xb7249000, 749568) = 0
| munmap(0xb740, 299008) = 0
| mprotect(0xb730, 135168, PROT_READ|PROT_WRITE) = 0
| open(/local/logs/php, O_WRONLY|O_APPEND|O_CREAT, 0666) = 7
| fstat64(7, {st_mode=S_IFREG|0777, st_size=58064679, ...}) = 0
| mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
| 0) = 0xb7448000
| fstat64(7, {st_mode=S_IFREG|0777, st_size=58064679, ...}) = 0
| _llseek(7, 58064679, [58064679], SEEK_SET) = 0
| time([1103599287]) = 1103599287
| write(7, [21-Dec-2004 14:21:27] PHP Fatal..., 142) = 142
This call looks very suspicious.. why should it be Fatal?
| close(7)= 0
| munmap(0xb7448000, 4096)= 0
| chdir(/) = 0
| futex(0xb7e76620, FUTEX_WAIT, 2, NULL
|
|
Fabio
- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBx7snhCzbekR3nhgRAvgyAKCd9fzoYhAHrqqVfgvsZkp2q/LwQgCffhfB
hNZlnREWiF3OfulzmG4NV54=
=pxhD
-END PGP SIGNATURE-
Re: Question about maintaining the unofficial/parallel apache-lingerd package.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexis Sukrieh wrote: | Hello there. | | I'm maintaining an unofficial package, apache-lingerd [1]. | It's a new flavour of the official Debian apache source tree. | | As it won't be included in Debian, and as some users requested me | to maintain the package against the last sid packages, I'm a little bit | confused : | Alexis, with all respect, you have send out this mail after only 2 days you have tried to contact me in private and i had no time to answer. I find a bit annoying that you jump to conclusion so fast. I understand that there is a possible request for your packages, but as I already explained to you, adding another flavour of apache is not necessarely simple. Also, I was going to ask you to discuss the security history of lingerd together with out security team as next step. If we need to add this flavour, we need to know first if it has any security complication or bad security history. Did you also consider to start creating patches for all modules so that they can use lingerd? As personal opinion I need to agree with Tollef, that apache1.3 is basically a dead package and it might get removed from Debian after Sarge is released. That means providing only security support to it. Are you ready to give such commitment to your package? What I really don't want is to endup maintaing another flavour on my own and i guess this is the same for the other memebers of the team. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBoDwshCzbekR3nhgRAlh/AJ9CMoFmGfCgFkq2TQIBHvU+XnxVWwCeN+7n rLo/ZyMkHKDbD47IW6AlQYI= =pg4V -END PGP SIGNATURE-
Bug#280206: apache: Apache wont start, FD_SETSIZE set too low in 1.3.31-7?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Bredlöv wrote: | Ok, I understand. | | A little googling shows that many people have tried adding CFLAGS, but in lots of cases they werent being used. I guess they didn't add them in the right spot, or something else over-wrote the change. | | Could you please check again to make sure it went in? | | Regards, | Peter Please Peter keep the bug address in CC and also please give me the time to look at it. Asking me updates on the problem doesn't help either. Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBnjGrhCzbekR3nhgRAt+zAJ4mLRQEwxXvShsanEnXo+SMkHlHoQCeK5tf OOdGu+cLPPW0Yos9bx2MvQs= =KlOu -END PGP SIGNATURE-
Bug#280233: Bug#280871: Problems with apache, PHP, MM and UML.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reassign 280871 libmm11 reassign 280233 libmm11 merge 280871 280233 severity 280871 grave severity 280233 grave tag 280233 woody tag 280871 woody stop Hi Mark, the last libmm11 stable update breaks apache badly. I received already other reports via irc (also related to non UML environments) and clearly it needs to fixed asap. Joey please consider either pushing fixed packages via a security update or to make them available for stable somehow. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmuZ1hCzbekR3nhgRAjeEAKCjfieC2zePloI7cj15ZUkcLNaPIACgjIkj ydgZ5rbhEQW8QpkZjTqRTJ0= =7BZW -END PGP SIGNATURE-
Bug#281387: ucf: too many arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakob Goldbach wrote: | Package: apache | Version: 1.3.31-7 | | configure fails for apache when you have to many Include files. | | I have a config file for each virtual host - and include them with | Include /etc/apache/vhosts/*.conf | | | Perhaps you want to add the config files? or tell us how many files are in the vhosts dir? What error message do you get? Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmMrYhCzbekR3nhgRAs2oAJ4w76FHMBLxjg5PPaukzc3dGqpaNACfVXS1 PtwOungeDVkXqleLM6fH1e8= =/ec0 -END PGP SIGNATURE-
Bug#279690: apache-ssl: Segmentation fault when accessing any pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giacomo A. Catenazzi wrote: | Fabio Massimo Di Nitto wrote: | | | Can you please attach the configuration files? What modules are you | using? | | Fabio | | | SSLNoV2 | Can you please try to comment this out? Thanks Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBlHtOhCzbekR3nhgRAoDWAJ9US21RfJl5t9mT7x/6ZBNnc0aGZQCfdsA7 ZytpsZW9LFE8XTzjkc0sV2E= =AnFJ -END PGP SIGNATURE-
Bug#280206: apache: Apache wont start, FD_SETSIZE set too low in 1.3.31-7?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Bredlöv wrote: | I installed apache, apache-common and apache-utils, but the same error comes up; | | [Wed Nov 10 01:55:34 2004] [warn] make_sock: problem listening on port 443, filedescriptor (1128) larger than FD_SETSIZE (1024) found, you probably need to rebuild Apache with a larger FD_SETSIZE | | /usr/sbin/apache -v gives: | | Server version: Apache/1.3.33 (Debian GNU/Linux) | Server built: Nov 9 2004 07:10:29 | | Now im confused ;) | | Yes that's ok.. but did you install the packages from the url i gave to you? I explicitly forced FD_SETSIZE to 4096 Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBlIiBhCzbekR3nhgRAgo7AJ4grMHvHxAbtcRQ+J4hH7odY8Z9WACggKmC uHtyIOjZ1g6Y8VvwuMIhY88= =AnF9 -END PGP SIGNATURE-
Bug#280206: apache: Apache wont start, FD_SETSIZE set too low in 1.3.31-7?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 280206 moreinfo thanks Peter Bredlöv wrote: | Package: apache | Version: 1.3.31-7 | Severity: important | | I recently upgraded from 1.3.31-6 to 1.3.31-7. After this, apache wont start | any more unless I disable the log files I have for my around 2000 virtual | hosts. | | This is a sample row that shows up in my main error log when I try to start | with logging enabled: | | [Tue Nov 2 00:36:40 2004] [warn] make_sock: problem listening on port 80, | filedescriptor (1069) larger than FD_SETSIZE (1024) found, you probably need | to rebuild Apache with a larger FD_SETSIZE | | Although things are working ok without logging, it would be nice to be able | to get logging to work again even for this relatively large number of vhosts. | Could this be fixed? | | Regards, | Peter Bredlöv Did you also change the kernel on this machine? there have been no changes at all to apache on that front and i suspect that either you increased the number of vhosts or the kernel is limiting something else. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBjyOghCzbekR3nhgRAuC1AJ9zr2/uwe98OQmwcUQ0Nc6dSAKBQQCeKtsw L/olb7H8/ZpR7O5nBAfQTIQ= =3P/g -END PGP SIGNATURE-
Bug#279753: apache: execute arbitrary code via SSI issue (CAN-2004-0940)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hideki Yamane wrote: | Hi, | | | Yes, stability is most important thing in stable release. | | I would ask you that it needs to be built on all woody arch means | it needs more time to be checked because changed source should be | able to be built on each arch or it needs more time to be built in | all arch machines? both? a combination of all of them :-) the source needs to build on all supported architectures and tested. Clearly you cannot do the latter without the former ;) Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBizq4hCzbekR3nhgRAoTUAJ0ZrdOs3hlmugRSPz92haZUS53EdACePARU JA1rfSoNX2/x6G41OpvWzlU= =dLmU -END PGP SIGNATURE-
Re: Bug#279753: apache: execute arbitrary code via SSI issue (CAN-2004-0940)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is offtopic for the bug. Hideki Yamane wrote: | Hi, | | Fri, 05 Nov 2004 09:32:59 +0100, Fabio Massimo Di Nitto | Re: Bug#279753: apache: execute arbitrary code via SSI issue (CAN-2004-0940) | | Is that review process on public or closed? If it is on public, | where can we read about that? closed. | If some arch (not powerful architecture like arm or m68k, etc) | needs more time to build package than i386 and so it makes release | late, I think we should do KAIZEN about build system. No. this is specified in the security release process. All the archs will get the update at the same time. | (or use some emulation environment like Scratchbox as test. | It is 10 times faster than native env.) | http://linuxdevices.com/articles/AT6264230012.html It is not the same as running on the native arch and it might introduce unwanted side effects. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBi0lahCzbekR3nhgRAs5IAJ4segE2AF7Who1wyW2hmOrD1fsimwCfZ0BQ tlSUW/N9/m7s81SjlNfRBX8= =Lq1n -END PGP SIGNATURE-
Bug#279865: acknowledged by developer (Re: Bug#279865: apache-common: CAN-2004-0940 Vulnerable?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helge Kreutzmann wrote: | Hello, | On Fri, Nov 05, 2004 at 06:18:12AM -0800, Debian Bug Tracking System wrote: | |Thanks for reporting this twice already. Please before filing bugs you are welcome to check both |debian-apache mailing lists and bugs.debian.org/src:apache. | | | I *did* check the bts (though admitingly without using the | src:-prefix). Sorry to miss #279753. But this one is closed, and I | assumed to either find an open bug, or an entry in the non-vuln-list. | Is there a reason #279753 is closed already? If you keep it open, then | everyone can see that this is being activly worked on. And technically | speaking, the bug is still open. Because it has been openly discussed on the mailing list all the security teams are already working on it. Plus one of apache1.3 maintainer is upstream too and we follow the package closely and constantly. Also people should not panic everytime there is security bug. Sid has been fixed in less than a few hours. woody takes more time and it is always followed by the related DSA if the problem affect a stable release. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBi54PhCzbekR3nhgRArVKAKChFzlwir3v5nU6TUDjcPOu8c7DlwCgg8YY cmNVSkfCX8e1dNx785axfAk= =skKx -END PGP SIGNATURE-
Re: Apache 1.3 on woody largefile problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Morley wrote: | Hi, | | I sent this to debian-user, but haven't heard anything. I didn't know if I should submit it as a bug, or send it here first --- sorry if I'm doing it the wrong way. Please point me to the right place otherwise. | | (please note I bumped to r3 and it still happens) | | thanks a bunch! | adam | | begin forward | Hi, | | I have a system running Debian Woody 3.0r2 (have yet to bump to r3) with the latest security patches as of today (Nov. 1) with apache 1.3.26-0woody5 (from dpkg -l). | | Short version: files 2GB don't get seen as 2GB, and it looks like largefile support doesn't work, in both GET and HEAD requests. | | I create a file in /var/tmp 2GB (2GB + 3 kbytes): | | dd if=/dev/zero of=/var/tmp/tester bs=1k count=2097155 | | and point apache to /var/tmp as document root (httpd.conf): This is an upstream limitation. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=156972 Cheers Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBiIwqhCzbekR3nhgRAvJ+AJ9vg7A0ibV6XBHeJCCqIqE8J6EM2QCfSehE BZp0DiwdRMoQoQlH8nFt2B8= =5D6Y -END PGP SIGNATURE-
Bug#277124: apache-common: /var/lib/apache/mod-bandwidth permissions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Lammerts wrote:
| Thom May wrote:
|
| Thank you so much, we hadn't noticed we were deliberately creating a
| directory with 777 permissions.
| (yes, it is necessary, and yes, it is really necessary, and yes it's
| absolutely necessary).
|
|
| Well, maybe you can explain why? This directory is not gonna be accessed
| by anyone except apache, right?
|
| I would read the RTFM you know, if there was any...
There is one copied in several locations:
zless \
/usr/share/doc/apache{,-ssl,-perl,-dbg,-utils,-common}/README.Debian.gz\
| head -n 20
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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBdK1phCzbekR3nhgRAlPlAJ48k2OFDNbq1p3fLiPaKBkV2Yr67wCfSZ6T
Sy5XayLIY+aK6z7bzwRvtkg=
=ZmZP
-END PGP SIGNATURE-
Re: help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Priya Ranjan wrote: | Hi I am not a member of this list but I need some help. I was trying to | install libapache-mod-perl and uninstall also but it was giving me grief | as shown below. | Any solutions? | thanks, | -priya | | | (Reading database ... 97252 files and directories currently installed.) | Removing libapache-mod-perl ... | Error: libphp4.so does not have a corresponding .info file. | The above errors might cause apache to not work properly or start | Please refer to the documentation on how to fix it or report it to | Debian Apache Mailing List debian-apache@lists.debian.org if in doubt | on how to proceed For some reasons your php4 installation is broken or not complete. This causes an error in the sanity checks we perform in order to handle the apache configuration properly. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBa3sihCzbekR3nhgRAoG/AJkBoXJ8R1spimvZqSwRq0b68KEP/gCggx66 kHl8VtwVmdqe+3NS6K9WHXo= =jtzq -END PGP SIGNATURE-
Re: Problem with segfaulting Apache 1.3.31-6 on Debian Sarge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Neumaier wrote:
| Hi,
|
| with the latest apache update i get an segmentation fault in apache
| while reading /usr/share/misc/file/magic/mime.
|
| If i do an 'strace apache -F' i get the following output:
|
| open(/usr/share/misc/file/magic.mime, O_RDONLY) = 4
| fstat64(4, {st_mode=S_IFREG|0644, st_size=26861, ...}) = 0
| mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
| 0) = 0x48997000
| read(4, # Magic data for KMimeMagic (ori..., 131072) = 26861
| read(4, , 131072) = 0
| close(4)= 0
| munmap(0x48997000, 131072) = 0
| --- SIGSEGV (Segmentation fault) @ 0 (0) ---
| +++ killed by SIGSEGV +++
|
| If i run it with 'gdb --args apache -F' i get this:
|
| Program received signal SIGSEGV, Segmentation fault.
| [Switching to Thread 1076565824 (LWP 23328)]
| 0x401f0568 in strcmp () from /lib/tls/i686/cmov/libc.so.6
|
| This even happens with when i run apache with -X...
|
| I've no clue why this happens - nor why it happend only last sunday
| morning when apache was restarted during the logrotate. Apache-ssl is
| not affected by this behavior.
|
| Some Package informations:
|
| ii apache 1.3.31-6 Versatile, high-performance HTTP server
| ii apache-common 1.3.31-6 Support files for all Apache webservers
| ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries and
| Timezone
| ii libc6-i686 2.3.2.ds1-16 GNU C Library: Shared libraries [i686
| optimized]
|
| Kernel is a 2.6.7
|
| Has anyone any hint for me how to get rid of this? Sadly using apache2
| is not a solution for me...
Are you running php4? In this case it is a know problem and either you
install libapache-mod-ssl (even unconfigured) or you remove php4.
The real problem is located down in the lic6 elf loader but there is not
much to do about it until there will be a fix for 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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBY9ZphCzbekR3nhgRAo/MAJ47XLCrzbWivkLzMiOMo9oKqCkwgwCfcxHh
sTsoWIoCuMIwphUDUXFFRd8=
=K+Aa
-END PGP SIGNATURE-
Re: Need some help to package apache-lingerd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexis Sukrieh wrote: | Hello there. | | I'm pretty interested in trying to package apache-lingerd, which has | been requested for more than 500 days now : | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=187460 | | Could someone point me to some piece of docs on how the Debian Apache | Maintainers team bild their package ? eheh the truth is that our documentation is our debian/rules file. | | The fact is that lignerd needs the following steps to be packaged : | | First step : building lingerd : | | - tuning of config.h file | - user creation : 'lingerd' | - directory creation for hosting pidfile and unix domain socket | (/var/run/lingerd). | - compilation of lingerd binary and installation of it. This can be done easily afaict. | | Second step : patching Apache. | | - add some files to the apache src source tree | - patch some apache native files | - compile apache Amen.. this is a pain. I really suggest you to look at how we build apache. Take as example the fact that from the same source we create binaries for apache, apache-perl and apache-ssl, but if you really really need to create a patched apache i sugget to prepare everything carefully and coordinate with us. It is easier to build a new apache flavour from the same sources than having to upload a new one. The security team would have serious problems to handle (again) more than one apache source. | | Third step : | | - update the init.d startup script for apache : lingerd must be launched | before apache to work properly. if you start from the apache package check debian/pkgtemplates and the script that creates the final scripts. | | I'm sure that the team has a lot of guidelines to build such a package | but I cannont find any docs about this. as above.. read the source luke ;) | | Help will be welcome :) | | 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBYYiRhCzbekR3nhgRAn9kAKCV8jPp0iU20wmuEvipphiOQeZIjQCdGDOT qJXBQPpDRJnmyzN8+9REP/A= =ktLr -END PGP SIGNATURE-
Bug#272463: (no subject)
reassign 272463 libapache-mod-php4 stop -- 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#272069: apache: fix for #269009 raised a new problem
tag 272069 wontfix severity 272069 wishlist stop On Fri, 17 Sep 2004, Gerfried Fuchs wrote: Package: apache Version: 1.3.31-6 Severity: important #269009's usage of www-browser instead of lynx raised a new problem: Not all www-browser alternatives do support -dump. This is a browser problem. Almost all the www-browsers support -dump. I fail to see why it is an apache problem to work around it. A package that offers an alternative should be capable to provide all the basic options as the others. netrik e.g. does need --dump. Switching to --dump on the other hand would make w3m getting problems. I don't know for other browsers that do the www-browser alternative like (e)links, lynx supports both. Well one of the 2 will have to switch. I am not dealing to implements 20 different exceptions because of this. This needs to be addressed soon and should IMHO definitely go into sarge. What a clean solution is I don't really now. It would be great if w3m supports GNU-style options, but I don't think that that is going to happen soon. I am leaving this bug open, but i don't believe it is our job to fix it so for me it's a wishlist that i wontfix. If you have valid arguments, I am wide open for discussion (that's why i am not closing it), but to me looks like an inconsistency between www-browsers that needs to be solved there. 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#271945: apache in woody is missing security patches/updates
On Thu, 16 Sep 2004, Matt Zimmerman wrote: Maintainers, please raise the severity of this bug and contact the security team if this is an urgent issue. Please can we have at least the CAN number and reference? Joey has been keeping track of this iirc. 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: Can apache display file size correctly which is bigger than 4G ?
On Wed, 15 Sep 2004, cwinl-debian-apache wrote: hi,all: I put some DVD image files(each more than 4GB) into an apache's directory. but i found that file size is xxxMB when i open that dir in IE browser . why? is it apache's bug? No it's a limitation. You need apache2 for LFS. 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-mono has screwed up my apache
On Tue, 14 Sep 2004, Mike McKay wrote: Hi, I am getting the following error whenever I try and do pretty much anything (installing Squirrelmail) via apt now: Error: libmod_mono.so does not have a corresponding .info file. The above errors might cause apache to not work properly or start Please refer to the documentation on how to fix it or report it to Debian Apache Maling List debian-apache@lists.debian.org if in doubt on how to proceed Error: libmod_mono.so does not have a corresponding .info file. The above errors might cause apache-perl to not work properly or start Please refer to the documentation on how to fix it or report it to Debian Apache Maling List debian-apache@lists.debian.org if in doubt on how to proceed I followed the instructions for installing mono from source (again, mod-mono is from source, not from apt) which basically directed me to add the following to my httpd.conf: [SNIP] I have had this problem for a while now, but now I need to install squirrelmail which apparently requires clean apache upgrades. The error message recommended me getting in contact if I don't know how to fix it - so here I am. I think I need to generate a .info file, but I the semantics of such a thing are beyond me. Hi, please install apache-dev and read /usr/share/doc/apache-dev/REAMDE.modules It will explain to you what a .info file is and how to create a proper one for your apache installation. The above is a warning to prevent external module to mangle apache configuration (given that the user is using standard debian tools for it). Nothing to be scared about. it's one line and one file :-) 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#271302: init.d script should not kill other unrelated apache processes
On Sun, 12 Sep 2004, Jeroen van Wolffelaar wrote: Package: apache Version: 1.3.31-6 While upgrading apache in a chroot, I noticed that: (a) there are two lines trying to stop apache, and not one: Preparing to replace apache 1.3.31-3 (using .../apache_1.3.31-6_i386.deb) ... Stopping web server: apache. Stopping web server: apacheNo process in pidfile `/var/run/apache.pid' found running; none killed. . This might be a different issue, and fwiw, I don't consider the mere fact that two lines are displayed a bug worth reporting. Yes they both come from maintainer scripts. unfortunatly there is a nasty problem upgrading from woody and apparently apache doesn't get kill as it should. We had to force this is a really hard way to avoid problems later on. like the reload at the first logrotate (there were other bugs related to woody-sid upgrade that you can find in the BTS). (b) It killed the apache process that was running on the main system in addition to the one in the chroot. The init.d script should _not_ touch random processes called 'apache', but only those that are part of the apache package. The init script doesn't do that. The prerm kills all `pidof apache`, it could at least use `pidof /usr/bin/apache to limit it to processes that are Debian's apache (this will not fix killing of apache in other/parent chroot's, but is still better). I will take this as a wishlist but if you notice from a ps ax the process is only apache. In order to really fix killing of processes in different chroots, you could check whether /proc/$PID/exe is a symlink to '/usr/bin/apache' (and doesn't give an error). For chroots that are below the root of the current process, that will give /chroot/usr/bin/apache (for example), and for roots that are upwards of the current root, it will give a permission denied. hmmm i wasn't aware of this bits. can you work out a 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: apache upgrade cleans modules.conf
On Wed, 8 Sep 2004, Gabor FUNK wrote: Current testing, upg. to apache 1.3.31-5 rendered php4 not working by installing a clear modules.conf over the one which contained a modules.conf with a line: loadmodule php4_module ... Happened on two systems. G. php4 has been broken for a few days. I saw a recent upload of it that should fix this issue. 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 Sat, 4 Sep 2004, Jonathan Ah Kit wrote: Fabio Massimo Di Nitto wrote: 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. Hi Fabio, I suspected this was a built-in module, whatever the jargon is. This workaround you've mentioned seems to have solved it; I checked after a restart and the module still seems to be listed in apache's list. Time to see now if anything breaks. :) This is not really a workaround. In terms that mod_macro.so should have never been there in the first place. 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. Perhaps. I guess now it's a case of trying to figure out who/what the heck installed the file in the first place? That raises a whole bunch of possibilities to me (though apache would be the prime -- though not the only -- suspect for me at this stage). Did you ever compiled apache by yourself? Debian doesn't ship that module since at least 4 years. Fabio PS I am closing the bug in the meanwhile and we can keep the discussion on the mailing list. apache did what it was supposed to do. -- 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
On Tue, 7 Sep 2004, Ian Eure wrote: Is there some definitive resource which documents these effects? I'd like to know what I run the risk of breaking by forcing Apache to use my locale. Check the BTS for archived apache bugs. some of them were reporting problems when LANG != C. I am not sure to recall all the details, but one of the problem was the sequence in which a config directory is scanned, breaking user configuration load sequences. Remember that /etc/init./apache is a config file that you can modify and it will not be overwritten across uploads, until you say so. 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.
Re: Bug#270459: Apache-ssl inetd
severity 270459 minor tag 270459 woody stop On Tue, 7 Sep 2004, LANTek wrote: But if ServerType standalone it's all right how to launch apache-ssl from inetd? apache and inetd are usually a very very bad combination. It is highly unsuggested. Also there are much more recent versions of apache that might fix this problem in sarge/sid. 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#270219: httpd.conf: docs say LoadModule, line is Include
On Mon, 6 Sep 2004, Marc Haber wrote: Package: apache Version: 1.3.29.0.2-5 Severity: minor httpd.conf says: # Please keep this LoadModule: line here, it is needed for installation. Include /etc/apache/modules.conf Shouldn't it say Please keep this Include line here? No. This is correct as it is. It is needed for a certain degree of backward compatibility. 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#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: 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#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: Bug#262582: apache-common: apache-modconf doesn't accept correct syntax. dpkg reported error status 128 when installing libapache-mod-perl
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? Please send me the output. 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#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: 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#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: 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#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: 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#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#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: 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.
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: 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.
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 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#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#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#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: 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#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: Bug#247140: apache: Please fix this soon
It is already fixed in incoming. On Mon, 3 May 2004, Fionn Behrens wrote: Package: apache Version: 1.3.29.0.1-5 Followup-For: Bug #247140 I basically ran into the same problem: trying to install the latest apache, my perl appeared to be too old but installing a new one would mean its too new. So the apache package isnt installable at all. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux rtfm 2.6.5 #5 SMP Fri Apr 9 21:38:15 CEST 2004 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] 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.8Debian configuration management sy ii dpkg1.10.20 Package maintenance system for Deb ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii libdb4.24.2.52-9 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-6 Pluggable Authentication Modules l ii logrotate 3.6.5-1 Log rotation utility ii mime-support3.20-1 MIME files 'mime.types' 'mailcap ii perl [perl5]5.8.0-18 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.
