As far as I know the version 3.2 squid uses the IPv6 by default, except if
you do by building –disable-ipv6.
Before 3.2 you need do a trick like it is described here:
http://www.squid-cache.org/Doc/config/tcp_outgoing_address/
To enable IPv6 support.
I use 3.3.8 from ubuntu official repository:
http://packages.ubuntu.com/saucy/squid3
where IPv6 is enabled by default.
The helper which I use is delivered by default with the package (v2.17):
http://manpages.ubuntu.com/manpages/saucy/man8/ext_ldap_group_acl.8.html
As I understood from google there is 2 options IPv4/IPv6 in helper. By
default it uses the IPv6 and than IPv4, but it is stuck on IPv6 so it does
not going further.
Therefore IPv4 flag must be defined.
Some people trying to solve the FD line log with such lines in config
(gogole is your best friend:) ):
tcp_outgoing_address 192.168.1.130
or
dns_v4_first on
or
http_port 127.0.0.1:3128
I tried both of those possibilities.
But I still have those lines in log(default debug options):
2013/11/13 22:25:18| commBind: Cannot bind socket FD 25 to [::1]: (99)
Cannot assign requested address
2013/11/13 22:25:18| commBind: Cannot bind socket FD 26 to [::1]: (99)
Cannot assign requested address
2013/11/13 22:25:18| ERROR: Failed to create helper child read FD: UDP[::1]
According http://proxy.ccu.edu.tw/squidfaq/FAQ.pdf; p115 (It is for IPv4,
but logical it leads to IPv6. There should be same principles):
"11.37 commBind: Cannot bind socket FD 5 to 127.0.0.1:0: (49) Can't assign
requested address
This likely means that your system does not have a loopback network device,
or that device is not properly con¯gured. All Unix systems should have a
network device named lo0, and it should be con¯gured with the address
127.0.0.1. If not, you may get the above error message. To check your
system, run:
% ifconfig lo0
The result should look something like:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1
netmask 0xff000000"
And If I do ifconfig lo0, I get (remember I disabled IPv6):
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1217 errors:0 dropped:0 overruns:0 frame:0
TX packets:1217 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:133681 (133.6 KB) TX bytes:133681 (133.6 KB)
Therefore, I have conclusion that even with disabled IPv6 in networking, it
is not possible to disable IPv6 request by Ubuntu's Squid 3.3.8 via conf
file. Except I download the squid sources and rebuilt it with –disable-ipv6
(what I do not want to do - lazy :) ). For small environment it is ok, but
for 50+ users addition requests are not good for traffic.
It would be grate if there will appear a conf solution, but till now I don't
see any.
P.S.: a bit off topic on first post, but it still related to it. :)
-----Oorspronkelijk bericht-----
From: Eliezer Croitoru
Sent: Wednesday, November 13, 2013 9:43 PM
To: squid-users@xxxxxxxxxxxxxxx
Cc: Andrey
Subject: Re: Ubuntu Server 13.10. Squid 3.3.8. WARNING:
external ACL 'memberof' queue overload
OK got it.
The basic issue is that the helper is trying to use ip?
I am trying to understand something about the docs and about the situation.
external_acl_type memberof %LOGIN /usr/lib/squid3/ext_ldap_group_acl
-P -R -K -b "dc=dot,dc=lan" -f
"(&(cn=%v)(memberOf=cn=%a,cn=Users,dc=dot,dc=lan))" -D
nslcd-service@xxxxxxx -w "Pa77w0rd" -h ubuntu.dot.lan
Which the ext_ldap_group_acl that is provided by ? squid?
It is a helper which suppose to communicate with squid via STDIN\STDOUT
and errors STDERR.
Correct me about the above if I am wrong.
This will might help also me to understand the meaning of ipv4\ipv6 in
the docs about external_acl:
http://wiki.squid-cache.org/Features/IPv6#How_do_I_make_squid_use_IPv6_to_its_helpers.3F
I am still unsure what it tries to do but:
In linux "everything is a file" even the hardware suppose to be a file.
it is not always brought to the hands of the Admin to spare the
replacement of a very pricey devices which should be left alone with a
tested piece of internal firmware!
Else then that Linux OS uses for example 3 channels of communication
between the user terminal\screen to communicate with the user\admin.
The whole communication channel is suppose to be "one" FD and I maybe
wrong but STDIN\STDOUT\STDERR is a communication channel between a user
and the computer in a command-line interaction.
There are many other ways to do that but leave it at that.
So a FD is a way for the kernel and other sources to communicate.
It can be a FILE on disk which has read\write channels or a TCP socket
that has a read\write channel or a UDP socket which is a bit more
complex to understand how it's a communication channel since it's a
"datagram" channel.
There is also the "unix" socket which is called a *pipe* which I do not
remember right now how it works since it cannot be used by a read+write
channels in the same sec If I do remember right.
Squid as a server emulates for the software like the external_acl helper
a communication channel as it(squid) was a terminal user that is now
interacting the software\script.
So squid has STDIN\STDOUT\STDERR on a "screen" (virtual inside the
software) and then when a client sends a request squid by the ACLs rules
"consults" the helper using STDIN(for the software while STDOUT for
squid) and then consider the "offer" that correspond to the request in
STDOUT(of the software while beaning squid STDIN) and any STDERR
messages are logged into the cache.log.
So the external_acl helper is like an interviewer for each request basic
"looks" such as src-IP and\or request-url and\or other parameters
available to squid.
So as Amos suggested there is might be a miss configuration in squid
ACLs order that forces the mentioned symptoms.
The logs can help determine the state of each request and the status of
each ACL and while doing so You can see in the logs that the problem is
still there..
"2013/11/13 20:29:13.689| WARNING: Cannot run
'/usr/lib/squid3/ext_ldap_group_acl' process."
The line you see in the logs:
"2013/11/13 20:29:13.689| ERROR: Failed to create helper child read FD:
TCP [::1]"
Is a general line That you will see when the OS trying to bind some
socket what ever it is using the TCP ipv6 protocol.
Disabling the ipv6 sockets from the Linux OS\kernel is not really
possible since once it is enabled it is there unless in the next reboot
you will not load it.
(I am wrong in a case there was some changes in Linux kernel and ipv6
modules.)
There might be a chance of converting the STD channel from one channel
to a TCP channel but I am not sure that the kernel developers will apply
it so soon.
Try to force squid to bind the ipv4 of squid in http_port like:
http_port 127.0.0.1:3128
Which will might cause the comm bind error to be gone from the logs.
Here if you need me,
Eliezer
On 11/13/2013 09:36 PM, Andrey wrote:
I think helper tries to access the IPv6 of the server (I'am not sure!),
but IPv6 is disabled:
/etc/sysctl.conf
# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
#Enable IPv4 forward
net.ipv4.ip_forward = 1
net.ipv4.conf_all.rp_filter=1
Here is the log without ipv4, well debug_options:82,9 84,9, I do not
know what is meaning of FD socket (No info on inet):
