Eureka! It appears that despite ipv6 being disabled on the Ubuntu Server OS itself, it was still interfering with the helper somehow. All I had to do was change the line in squid.conf that starts with "external_acl_type" to read: > external_acl_type session ipv4 ... and all of a sudden, cache.log stopped displaying errors, and everything started to work. It redirects properly now. Thank you Amos for your time, and advice. If we ever meet in person, remind me that I owe you a beer :) Tal On Thu, Jul 12, 2012 at 9:40 AM, Jack Black <secretagent101@xxxxxxxxx> wrote: > I have no idea why, but all of a sudden, after reinstalling and > reconfiguring squid 3.2.0.18 from scratch, my Ubuntu Server 12.04 64 > bit VM started working. I really did nothing special to get it to run > - just the same as I've been doing. As soon as this happened, I > quickly followed the same steps on my real Ubuntu Server 12.04, but > there, it once again refused to work. The squid.conf file on the > working VM and my production Ubuntu Server aren't just similar - they > have the same md5 checksum. They are exactly the same. > > I tried the -d flag, but it had no effect on the level of detail found > in cache.log. This is probably to be expected, considering I just > spotted this line within the same log file: > > WARNING: Cannot run '/usr/local/squid/libexec/ext_session_acl' process. > > Here's the section around that line: > > 2012/07/12 09:02:20 kid1| Starting Squid Cache version 3.2.0.18 for > x86_64-unknown-linux-gnu... > 2012/07/12 09:02:20 kid1| Process ID 8871 > 2012/07/12 09:02:20 kid1| Process Roles: worker > 2012/07/12 09:02:20 kid1| With 1024 file descriptors available > 2012/07/12 09:02:20 kid1| Initializing IP Cache... > 2012/07/12 09:02:20 kid1| DNS Socket created at [::], FD 8 > 2012/07/12 09:02:20 kid1| DNS Socket created at 0.0.0.0, FD 9 > 2012/07/12 09:02:20 kid1| Adding nameserver 205.233.109.40 from /etc/resolv.conf > 2012/07/12 09:02:20 kid1| Adding nameserver 8.8.8.8 from /etc/resolv.conf > 2012/07/12 09:02:20 kid1| helperOpenServers: Starting 1/1 > 'ext_session_acl' processes > 2012/07/12 09:02:20 kid1| commBind: Cannot bind socket FD 10 to [::1]: > (99) Cannot assign requested address > 2012/07/12 09:02:20 kid1| commBind: Cannot bind socket FD 11 to [::1]: > (99) Cannot assign requested address > 2012/07/12 09:02:20 kid1| ipcCreate: Failed to create child FD. > 2012/07/12 09:02:20 kid1| WARNING: Cannot run > '/usr/local/squid/libexec/ext_session_acl' process. > 2012/07/12 09:02:20 kid1| Logfile: opening log > daemon:/usr/local/squid/var/logs/access.log > 2012/07/12 09:02:20 kid1| Logfile Daemon: opening log > /usr/local/squid/var/logs/access.log > 2012/07/12 09:02:20 kid1| Store logging disabled > 2012/07/12 09:02:20 kid1| Swap maxSize 0 + 262144 KB, estimated 20164 objects > > I tried changing the ownership of the ext_session_acl file to > proxy:proxy, and even set its permissions to 777, but neither helped. > It doesn't appear to be a permissions issue. Is there anything > obviously wrong here that might indicate why ext_session_acl won't > run? Like maybe the line that reads "ipcCreate: Failed to create child > FD."? Or is that normal? > > Tal > > On Wed, Jul 11, 2012 at 7:12 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: >> On 12.07.2012 12:37, Jack Black wrote: >>> >>> I just tried the same squid configuration on Ubuntu Mini remix 11.04 >>> x64, and Ubuntu Desktop 12.04 x64 live (I didn't even bother >>> installing it). They both work perfectly, just like CentOS. Whatever >>> the problem is, it appears to be specific to Ubuntu 12.04 Server >>> edition for some reason, which just happens to be the exact OS my >>> production server (the one that needs to run squid) is running. >>> There's got to be something that I'm missing... >>> >> >> Since you have the helper from squid-3.2 built stick with that one. It has a >> few important bug fixes and the -d flag operating. >> >> If you add -d to the helper command-line parameters in squid.conf it should >> record in cache.log what is going on with each session lookup. >> >> I'm kind of suspicious that the helper is having problems in the background >> that are not showing up. >> >> Also double-check that the squid.conf are completely identical between the >> machines. Security in squid is default-closed so the expected behaviour with >> a failing helper should be causing TCP_DENIED constantly to the client on >> Ubuntu, not access to the Internet. >> >> >> Amos >>
