On Sun, 22 Feb 2004, Eric Kahklen wrote:

> AGAIN!! Thanks for the help! I think I may have it working (knock on
> wood).


Good.

> From the Squid website they show Squid 3.0Pre3 as the latest for testing
> with the Daily auto-generated release. Can I just patch my 3.0Pre3
> version? or downloaded the Daily auto-generated release? Is the later
> more stable/secure??


As I said Squid-3.0 is not yet released. The 3.0 versions available
for download is suitable for testing but not for production use.

The current nightly snapshots is expected to have pretty much the
functionality of the upcoming Squid-3.0 release, but is known to have many
bugs and also have not passed any serious testing by the Squid developers.

As a Squid developer I can not encourage you to run Squid-3.0 in
production until Squid-3.0.STABLE is released. You are more than welcome
to test it in your lab however. If you really want to use any 3.0 release
in production at this stage you must fully verify that it works properly.

Bug reports to PRE releases (including nightly snapshots of PRE releases)
are generally not accepted unless you can verify the problem exists in the
current nightly snapshot or at least something which is not too far away,
so once you hit a problem you will be required to upgrade.

> I have these two likes which makes it work:
>
> #I am using my FQDN and I point my browsers to the FQDN with the added
> path (exchange)
> https_port 443 cert=/etc/squid/key-cert.pem defaultsite=mydomain.org


Ok.

> #This does not include "originserver" since it won't work unless I take
> it out.
> cache_peer 10.0.0.10 parent 80 0 proxy-only no-query no-digest
> front-end-https=on login=pass
>
> The "originserver" option won't work. Is this a bad thing??


In my setups OWA has required the originserver option, but if it works
without then there is no panic.

The drawback from not using this option when it works without is that
persistent connections can then not be used between Squid and the web
server cache_peer and may result in a slight performance loss.

> I didn't seem to need the vhost option either. Again would this be a
> problem down the line??


Well.. running a PRE release in production will give you problems down the
line, but the vhost directive as such is not needed unless you want to
accelerate multiple servers.

Regards
Henrik