Hi, after some more playing, I will take this of the Tomcat users list. I was able to reproduce the same problem with the previous setup:
Server Version: Apache/2.4.18 (Unix) OpenSSL/1.0.2g mod_jk/1.2.41 It seems to take a bit longer to reproduce, but it happens with the same traces in the logs. [Thu Dec 29 15:55:31.128662 2016] [authnz_ldap:debug] [pid 24939:tid 139865530685184] mod_authnz_ldap.c(516): [client 160.46.222.183:52181] AH01691: auth_ldap authenticate: using URL ldaps://##########:6362/dc=########,dc=com?uid ldap_search_ext put_filter: "(&(objectclass=*)(uid=######))" put_filter: AND put_filter_list "(objectclass=*)(uid=#######)" put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" put_filter: "(uid=#######)" put_filter: simple put_simple_filter: "uid=########" ldap_build_search_req ATTRS: uid ldap_send_initial_request ldap_send_server_request ldap_result ld 0x84f940 msgid 6 wait4msg ld 0x84f940 msgid 6 (timeout 60000000 usec) wait4msg continue ld 0x84f940 msgid 6 all 1 ** ld 0x84f940 Connections: * host:###########t port: 6362 (default) refcnt: 2 status: Connected last used: Thu Dec 29 15:55:31 2016 ** ld 0x84f940 Outstanding Requests: * msgid 6, origid 6, status InProgress outstanding referrals 0, parent count 0 ld 0x84f940 request count 1 (abandoned 0) ** ld 0x84f940 Response Queue: Empty ld 0x84f940 response count 0 ldap_chkResponseList ld 0x84f940 msgid 6 all 1 ldap_chkResponseList returns ld 0x84f940 NULL ldap_int_select read1msg: ld 0x84f940 msgid 6 all 1 read1msg: ld 0x84f940 msgid 0 message type extended-result ldap_chase_referrals read1msg: V2 referral chased, mark request completed, id = 0 read1msg: ld 0x84f940 0 new referrals read1msg: mark request completed, ld 0x84f940 msgid 0 request done: ld 0x84f940 msgid 0 res_errno: 11, res_error: <This connection has been terminated because it has remained idle for too long>, res_matched: <> ldap_err2string [Thu Dec 29 15:55:31.129230 2016] [authnz_ldap:info] [pid 24939:tid 139865530685184] [client #########:52181] AH01695: auth_ldap authenticate: user ######## authentication failed; URI /jkmanager [ldap_search_ext_s() for user failed][Administrative limit exceeded] Interesting is the LDAP debug blurb about "connection has been idle for too long". Maybe we are seeing an infrastructure problem here. I will raise an issue with the responsible IT group. Thats fun :-( Thanks for the patience and a "Happy and Peaceful New Year 2017" Martin On Thu, Dec 29, 2016 at 12:36 PM, André Warnier (tomcat) <a...@ice-sa.com> wrote: > On 29.12.2016 10:46, Martin Knoblauch wrote: > >> Hi, >> >> "mod_jk" is now clearly off the hook. Upping the httpd log level from >> "warn" to "info" (I was assuming an event leading to a 500 response would >> be at least "warn" :-( reveals: >> >> [Thu Dec 29 10:37:37.300421 2016] [authnz_ldap:info] [pid 20325:tid >> 139641195009792] [client xxx.xxx.xxx.xxx:49959] AH01695: auth_ldap >> authenticate: user yyyyyyy authentication failed; URI /jkmanager >> [ldap_search_ext_s() for user failed][Administrative limit exceeded] >> >> @Christopher: thanks for the LDAP hint !!! >> >> > Perhaps also if you did not already know this : httpd 2.4 allows for > setting the LogLevel on a per-module base, see here : > https://httpd.apache.org/docs/2.4/logs.html -> Per-module logging > > > > Cheers >> Martin >> >> >> >> On Thu, Dec 29, 2016 at 10:02 AM, André Warnier (tomcat) <a...@ice-sa.com> >> wrote: >> >> On 29.12.2016 09:47, Martin Knoblauch wrote: >>> >>> Hi Christopher, >>>> >>>> that is an interesting pointer. We are of course securing the >>>> "jkmanager" >>>> app. And guess what we are using: LDAP. The funky thing is that it is >>>> working most of the time. It fails just after some time. Refreshing the >>>> URL >>>> cures it again - for some time. What did you do to fix your problem? >>>> >>>> As I mentioned elsewhere, setting "JkLogLevel debug" just filled the >>>> log >>>> without anything suspicious showing up. I can see "jkmanager" fire/work >>>> every 10 seconds (autorefresh), returning a 200 status. And then it >>>> nothing >>>> until I refresh the URL.So it seems the problem is elsewhere, before >>>> "mod_jk" come into play. >>>> >>>> >>> So setting JkLogLevel higher was far from useless : at least it tells you >>> where the problem isn't. >>> >>> "How often have I said to you that when you have eliminated the >>> impossible, whatever remains, however improbable, must be the truth?" >>> >>> Sherlock Holmes - The Sign of the Four >>> >>> >>> >>> >>> I will now try to investigate towards "mod_ldap" and maybe towards the >>>> OpenSSL stuff (we use LDAP over SSL). Fortunately rolling back versions >>>> is >>>> simple. >>>> >>>> As for being current, as far as I know we are up2date: >>>> >>>> ==> Server Version: Apache/2.4.23 (Unix) OpenSSL/1.0.2j mod_jk/1.2.42 >>>> >>>> Thanks >>>> Martin >>>> >>>> >>>> On Wed, Dec 28, 2016 at 9:43 PM, Christopher Schultz < >>>> ch...@christopherschultz.net> wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> >>>>> Hash: SHA256 >>>>> >>>>> Martin, >>>>> >>>>> On 12/28/16 10:38 AM, Martin Knoblauch wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> today we updated our Devel/Integration environments from >>>>>> >>>>>> HTTPD 2.4.18/mod_jk 1.2.41/OpenSSL-1.0.2h >>>>>> >>>>>> to >>>>>> >>>>>> HTTPD 2.4.23/mod_jk 1.2.42/OpenSSL-1.0.2j >>>>>> >>>>>> >>>>>> Since then we observe on both systems spurious "500" messages when >>>>>> accessing the "jkmanager" page. Unfortunately there isn't much info >>>>>> besides that. Only "access_log" shows >>>>>> >>>>>> access_log:xxx.xxx.xxx.xxx - xxxxxxxx [28/Dec/2016:16:29:18 +0100] >>>>>> "GET /jkmanager HTTP/1.1" 500 536 >>>>>> >>>>>> Any ideas how to get more insight >>>>>> >>>>>> >>>>> I had a problem a while back where I would get 500 responses and >>>>> *nothing* else back. It took a lot of tinkering-around to figure out >>>>> the problem: my LDAP server wasn't acceptable for some reason and >>>>> mod_auth_ldap was choking. >>>>> >>>>> I spent all my time trying to figure out what was wrong with mod_jk >>>>> and it was the authentication layer way before mod_jk was being >>>>> consulte >>>>> d. >>>>> >>>>> If you require authorization for jkmanager (and you should!) make sure >>>>> that's working as expected before banging your head against mod_jk. >>>>> >>>>> Also, make sure you are using the latest mod_jk that you can: the >>>>> distribution is separate from httpd. >>>>> >>>>> - -chris >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Comment: GPGTools - http://gpgtools.org >>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>> >>>>> iQIcBAEBCAAGBQJYZCPtAAoJEBzwKT+lPKRY82gP/1eG7zYY0dfxBKs8WTl80Wdp >>>>> o3qNaUeDROOdwER8VMmyVb7bmiPkmlj9FGGdKJqhjOSGeaHOLC6cEGce5JZSAzgl >>>>> q+/dOJ4xPaFqbmWUPfvQD7+pJZdFgcVqDowuSx2XWFUy/4L8CAjGii1jSHq3aEWu >>>>> umXiFT37igb0ApfpqYm1BNLtIuNvhoOdtpNxMWKULVF+kOjDPNK4+VE2Zj/2KCdk >>>>> Msm6jmSPvEKKbr+FaawdNyJl2D5qRMDrLwtzy+eGOFzatz6wQYQ6bc+i8JUqLjFo >>>>> 9+id+SLMlCSZxrZo3iTJBna/kUy1TZmqhLu1IpkqqRmapqdlMQpouCDfkpbO6g6B >>>>> Ot0/hffM9r8Ggp+OMd1GNBIzLwZAn3jRumZ/HxUmds5O2U/tJw0C4ajggXBwtZ5D >>>>> fz1ZEPkdkCcyP+3hB8G76BglfhcOfqti4jPmoVj+jqJ3QAQA7FdFcKVrS5erJB3z >>>>> YA3BSasWaOkO6Eg0UhZmwYvjy7YpptaF4NjRlftTiIgSd1gnoZOE1CMpItajjPYx >>>>> LajaudBoXy/wdvXHjydZXOZgzFS4a3UCReZvCwD/upegJsU2UbAoFswX8vq8lW3I >>>>> hu3WwazKja975ANKNQtLzDmKS0W4Hto4+oO94CmvGpY9s6oOkycu93Dnesgx73kS >>>>> TGIwfW3anqIyev1SG5w5 >>>>> =v9/q >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
