Thanks for your reply. I dont knwo why it became mixed up :o I forgot to mention that i first tries with Ipv6 disabled kernelmodule and ipv4 parameter in external_acl_type, but that didn't work eather so i enabledipv6 to test that to. Iptables Firewall is off, also you can see the the established TCP Connection betweenSquid Process & Helper Process via lsof and netstat. Afaik some sort of firewall wouldnt allow that. squid 1858 squid 14u IPv6 47840 0t0 TCP [::1]:38965->[::1]:45367 (ESTABLISHED)test.sh 10617 squid 0u IPv6 47841 0t0 TCP [::1]:45367->[::1]:38965 (ESTABLISHED)test.sh 10617 squid 1u IPv6 47841 0t0 TCP [::1]:45367->[::1]:38965 (ESTABLISHED) tcp 0 0 ::1:45367 ::1:38965 VERBUNDEN 10617/bashtcp 0 0 ::1:38965 ::1:45367 VERBUNDEN 1858/(squid) ---------------------------------------- > Date: Thu, 24 Nov 2011 23:10:35 +1300 > From: squid3@xxxxxxxxxxxxx > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Squid not communicating with Helper Processes > > On 24/11/2011 10:36 p.m., Christian Zink wrote: > > Hi, > > i have a strange problem driving me mad. I set up a fresh RHEL 6.1 System and installedLDAP and Squid. I want do authenticate users and contol the internet access depending on groups. > > Ldap auth with digest_ldap_auth works fine, but i can't get the squid_ldap_group helper to work. > > My conf: > > (your mailer seems to have mangled the config somewhat badly. > re-formatted while snipping). > > > auth_param digest program /usr/lib64/squid/digest_ldap_auth -H ldap://127.0.0.1 -v 3 -e -b "ou=0500,dc=drv,dc=drv" -u "uid" -A "userPassword" -D "uid=digestreader,dc=drv,dc=drv" -W "/etc/squid/digestreader_cred" > > > external_acl_type ldap_group children=1 %LOGIN /usr/lib64/squid/test.sh > > > The Problem: > > Squid doesnt talk to the Helper Processes! That's all i can see in logs: > > 2011/11/23 17:07:34.219| ACLChecklist::preCheck: 0x7fff8c40cc70 checking 'cache_peer_access download.proxy allow ldap_download'2011/11/23 17:07:34.219| ACLList::matches: checking ldap_download2011/11/23 17:07:34.219| ACL::checklistMatches: checking 'ldap_download'2011/11/23 17:07:34.219| aclMatchExternal: acl="ldap_group"2011/11/23 17:07:34.219| aclMatchExternal: ldap_group("v990493 download") = lookup needed2011/11/23 17:07:34.219| aclMatchExternal: "v990493 download": entry=@0, age=02011/11/23 17:07:34.219| aclMatchExternal: "v990493 download": queueing a call.2011/11/23 17:07:34.219| aclMatchExternal: "v990493 download": return -1.2011/11/23 17:07:34.219| ACL::ChecklistMatches: result for 'ldap_download' is -12011/11/23 17:07:34.219| aclmatchAclList: 0x7fff8c40cc70 returning false (AND list entry failed to match)2011/11/23 17:07:34.219| aclmatchAclList: async=0 nodeMatched=0 async_in_progress=0 lastACLResult() = 0 finished() = 0 > > > While this is repeated endlessly i straced the helper Process ... nothing! I also wrote a dummy Helper, also nothing.Tcpdump on localhost i see the packets from digest_ldap_auth to ldap. Squids talking to digest_ldap_auth over Unix Pipe, that works, and form digest_ldap_auth to ldap over 127.0.0.1 works to,but not from Squid to the Helper although there is an TCP Connection: > > squid 1858 squid 8u IPv6 47834 0t0 UDP *:54597squid 1858 squid 14u IPv6 47840 0t0 TCP [::1]:38965->[::1]:45367 (ESTABLISHED)squid 1858 squid 15u IPv6 47842 0t0 TCP *:d-s-n (LISTEN)test.sh 10617 squid 0u IPv6 47841 0t0 TCP [::1]:45367->[::1]:38965 (ESTABLISHED)test.sh 10617 squid 1u IPv6 47841 0t0 TCP [::1]:45367->[::1]:38965 (ESTABLISHED) > > > > > What i tried so far: > > - the squid_ldap_group works on the shell, piping Username& Group result in OK/ERR depending on the ldap group membership- no activity in strace on squid_ldap_group, but on digest_ldap_auth- no Packets seen with tcpdump on localhost, except from digest_ldap_auth- tried many different options of external_acl_type ...- no iptables active& SELinux Permissive > > Probably it's a really simple solution, like an internal acl not allowing network access to localhost, but i can't see it and its driving me nuts !!!! > > So contact to a server on IPv4 localhost works. But packets never make > it to a helper listening on IPv6 localhost. It looks like an overly > restrictive IPv6 firewall block to me. > > If you can fix those IPv6 firewall rules you may find other things > around the OS start working better as well. As a workaround if that is > not possible, you can try adding the external_acl_type directive option > "ipv4". > > Amos >
