Univention Bugzilla – Bug 34044
I/O error in squid_ldap_ntlm_auth
Last modified: 2019-01-03 07:16:13 CET
In an UCS (3.1-1 errata209) DC Master with SQUID(3.1.6) using NTLM+SAMBA(4.0.3) Domain authentication. squid_ldap_ntlm_auth helpers are having some problems validating users: ---[cache.log] 2014/02/04 09:45:59| authenticateNTLMHandleReply: Error validating user via NTLM. Error returned 'BH internal error' --- then, after a while, the helpers start dying one by one with the following traceback: ---[cache.log] Traceback (most recent call last): File "/usr/lib/squid3/squid_ldap_ntlm_auth", line 678, in <module> sys.stdout.write(answer + "\n") IOError: [Errno 32] Broken pipe ---
I think this is related with Bug #30501 Samba4 still referencing a Samba3's Winbind library as dependency.
(In reply to Daniel Orrego from comment #1) > I think this is related with Bug #30501 > > Samba4 still referencing a Samba3's Winbind library as dependency. Than it seems to be fixed with UCS 3.2? Is a backport for UCS 3.1 important?
Currently, UCS 3.1 installs samba 4.03 with libwbclient0 2:3.6 (WBCLIENT_0.9, but WBCLIENT_0.10 is required). One is not able to run 'wbinfo' for example. This could cause performance issues in squid+NTLM-Auth environments with hundreds of simultaneous users since the authentication helpers are restarting all the time.
Hmm, looking at squid_ldap_ntlm_auth I don't see the connection to wbinfo. From my perspective the first question would be if the "BH internal error" is due to an actual bug in the authentication process and at what point. The script implements the "squid ntlm helper protocol", maybe something goes wrong there, or some special case in its implementation of the NTLM authentication causes some unforseen problem. If you still think the wbinfo tool causes the problem we probably better discuss this directly to identify the issue. On a Samba4 DC the program samba-tool would be the tool of choice.
These are two different cases. I can see the traceback in a current school environment - without the 'BH internal error'. 2015093021000646: Traceback (most recent call last): sys.stdout.write(answer + "\n") File "/usr/lib/squid3/squid_ldap_ntlm_auth", line 689, in <module> IOError: [Errno 32] Broken pipe sys.stdout.write(answer + "\n") IOError: [Errno 32] Broken pipe Traceback (most recent call last): File "/usr/lib/squid3/squid_ldap_ntlm_auth", line 689, in <module> sys.stdout.write(answer + "\n") IOError: [Errno 32] Broken pipe Traceback (most recent call last): File "/usr/lib/squid3/squid_ldap_ntlm_auth", line 689, in <module> Traceback (most recent call last): File "/usr/lib/squid3/squid_ldap_ntlm_auth", line 689, in <module> sys.stdout.write(answer + "\n") sys.stdout.write(answer + "\n") IOErrorIOError: : [Errno 32] Broken pipe[Errno 32] Broken pipe ... and so on ... I don't see any obvious hints with raised debug level.
cache.log and squid-ntlm-auth.log can be found at the ticket (possibly sensible data)
> These are two different cases. I can see the traceback in a current school environment Yes, I also saw this again today at Ticket#: 2016042121000705. I guess the reason is trivial and non-critical: Before these lines start there is a squid stop or squid reload, so all squid/ntlmauth/children fail writing (the "answer") back to the parent process (which causes an ugly mess of interleaving tracebacks in the cache.log) We should simply improve the squid_ldap_ntlm_auth helper script to try/except.
Again at Ticket#2016050221000392
> Again at Ticket#2016050221000392 Again every time squid is reloaded or restarted. OTOH this is a cosmetic issue.
As Comment 5 says: "These are two different cases": Ticket#2016050221000392 is the case of Error validating user via NTLM. Error returned 'BH internal error' see Comment 4.
Actually Ticket#2016050221000392 is yet another case, as can be seen from the differing log messages: ============================================================================ 2016/05/02 14:54:26| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. ============================================================================
(In reply to Arvid Requate from comment #11) > Actually Ticket#2016050221000392 is yet another case, as can be seen from the differing log messages: Yes, my bad. (In reply to Arvid Requate from comment #7) > > These are two different cases. I can see the traceback in a current school environment > > Yes, I also saw this again today at Ticket#: 2016042121000705. I guess the > reason is trivial and non-critical: Before these lines start there is a > squid stop or squid reload, so all squid/ntlmauth/children fail writing (the > "answer") back to the parent process (which causes an ugly mess of > interleaving tracebacks in the cache.log) > > We should simply improve the squid_ldap_ntlm_auth helper script to > try/except. Just to clarify: in UCS@school environments these tracebacks happen every time the internet settings in a computer room are changed (looks like a '/etc/init.d/squid3 force-reload'). I agree that in these cases it's non-critical, but the log is messy.
There is a Customer ID set so I set the flag "Enterprise Customer affected".
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.