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
Received on Tue May 01 2007 - 16:41:53 MDT
This archive was generated by hypermail pre-2.1.9 : Fri Jun 01 2007 - 12:00:04 MDT