-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, On 10/5/14 10:23 AM, Christopher Schultz wrote: > All, > > On 10/5/14 10:01 AM, Christopher Schultz wrote: >> All, > >> Over the past week, I've had 4 separate httpd servers running 2.2 >> and 2.4 start failing with the generic "Internal Server Error" >> page and a 500 response. > >> The only logs generated are the access log, which of course >> indicates a 500-response. So, no error logs, no syslogs, no >> nothing. > >> We have a couple of redirects configured using something like >> "RedirectMatch 301 "^/$" https://hostname/"; and these are >> processed and I get a 302 response which redirects to another >> page that fails. > >> All of the pages that are failing are using HTTP Basic >> authentication with an LDAPS authentication module >> (mod_authz_ldap) to a remote server. Other httpd instances are >> currently successfully authenticating against this LDAP server, >> so the LDAP server itself doesn't appear to be a problem. > >> In the other cases, an httpd restart has fixed the problem. >> Triggering a config reload (/etc/init.d/httpd reload on my >> RHEL-compatible VM) will allow the configuration to reload and >> does not change the situation with the errors (i.e. the errors >> still occur). > >> I was able to reconfigure the VirtualHost to /not/ require LDAP >> authentication and then I was able to access my pages as >> expected. So, I'm fairly sure that the problem is with the LDAP >> authentication module. > >> I now have another case that is failing and I have the >> opportunity to inspect it in its failing state. Can you anyone >> suggest a way to instrument the still-running, still-failing >> httpd instance to figure out what the problem is? > >> This particular server has the following configuration as >> reported by apachtctl -V: > >> Server version: Apache/2.2.29 (Unix) Server built: Sep 15 2014 >> 19:41:45 Server's Module Magic Number: 20051115:36 Server >> loaded: APR 1.5.0, APR-Util 1.4.1 Compiled using: APR 1.5.0, >> APR-Util 1.4.1 Architecture: 32-bit Server MPM: Prefork >> threaded: no forked: yes (variable process count) > >> Looking at a process list, I can see 8 processes. If I go to my >> browser and mash the RELOAD button, the browser reports a 500 >> response each time, and when I go back and check the process >> list, all the pids are the same, so the child processes are not >> crashing and failing to log errors before the die or anything >> like that. > > I might have a lead on this ... the TLS certificate used by the > LDAP server has expired. But, I have some httpd servers that are > happily using it for authentication (likely due to the server > restart of each one I've had to do). > > Any idea how I might be able to test this hypothesis? I'd prefer > to nail this down and call the problem solved (by issuing a new > certificate) rather than mask the real error if there is another > one. I updated the TLS certificate being used for the LDAP server and it appears to have had no effect on whats going on: I'm still getting 500 errors with no details in any logs. :( Any suggestions? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUMVtXAAoJEBzwKT+lPKRY/o8QAJ9HXA+AE2nFZz5BVJWj6IRK tyIudhUcK/SDDq3T6eELxqkaF8AlHuOGlN5ugbCfJ/+GkUBydD2fD2ofsVvIHpiP q9La4yy029XmhvXmrX4+ncyRY9hKh7BJEak2inUZIOksnNlK9NF14PfnySoH+3jr tkPdi+QMo30d5N25GcWsm8iIGaOuv9dXGz8p7v71TpSTN7PGSC+6mgZWrlSFu0aa 4QKehO/c2lidU5Eqhw1LsIVJ5wQ8SktX4TwNfqCvaXP3w0zjsIxsvrfPA6qQqM85 cBhGBmf3PLoIxFwu0So3PHr9uEbHvcD0MI6Hbst7mN7kHGypCiQCT+IrhvuGhYHN 3sOYWxJxGkBTyg5bpvlvaWX5jt8lfQP+T1ahFgvqTyn+b/77vAoksOXvN/AOvuuD kAsmaKUtKshsTfEYCjUu8FzjKHxoM8EJt00EKaPAgTOcmlS1J1aLgmRSnclY5pLH rxTjhxhW3gOcvVa3J/9ZDOt7K6fX5TI6fLXDG3XiPKa0Fug08SINlB26NB6iA9LX dwGKDxEPpEyqAPdS9Aof1GfqmNr3NVv5sFJ2gJ2wj1Gy5009MLuM4pXktkRHBjPo yOoQx+BRJfCAfV7Z7ErrNgFqUEsnqgrNMVFFL09zLJd6DPh/8VYKhAIqs6rmEP7s oVAQ0S4vm0Mic8H/AmHc =VAwN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|