endless loop trying to create ssl_scache (2.0.54)
Hi, I had just killed off my apache2 and tried to restart it when the following kept apache running at ~100% cpu usage, trying to create the file but failing. Attaching a strace resulted in an endless loop of: stat64(/var/run/apache2/ssl_scache, 0xb8a0) = -1 ENOENT (No such file or directory) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) open(/var/run/apache2/__db.ssl_scache, O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = -1 EEXIST (File exists) Removing the files from /var/run/apache2/ resolved the issue and apache is happily serving again :) Could it be a locking issue? (O_EXCL) IMHO it should simply abort after trying the above for n (say 50?) times and at least log it then. Greets, Jeroen -- related version info: ii apache2-common 2.0.54-4next generation, scalable, extendable web server ii apache2-mpm-prefork 2.0.54-4traditional model for Apache2 ii apache2-utils 2.0.54-4utility programs for webservers ii libapache2-mod-php4 4.3.10-15 server-side, HTML-embedded scripting language (apache 2.0 module) signature.asc Description: This is a digitally signed message part
RE: Spam Using SMTP Over HTTP-Proxy
-BEGIN PGP SIGNED MESSAGE- Joshua Slive [mailto:[EMAIL PROTECTED] wrote: On Thu, 4 Sep 2003, Jeroen Massar wrote: Requiring a IKnowIAmOperatingAOpenProxy flag that needs to be set explicitly would be a better idea then :) That's what the ProxyRequests directive does. Giving it a silly name isn't going to help ;-) True, nothing much we can do about people not reading the docs :( Seriously, we could add a default deny for outgoing port 25 (smtp) and 6660-6670 (irc) proxied connections. This won't really hurt anyone as I don't see any reasons why anybody would want that. A special AllowProxyPorts 25 6660-6670 directive could then turn those ports open too. We could even try to limit it to defaultly allowing only the proxying of port 80 and 443 and denying the rest for instance. Bill Wrowe is a fan of the last idea. I'm neutral about making it the default, but I think it would be good to make it configurable. You should be specific here, however. We are talking about a directive that would allow *outgoing* proxy connections only on specific ports. For example AllowForwardProxy 80 8080 That could be the default then, if people would require other ports they would either need to add them or specify All if they are really sure of what they are doing. We should also convince packagers that they never include the All option per default or as a simple configuration option. If someone wants it, let them read the doc, which should contain the you are opening up as an open relay warning. Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP1hHximqKFIzPnwjEQK6VgCfSJkykyhb+jvWp/ShzWrDcflhFxgAn26c RKAczDl/QqHK5kk8w8Mcvtqb =NT/J -END PGP SIGNATURE-
RE: Spam Using SMTP Over HTTP-Proxy
-BEGIN PGP SIGNED MESSAGE- Joshua Slive [mailto:[EMAIL PROTECTED] wrote: I don't think that is feasible. There are MANY ways to do access control in apache. Sending a message along the lines of Your server is configured to proxy requests to arbitrary servers. whenever ProxyRequests is On would be a possibility. That would indeed help, but how many redhat/debian/... read the logs when it works ? Requiring a IKnowIAmOperatingAOpenProxy flag that needs to be set explicitly would be a better idea then :) Seriously, we could add a default deny for outgoing port 25 (smtp) and 6660-6670 (irc) proxied connections. This won't really hurt anyone as I don't see any reasons why anybody would want that. A special AllowProxyPorts 25 6660-6670 directive could then turn those ports open too. We could even try to limit it to defaultly allowing only the proxying of port 80 and 443 and denying the rest for instance. Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP1ePfCmqKFIzPnwjEQKGWACffesaa690wCAFBWKxF4ae7IjeICIAn1e5 9dvAvWU3n9iGcLFTeiYxuphu =Aj1Q -END PGP SIGNATURE-
RE: Fw: Spam postings via Apache to postfix on the same host
André Malo [mailto:[EMAIL PROTECTED] wrote: * Joshua Slive wrote: [spam via proxy] One possible thing we could do is simply remove the sample proxy config from our default httpd.conf. These samples make it too easy for people to activate a proxy without securing it properly. +1! Since proxying is not the primary purpose of the httpd I won't miss it in the default config (commented or not). Possibly a 'go look in the docs' type question. But for instance: From the docs: 8- NoProxy Directive This directive is only useful for Apache proxy servers within intranets. The NoProxy directive specifies a list of subnets, IP addresses, hosts and/or domains, separated by spaces. A request to a host which matches one or more of these is always served directly, without forwarding to the configured ProxyRemote proxy server(s). -8 In that the sentence: A request to a host which matches one or more of these is always served directly NoProxy 2001:db8::/32 www.example.com 2001:db8::1 Is a bit dubious, at least for me. It could mean two things: - GET http://www.example.com/ HTTP/1.1 Would be served 'directly' (from cache, from how?) - A client from 2001:db8::/32 sending GET http://www.example.com/ HTTP/1.1 will be served 'directly'. It could be my english understanding ofcourse, but if somebody would like to enlighten me ;) Then there is also: Proxy * Order Deny,Allow Deny from all Allow from 192.168.0 /Proxy But that is for _client's_. We could have something similar with destination's. Which could also be usefull for spam-ad blocking etc: Proxy * Order Allow,Deny Allow to all Deny to example.com Deny to 2001:db8::/32 Deny to ::1 Deny to 127.0.0.1 Deny to port 25 /Proxy Having that would be perfect ofcourse. Next in from the document is the AllowCONNECT Directive. Maybe at least a AllowProxyPort would be helpful, somewhat like the above ? Greets, Jeroen
RE: [ANNOUNCE] Apache 2.0.44 Released
Sander Striker [mailto:[EMAIL PROTECTED]] wrote: First, congrats with 2.0.44 ;) *) Introduce the EnableSendfile directive, allowing users of NFS shares to disable sendfile mechanics when they either fail outright or provide intermitantly corrupted data. PR [William Rowe] Shouldn't this also be noted as the fix for: IPv6 enabled version doesn't output any data on some NIC's and linux As mentioned in the following threads: http://groups.yahoo.com/group/new-httpd/message/41447 http://groups.yahoo.com/group/new-httpd/message/41485 The general fix with 2.0.43 was to use --disable-sendfile too. This option is thus also meant for Linux users who have a NIC which behaves strange when sendfile() is enabled along with IPv6. Also I can't find any mention of it in the docs (http://httpd.apache.org/docs-2.0/) Greets, Jeroen
RE: Linux + TCP_CORK + IPv6 = Broken [PATCH]
Colm MacCárthaigh [mailto:[EMAIL PROTECTED]] wrote: On Thu, Dec 05, 2002 at 12:58:48PM +, Colm MacCárthaigh wrote: I'm using vanilla 2.4.18, from Debian kernel-source-2.4.18 , one machine has the broadcom bcm5700 module, and the the other has the intel e1000 module. O.k., more testing, I've tried it out on another box, which has a 3com network card and IDE disks, and it *doesnt* happen there. Things the vulnerable machines have in common: SCSI hard-disks Software RAID 1 set-up GigE cards (bcm5700 , e1000) Dell (2650, and 1650) Things unaffected machine has: IDE disks no RAID 3c905 network card. I just recompiled the debian's 2.0.43 with --without-sendfile (push it in the args list of debian/rules) and now www.sixxs.net works fully on IPv4/IPv6 and IPv4-SSL and IPv6-SSL. As for the hardware in that box, Linux 2.4.18, Celeron, IDE, ext3 fs's and a: eth0: RealTek RTL8139 Fast Ethernet at 0xd080, 00:10:dc:20:7c:7c, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139B' purgatory.unfix.org has 2.4.18, p100, IDE, ext3 and a Intel and DEC, but IPv6 is tunneled and doesn't have that problem. games.concepts.nl box has 2.4.19-pre5-ac3, Athlon, SCSI, ext3 and a 3c905C, this one doesn't have any problems. I'll be running that first box with --without-sendfile :) If you need extra informations don't mind to speak up. Greets, Jeroen
RE: Linux + TCP_CORK + IPv6 = Broken
Colm MacCarthaigh [mailto:[EMAIL PROTECTED]] wrote: On Mon, Dec 02, 2002 at 02:48:53PM -0500, Jeff Trawick wrote: Colm MacCarthaigh [EMAIL PROTECTED] writes: Linux (2.4.18 and 2.4.19, for me anyway) with apache versions 2.0.40 to 2.0.43 (that I've tested anyways) is broken with TCP_CORK and IPv6. Bizarrely v6 requests will work the first few times and then start failing, typically you just wont get a response from the server. Though strace shows that it did try to send one. Another 'fun' thing: - Linux 2.4.18 - Apache 2.0.43 (preforked) - Debian unstable http://www.sixxs.net - IPv4 works - IPv6 doesn't work https://www.sixxs.net - IPv4 works - IPv6 works So I have currently installed a default reroute on http://www.sixxs.net for IPv6 requests to redirect them to the https:// variant. Try http://www.ipv6.sixxs.net/news/ for example to not get redirected (only a IPv6 non-ssl / request redirs). btw www.ipv4.sixxs.net has only A, www.ipv6.sixxs.net has only . The IPv6 doesn't work actually means: request comes in, answer comes out partially. A first request gets returned correctly any pipelined request coming in next fail. That's why the / works (as it's only 1 answer, not pipelined) some other pages without pictures show this too. Odd that IPv4 and SSL'd IPv4/IPv6 do work. Another thing is that I do got it working on other boxes with 2.4.18 :) Same build of apache on those, other NIC's though: 2.4.18 - purgatory.unfix.org (HTTP and HTTPS IPv4 and IPv6 ofcourse) 2.4.19-pre5-ac3 - games.concepts.nl (HTTP IPv4 and IPv6) Oddness all around, but maybe that problem is related? Greets, Jeroen
RE: new download page
Joshua Slive [mailto:joshua;slive.ca] wrote: Pier Fumagalli wrote: I looked into it back in the days, but the only way would be to go down to RIPE (IANA in the US) to see where that IP is coming from, doing some weirdo WHOIS parsing and stuff... _WAY_ overkilling... Anyhow this is going waaay offtopic! :-) See: http://maxmind.com/geoip/ If someone wants a little project, it shouldn't be too hard to integrate this into the existing closer.cgi script. Being geographically close says nothing about the connection. If you really want to autodirect users to a certain mirror you could do this based on AS number. This is for example done by the folks at scene.org. Contact [EMAIL PROTECTED] if you want to know more about this solution. A easy fix for the Sourceforge syndrome grin would be : a href=http://www.apache.org/dyn/closer.cgi/httpd/httpd-2.0.43.tar.gzdes c=this-points-to-a-html-with-mirrors-do-not-wget-this-urlhttpd-2.0.43. tar.gz/a Et tada people wanting to use wget, of which I am one, would notice that it is not a direct link to the file, you won't need changes to the closer.cgi as it should ignore the second param (desc). Now you can put back that cool download page which was much better than the current and old one. At least thats my opinion. Greets, Jeroen
RE: [ANNOUNCE] Apache 2.0.40 Released
Sander Striker [mailto:[EMAIL PROTECTED]] wrote: SNIP We have also included support for IPv6 on any platform that supports IPv6. Hmmm Windows NT/2k/XP/.Net/98/95 supports IPv6, now where is the IPv6 capable binary (or source for that matter ;) ? (Btw... Mac OS X sports IPv6 also in beta's and public in the coming september updates) Greets, Jeroen
RE: Auth - what should happen
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: Opinions - not on what happens to day in 1.3 but what should happen in a perfect world: Given a config like this: Directory /my/secrets AuthTypebasic AuthNameRestricted area /Directory What should happen ? Allowed in with, or without a password ? What would users feel as most logical ? They want it to be open probably, unless you got security savvy types, they want it closed. In order words: Default Policy Closed If it doesn't serve content people will notice, people will complain, people will fix. If it by default serves content, it could be content that people didn't want to serve at all. Then Directory /my/secrets AuthTypebasic AuthNameRestricted area Limit POST require valid-user /Limit /Directory Same here when using a GET. (Note - I've not even started with 'allow from' or 'satisfy any complexity). Maybe introduce a LimitPolicy Deny But we got Order deny,allow for that. If we take into consideration that Order defaults to deny,allow one would end up: - Allowing POST to valid-user. - Denying anything else. Greets, Jeroen
RE: [PATCH] Apache2 httpd.conf
Günter Knauf [mailto:[EMAIL PROTECTED]] wrote: unfortunately we have symlinks only on *nix platforms, so for all other platforms this isnt a solution... Guenter. Unices all? have symlinks and NT supports lins too. Then still people could instead of symlinking the data copy the configs in and out of the enabled dir. On debian they got the two simple commands for that, apachectl could be made to do it to. Greets, Jeroen Better do the configs the 'debian way' then: /etc/apache2/ containing: apache2.conf : default config for running Apache2 minimally. ports.conf : Port 443 etc directives httpd.conf : local site extra's modules-available/ : containing a config file per module modules-enabled/ : containing symlinks to the modules-available directory Now if you want a module enabled; you can symlink it, easy and obvious configging for everybody ;) The apache2.conf includes the ports.conf + httpd.conf + modules-available ofcourse. As for packagers, let your apache module depend on the main apache package and install your module's config into the available dir, then _ask_ the user if they want it enabled at once.
RE: [PATCH] Apache2 httpd.conf
Günter Knauf [mailto:[EMAIL PROTECTED]] wrote: Ahhh, but you forget that not everyone uses DSO modules. Many people compile the modules into the server, and for them the module is active regardless of the LoadModule line. Ok, that was the point I missed and convinces me that it's not such a good idea then... then let's make another suggestion: let's create a modules.conf and move these configs into it, and perhaps also the mod_deflate config; then this conf can easily be included from the httpd.conf, and httpd.conf becomes simpler... Better do the configs the 'debian way' then: /etc/apache2/ containing: apache2.conf : default config for running Apache2 minimally. ports.conf : Port 443 etc directives httpd.conf : local site extra's modules-available/ : containing a config file per module modules-enabled/ : containing symlinks to the modules-available directory Now if you want a module enabled; you can symlink it, easy and obvious configging for everybody ;) The apache2.conf includes the ports.conf + httpd.conf + modules-available ofcourse. As for packagers, let your apache module depend on the main apache package and install your module's config into the available dir, then _ask_ the user if they want it enabled at once. Greets, Jeroen
RE: is httpd a valid way to start Apache?
Jeff Trawick wrote: Who would be in favor of this, or parts thereof? I'm anxious to see a consensus so that steps toward the goal can be filled in over time. 1) httpd can't be used directly on Unix because of environment variable settings SNIP Due to inheritance (export) of environment variables I usually start Apache after doing a: # for i in `export | cut -f3 -d' '|cut -f1 -d'='`; do export -n $i; done Which cleans them all up nicely. One reason for doing this is so that phpinfo() shows all these nice Enviroment variables which could reveal one thing or the other of some persons setup. Maybe it's an idea to let the 'startup' program (may it be httpd or apachectl) to filter these environment variables too ? they also take up memory, oooh ah :) Greets, Jeroen
RE: PHP and other security problems - a solution idea
[EMAIL PROTECTED] wrote: Idea: On handling a file, setuid() to owner of file. On closing connection, re-engage original uid (nobody, apache, www-data, whatever it is). PHP will run under user's UID, other users are save. The 'solution' is the perchild MPM ;) Or a dirty hack; run apache as root and let it change uid based on the url's owner or something like: Directory /www/www.example.org/user/test/ User test Group users /Directory Something like that would be quite nice too, perhost MPM only will be able to do per-vhost uid-changes. With some patches (which haven't been accepted yet) perchild will actually compile, run and work. Though the user-changes can't be made effective yet :( But that will be some of the things for next week ;) Greets, Jeroen
Re: Apache 2.0.32 beta is available
On Mon, 18 Feb 2002, Bill Stoddard wrote: On Sun, 17 Feb 2002, Justin Erenkrantz wrote: SNIP SNIP Unless someone submitted patches since the 2.0.32-alpha tarball last week. I don't think Win32/nt works especially as it relies on sockaddr_in for the mpm_winnt. I figured and fixed this, this weekend when I wanted too see if the IPv6 support for Apache on NT worked or not. It did compile but without IPv6 support. After some hours of changing things, enabling getaddrinfo() etc. I suddenly had a IPv6 enabled mpm_winnt version of Apache 2.0.32. I will be cleaning up the diff tonight and fixing the fact that IPv6 addresses get logged quite weirdly, which is a weird offset effect. You'll probably get the diff tomorrow morning CET ;) Cool! Thanks, will be looking for the patch. Bill I haven't made a proper diff, nor the cleanups, but if you copy the files from: http://calvin.ics.hro.nl/~jeroen/apache2/apache_2.0.32-winnt-ipv6.zip And extract them on top of the apache 2.0.32 alpha/beta tarball and compile it should work. This _does_ however require the IPv6 headers supplied by either the platform preview (http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp) and or the newer SDK's. Simply build with the InstallBin targets etc and it should all work out fine. The newer IPv6 stacks by MS automatically detect IPv6 presence and use it if possible. This allows for a IPv6 enabled build which should be able to run on most NT's. I say NT's here as the IPv6 stack for 9x/ME is unknown untested for me. Things I have to do to clean it up: - fix the address copying (save_addrinfo goes wrong on me) - put in many #ifdef APR_HAVE_IPV6 lines. - get rid of the debug stuff :) You'll notice that the winnt_mpm now passes the listen_rec to winnt_accept() This was the cleanest way in my opinion for it to get the address family. There is also some weird magic, sockaddr_in6 is normally 24 bytes, but when returned from getaddrinfo() it's always 28 hmm ;) I'll probably have a stab on this tomorrow and pass in a diff to you guys ;) If I am really lucky I will have my adsl line back tomorrow, carrying printed code and using floppydisks isn't fun ;)... I got the sync.. now they have to turn on provisioning... Greets, Jeroen
Re: Apache 2.0.32 beta is available
On Sun, 17 Feb 2002, Justin Erenkrantz wrote: SNIP Apache 2.0 offers numerous enhancements, improvements and performance boosts over the 1.3 codebase. The most visible and noteworthy addition is the ability to run Apache in a hybrid thread/process mode on any platform that supports both threads and processes. This has been shown to improve the scalability of the Apache HTTPD server significantly on some versions of Unix in our testing. Apache 2.0 also includes support for filtered I/O. This allows modules to modify the output of other modules before it is sent to the client. Finally, we have included support for IPv6 on any platform that supports IPv6. Unless someone submitted patches since the 2.0.32-alpha tarball last week. I don't think Win32/nt works especially as it relies on sockaddr_in for the mpm_winnt. I figured and fixed this, this weekend when I wanted too see if the IPv6 support for Apache on NT worked or not. It did compile but without IPv6 support. After some hours of changing things, enabling getaddrinfo() etc. I suddenly had a IPv6 enabled mpm_winnt version of Apache 2.0.32. I will be cleaning up the diff tonight and fixing the fact that IPv6 addresses get logged quite weirdly, which is a weird offset effect. You'll probably get the diff tomorrow morning CET ;) Greets, Jeroen PS: What makes this so cool is the fact that IIS doesn't have IPv6 support (yet, unless someone has a superduper development version somewhere ;)
[patch] per-child (Re: 2.0.32 has been released.)
On Thu, 14 Feb 2002, Bill Stoddard wrote:
From testing on Windows, I am +1 for beta.
First I noticed that the KEYS file is missing from the tar file.
Second perchild doesn't compile, but see attached mpm_perchild.patch for the fix ;)
It basically does a int num_sockets and add the POD definition and static.
It doesn't work then though at least it works unless I specify the
following things:
8
ChildperUserID 33 33 1
ChildperUserID 1004 1004 2
8
Numberic... otherwise it will b*tch
And per vhost:
8
AssignUserID 1004 1004
8
One vhost is using 1004 (wwwics) user, the others use the 33 (www-data) user which is
the default.
It does start up nicely and I think it's accepting the connection at the
right client, this shows up as 'top' shows the process taking the rest of
the cputime and it does have the correct user I picked for that vhost.
But where/what it's cycling at, dunno yet ;)
Also a nice error seen in my logs while fooling around with the above settings:
[Thu Feb 14 14:39:57 2002] [alert] (2)No such file or directory: getpwuid: couldn't
determine user name from uid 4294967295, you probably need to modify the User directive
Aka uid == 0x == -1 (32bits).
Firing up my apache now makes:
1x apache2 running as root
22x www-data (uid=33)
14x wwwics (uid=1004)
www-data is also the user used in the User option.
Perchild config:
IfModule perchild.c
NumServers 5
StartThreads 5
MinSpareThreads 5
MaxSpareThreads 10
MaxThreadsPerChild 20
MaxRequestsPerChild 0
/IfModule
Running it without the AssignUserID and ChildperUserID settings gives me
38x apache2 running as www-data ;)
The php/cgi-script thing was caused because of a missing mod_cgid by the way ;)
Greets,
Jeroen
diff -u -r -N httpd-2.0.32/server/mpm/perchild/mpm.h
../2.0.32-perchild/build-tree/httpd-2.0.32/server/mpm/perchild/mpm.h
--- httpd-2.0.32/server/mpm/perchild/mpm.h Wed Dec 19 18:50:38 2001
+++ ../2.0.32-perchild/build-tree/httpd-2.0.32/server/mpm/perchild/mpm.hThu
+Feb 14 13:43:07 2002
@@ -77,6 +77,7 @@
#define AP_MPM_WANT_SET_COREDUMPDIR
#define AP_MPM_WANT_SET_ACCEPT_LOCK_MECH
+#define AP_MPM_USES_POD 1
#define MPM_SYNC_CHILD_TABLE()
#define MPM_CHILD_PID(i) (ap_scoreboard_image-parent[i].pid)
#define MPM_NOTE_CHILD_KILLED(i) (MPM_CHILD_PID(i) = 0)
diff -u -r -N httpd-2.0.32/server/mpm/perchild/perchild.c
../2.0.32-perchild/build-tree/httpd-2.0.32/server/mpm/perchild/perchild.c
--- httpd-2.0.32/server/mpm/perchild/perchild.c Tue Feb 5 23:18:49 2002
+++ ../2.0.32-perchild/build-tree/httpd-2.0.32/server/mpm/perchild/perchild.c Thu
+Feb 14 13:42:30 2002
@@ -78,7 +78,7 @@
#endif
#define CORE_PRIVATE
-
+
#include ap_config.h
#include httpd.h
#include http_main.h
@@ -107,6 +107,9 @@
#include sys/processor.h /* for bindprocessor() */
#endif
+#include ap_mmn.h
+
+
/*
* Define some magic numbers that we use for the state of the incomming
* request. These must be 0 so they don't collide with a file descriptor.
@@ -175,6 +178,8 @@
static int num_listenfds = 0;
static apr_socket_t **listenfds;
static jmp_buf jmpbuffer;
+static ap_pod_t *pod;
+
struct child_info_t {
uid_t uid;
@@ -1429,6 +1434,7 @@
static int perchild_open_logs(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp,
server_rec *s)
{
apr_status_t rv;
+int num_listensocks;
pconf = p;
ap_server_conf = s;
Apache 20020213 anonCVS perchild
I compiled a 20020213 httpd anoncvs today to try the perchild module. And I think that: 8- Out of Memory: Killed process 4768 (apache2). Out of Memory: Killed process 4774 (apache2). Out of Memory: Killed process 4775 (apache2). Out of Memory: Killed process 4783 (apache2). Out of Memory: Killed process 4790 (apache2). Out of Memory: Killed process 4791 (apache2). Out of Memory: Killed process 4798 (apache2). -8 Kinda show that it's not entirely okay on my machine ;) I also tried the 2.0.28-beta which is found on the distribution site. The system is a mere p3 750 with 128mb running linux 2.5.1 Linux calvin 2.5.1 #1 Mon Jan 14 15:08:00 CET 2002 i686 unknown The effect seen is that mozilla (nope not only apache is bad ;) 8--- Out of Memory: Killed process 4713 (mozilla-bin-cvs). Out of Memory: Killed process 4728 (mozilla-bin-cvs). Out of Memory: Killed process 4729 (mozilla-bin-cvs). Out of Memory: Killed process 4730 (mozilla-bin-cvs). Out of Memory: Killed process 4731 (mozilla-bin-cvs). ---8 At least something is filling the memory ;) Well it's apache aparently because a simple: root@calvin:/home/staff/jeroen/data/apache2/deb/2.0.28-perchild/apache2-2.0.28# telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / HTTP/1.1 Host: calvin.ics.hro.nl ^]q telnet Connection closed. Wellps that makes apache2 go rogue too and no response ;( The configlines which when removed make it work, but when added make it break: ChildperUserID wwwics wwwics 1 and in one of the 3 vhosts: AssignUserID wwwics wwwics (little background, the idea is to secure every vhost so that it runs under a seperate user and that there is no way that some random user reads the cleartext passwords for databases etc through something like a php. Every vhost will be seperate... ) The host: http://calvin.ics.hro.nl Server Info at http://calvin.ics.hro.nl/server-info Server Stats at http://calvin.ics.hro.nl/server-status Currently running without assignuserid and childperuserid, otherwise it simply doesn't respond :( The debian tag is because I built it using the debian build rules: The configure options: AP2_CONFARGS = --enable-layout=Debian --enable-so \ --with-program-name=apache2 --enable-speling=shared \ --enable-rewrite=shared --enable-cgid=shared \ --enable-vhost-alias=shared --enable-info=shared \ --enable-suexec=shared --enable-ssl=shared \ --enable-unique-id=shared --enable-usertrack=shared \ --enable-expires=shared --enable-cern-meta=shared \ --enable-mime-magic=shared --enable-headers=shared \ --enable-auth-anon=shared --enable-proxy=shared \ --enable-dav=shared --with-suexec-caller=www-data --with-suexec-docroot=/www --with-suexec-logfile=/var/log/apache2/ \ --with-mpm=perchild Something else broke the php handling through a cgi using the trick: Action application/x-httpd-php /cgi-bin/php4 Which results in a: [Wed Feb 13 16:37:56 2002] [warn] [client 145.24.239.47] handler cgi-script not found for: /usr/lib/cgi-bin/php4 Every query but that's prolly something different and not related to mpm_perchild If somebody can give me some clue... I welcome it ;) Greets, Jeroen
OpenSSL 0.9.6 (Was: RE: ssl is broken)
Boo, First I'll twack myself for the fact that I didn't look at the openssl version any sooner... This is prolly at least one nice for the archives for other donkeys hitting their heads against this brick... I wanted a newer version than the 2.0.16 beta's to experiment some more with Apache 2.0.. so I pulled down http://dev.apache.org/dist/httpd-2_0_25-alpha.tar.gz and tried to compile it with --enable-ssl --with-openssl=/usr/include/openssl/ and such on a almost standard FreeBSD 4.2 box which comes with the old OpenSSL 0.9.5a, ./configure etc go just fine untill the make pops up the following error: 8--- modules/ssl/.libs/mod_ssl.al(ssl_engine_kernel.lo): In function `bio_hook_set': /usr/home/www/compile/httpd-2_0_25/modules/ssl/ssl_engine_kernel.c:264: undefined reference to `BIO_next' ---8 And after some more tries and peeking at google I finally noticed that my old OpenSSL version (twack me :) Also http://www.openssl.org/docs/crypto/BIO_find_type.html nicely states: 8-- NOTES BIO_next() was added to OpenSSL 0.9.6 to provide a 'clean' way to traverse a BIO chain or find multiple matches using BIO_find_type(). Previous versions had to use: next = bio-next_bio; --8 Then added the following after the #include openssl/ssl.h in modules/ssl/ssl_engine_kernel.c: 8 #ifndef BIO_next #define BIO_next(b) b-next_bio; #endif --8 Ran another make. et tada it compiled :) I'd better upgrade my OpenSSL sooner or later though :) [03/Oct/2001 01:37:59 91292] [info] Connection: Client IP: 3ffe:8114:2000:240:2d0:b7ff:fe8f:5d42, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits) But it works ;) Next-stop... stability tests mod_proxy grin Greets, Jeroen
