hi Henrik - answers inline...
Henrik Nordstrom wrote:
tis 2007-05-01 klockan 22:49 +0100 skrev Gareth Edmondson:
Now this threw up an error along the lines of having two cache_peer
names the same. So we edited the hosts file in DNS setting a name to
resolve to the same IP address. The line now reads:
cache_peer sslproxy 443 parent 7 <and then all the other stuff>
There is a name= option to cache_peer to solve this without having to
fake host names..
Thanks for the advice here. I read about this name= option earlier in
the archives - but I got the impression from previous posters that it
was in version 3 of squid and not the stable version that ships with
Debian Etch. The stable version is 2.6.5-6.
A quick look at debian.org reveals that 3.0.PRE5-5 is there. I have not
tried this because we have been advised to stick with the stable branch.
We thought this would work - but it didn't, so we edited the
cache_peer_access line to say 'cache_peer_access sslproxy allow CONNECT'.
You also need to deny CONNECT from the other..
Okay - I think we may have done this. The lines looked something like this
cache_peer_access sslproxy allow CONNECT
cache_peer_access sslproxy deny all
cache_peer_access <original upstream name> deny CONNECT
cache_peer_access <original upstream name> allow all
I'm not sure they are in the right order.
Everything seems to be working. However when we try and connect to the
443 website it challenges us again for the AD username and password.
Upon entering this the browser challenges us again and again and again -
simply not letting us through.
What does your access.log say?
I shall take a look in work tomorrow.
Cheers
Gareth
