Re: Re: insserv + apache2 + bind9 = pain
The rcN.d format is an excellent design if we can just keep insserv from mangling it. As I haven't converted one of my systems to dependency based boot yet, there still has to be some way to keep the old way. No idea why there is no documented way to switch that on... It could be that touch /etc/init.d/.legacy-bootordering dpkg-reconfigure -plow sysv-rc does the trick, but I haven't tried it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101022259.01710...@sfritsch.de
Re: questions about shishi problem while using apache with etch
In trying to create some new web stuff, apache seems to be complaining about shishi (which I see from research is the gnu kerberos stuff). Why is it doing this? I know I could just create the directory, but I want to understand WHAT it is trying to do and WHY. Port 12345 is one of my apache ports telnet localhost 12345 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. libshishi: warning: /home/dan/.shishi/tickets: No such file or directory It also seems to me to be an apache error to have something come out on stderr. Why do you think that this is apache? This is probably a kerberos enabled telnet that is giving the warning. Try using a different telnet· Cheers, Stefan
Re: Apache2 is serving php files it does not own
debian-apache is not a support list, CCing to debian-user On Monday 08 January 2007 19:50, Virgil E. Alderson wrote: After an update apache2 all of a sudden is serving php files it does not own or have rights to read or write to. Up to this point i have had my files owned by user: root and group: www-data, and all i had to do was remove group rw rights on the file for apache2 not to serve the php file. But all of sudden apache is serving the file regardles of who owns it and with 000 permissions. I tried a test with a .png file in the same directory and that works fine, removing -r from its group www-data denies access to it. Doing a ps -ef shows that apache is running as www-data, i also consoled in as www-data and tried to cat the php file and I do get denied as expected. Any ideas? I am using etch and apache 2 with php5 Maybe the pages are still cached in your browser or your proxy. Try reloading / clearing the cache / disabling the proxy. Cheers, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Apache2 is serving php files it does not own
On Monday 08 January 2007 22:42, Virgil E. Alderson wrote: I had already looked into my cache, and that is not it. as a test I have put a rule in my directory entry so that it will only allow to serve test.php on localhost and that stops it from showing it on a external computer. So its not the cache, and I do not run a proxy. I can't quite believe that. If you do a request for a file with mode 000, does it appear in the access log? Do you use special php modules that cache the compiled scripts? Do you use fastcgi? If the answers are yes, no, no, respectively, you can try: /etc/init.d/apache2 stop strace -f -o /tmp/strace.out /etc/init.d/apache2 start do a single request, then from a different shell (replace test.php in the second line with the script you requested): /etc/init.d/apache2 stop egrep 'open.*test.php|set.*uid' /tmp/strace.out There should now be a ... open(.../test.php) = ... line near the bottom. What is it exactly? What is the number ## in the setuid32(##) lines? Cheers, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#391290: apache should automatically detect extra periods/commas at the end of URLs and fix
On Friday 06 October 2006 00:32, Jason Spiro wrote: This can be done with mod_speling or with something like RewriteRule ^(.*)[,.]$ $1 [R] though the latter will prevent you from requesting any file ending with period or comma. With some more refined rewrite magic using subrequests, you can probably avoid that. However, by default Apache should return exactly what was requested. Therefore I close this bug. Why shouldn't Apache ship with a RewriteRule to correct such a common error by default? It's very uncommon for webmasters to post files whose names end with a period or comma anyway. Several reasons: - if you don't know that the rule is active, it would lead to quite unexpected and hard to debug behaviour (who knows what kind of URLs are used by some webapp...) - you don't want to have mod_rewrite active by default (there have been security issues that only affect mod_rewrite) - mod_speling does quite a bit more, so you don't want to have that active by default either Cheers, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
