Re: problem w/ apache 2.2.3 under redhat 5.6 (kernel 2.6.18)
Thank you. I just renamed nss.conf nss.conf.not and that prevented nss from load up. Martin On Tue, Jan 18, 2011 at 4:49 PM, Sander Temme wrote: > On 01/18/11 16:01, martin olivera wrote: > >> >> Good day -- >> > > Hey Martin, > > > We have three Redhat 5.6 servers running Apache 2.2.3. After our last week >> software update (directly from Redhat), the three Apache servers became >> unaccessible from any browser. >> >> A simple "service httpd restart" gives no errors, and we can see the >> daemon >> running. Put the list of processes just shows [httpd] . It >> appears >> to be an SSL/NSS problem. A status check yields: "httpd (pid ...) is >> running >> ...". But the services manages indicates: "httpd dead but subsys locked". >> > > You might consider taking this to us...@httpd.apache.org: maybe someone > there has seen a similar problem. > > mod_nss is not apache.org code: it was done by Red Hat so you should > probably open a ticket with them. > > S. > > > The messages log shows: >> >> SSL Library Error: -8038 SEC_ERROR_NOT_INITIALIZED >> NSS_Initialized failed. Certificate database:/etc/.httpd/alias >> >> The ssl error log says (both are warnings): >> >> RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE >> !? >> RSA server certificate CommonName (CN) 'localhost.local.domain' does NOT >> match server name!? >> >> I've obvioulsy missed creating certificates somewhere. It's the first time >> I >> find errors after an Apache upgrade. I thought the upgrades were >> automatic. >> Nothing else (firewall, httpd.conf) has been changed from the time we had >> apache working w/o problems. Any clue as to how to proceed to fix this >> problem? I don't subscribe to the list, so answers by direct mail is >> preferred. >> >> Thank you, >> >> Martin >> > > > -- > Sander Temmescte...@apache.org > PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A > > View my availability: http://tungle.me/sctemme > > > >
Re: problem w/ apache 2.2.3 under redhat 5.6 (kernel 2.6.18)
On 01/18/11 16:01, martin olivera wrote: Good day -- Hey Martin, We have three Redhat 5.6 servers running Apache 2.2.3. After our last week software update (directly from Redhat), the three Apache servers became unaccessible from any browser. A simple "service httpd restart" gives no errors, and we can see the daemon running. Put the list of processes just shows [httpd] . It appears to be an SSL/NSS problem. A status check yields: "httpd (pid ...) is running ...". But the services manages indicates: "httpd dead but subsys locked". You might consider taking this to us...@httpd.apache.org: maybe someone there has seen a similar problem. mod_nss is not apache.org code: it was done by Red Hat so you should probably open a ticket with them. S. The messages log shows: SSL Library Error: -8038 SEC_ERROR_NOT_INITIALIZED NSS_Initialized failed. Certificate database:/etc/.httpd/alias The ssl error log says (both are warnings): RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !? RSA server certificate CommonName (CN) 'localhost.local.domain' does NOT match server name!? I've obvioulsy missed creating certificates somewhere. It's the first time I find errors after an Apache upgrade. I thought the upgrades were automatic. Nothing else (firewall, httpd.conf) has been changed from the time we had apache working w/o problems. Any clue as to how to proceed to fix this problem? I don't subscribe to the list, so answers by direct mail is preferred. Thank you, Martin -- Sander Temmescte...@apache.org PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme
problem w/ apache 2.2.3 under redhat 5.6 (kernel 2.6.18)
Good day -- We have three Redhat 5.6 servers running Apache 2.2.3. After our last week software update (directly from Redhat), the three Apache servers became unaccessible from any browser. A simple "service httpd restart" gives no errors, and we can see the daemon running. Put the list of processes just shows [httpd] . It appears to be an SSL/NSS problem. A status check yields: "httpd (pid ...) is running ...". But the services manages indicates: "httpd dead but subsys locked". The messages log shows: SSL Library Error: -8038 SEC_ERROR_NOT_INITIALIZED NSS_Initialized failed. Certificate database:/etc/.httpd/alias The ssl error log says (both are warnings): RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !? RSA server certificate CommonName (CN) 'localhost.local.domain' does NOT match server name!? I've obvioulsy missed creating certificates somewhere. It's the first time I find errors after an Apache upgrade. I thought the upgrades were automatic. Nothing else (firewall, httpd.conf) has been changed from the time we had apache working w/o problems. Any clue as to how to proceed to fix this problem? I don't subscribe to the list, so answers by direct mail is preferred. Thank you, Martin
Re: Fwd: util_expr_parce.c
On Tue, 18 Jan 2011, Gregg L\. Smith wrote: Thank you and yes that probably is not a good idea after all, I was unaware of that connection. Your suggestion does work, that removes the linkage warnings. Thanks for testing. Commited as r1060588 Yes _MSC_VER is correct, the compilers do define that and our header file defines; #ifndef _INC_STDLIB #define _INC_STDLIB It seems bison wrongly assumes that stdlib.h always uses _STDLIB_H.
Re: Fwd: util_expr_parce.c
Sorry if this breaks thread, had to subscribe a new address > That is an extremely ugly solution: stdlib.h uses "#ifndef _STDLIB_H" > internally, so this may negatively affect other plattforms or other > source files which include util_expr_private.h. > > From reading util_expr_parse.c, I think something like > > #define YYMALLOC malloc > #define YYFREE free > > in util_expr_private.h could help. Please test this. Maybe it should > be surrounded by some suitable ifdef. Is _MSC_VER the correct ifdef > for visual studio? > > Cheers, > Stefan Hi Stefan, Thank you and yes that probably is not a good idea after all, I was unaware of that connection. Your suggestion does work, that removes the linkage warnings. Yes _MSC_VER is correct, the compilers do define that and our header file defines; #ifndef _INC_STDLIB #define _INC_STDLIB Thanks again, Gregg
Test suite for trunks looks good again
Hi, after yesterdays various small fixes the test suite for trunk again runs flawlessly for me, no failures, no cores. Tested on Solaris 8+10 Sparc, RedHat 5 64 Bits and SuSE Linux Enterprise 10 32 Bits using r1060283. I checked against apr trunk (r1060249) and apr 1.4.2/apu 1.3.10, using dynamically and statically linked modules and running the test suite with default LogLevel (debug) as well as with LogLevel trace8 for MPMs prefork, worker and event (where applicable). Especially I could no longer reproduce the rewrite failures (proxy 502), but since those were sporadically you might want to recheck yourselves. Regards, Rainer
Authentication module sanity check
Hi developers. I have hacked up a new authentication module[1] that will use libcurl to forward all cookies to a specified URL. The URL will validate my normal session cookie and print the matching username. This way, I can reuse my internal session manager to password protect folders (webalizer, munin, etc.) with a simple .htaccess like this: AuthType Cookiecheck AuthCookiecheckUrl http://example.com/cgi/cookiecheck.cgi Require user mya...@example.com and not bother users with the annoying basic auth and an extra password. As I am not used to working with the Apache source code, I would appreciate comments on this approach. I am wary of the implementation details as well as the general idea. [1] http://www.kalibalik.dk/anders/software/mod_auth_cookiecheck/mod_auth_cookiecheck.c Thanks, Anders.
Re: Possible crash in mod_cgid (logging crashes because of NULL s->module_config)
On Tue, 18 Jan 2011, Rainer Jung wrote: I did a broken build using a SHELL_PATH that was not available on the build platform. The test suite tried to log "exec of 'echo pass' failed" in test number 16 of t/modules/include.t (line 261). This produced a crash. It seems the crash will happen every time and exec include fails. The reason is an incomplete server_rec, that has a NULL module_config. Thanks for the analysis. r1060245 should fix it.
