Geoffrey ROBERTS wrote:
>>>> On Monday, 16 February 2009 at 12:52 pm, in message
>>>>
> <1234750932.13574_at_davidwbrown.name>, <david_at_davidwbrown.name> wrote:
>
>> Hello Geoffrey, I have not gone with the default anything on Linux in 10
>> years. It is only a headache.
>>
>
> Ok, I'm not sure why they would want to put it where the default is anyway.
>
> The problem I'm having is figuring out where it actually IS installed.
>
> This appears to be a pre-build configuration item. Don't ask me why, because it seems silly.
>
>
>> I have run Suse in the past but I don't
>> recollect if there are any bug-a-boos about Suse that come to mind.
>>
>
> It seems to work well enough. I've had very little trouble with it. The box its on is
> an ex workstation and it seems to cope quite well. Squid seems to work pretty well
> on it, the only issue I'm having seems to be this redirect script thing which so far refuses
> to work.
>
>
>> That being
>> said I would almost guarantee that any flavor of Linux as preferable with the
>> exception of Debian/Ubuntu that a good ol' tarball of Squid should fix your
>> issues.
>>
>
> Getting it to update the existing version is going to be the hardest part.
> I've yet to find the right part of the documentation for that.
>
> I suppose I can remove the old version and just do a clean install of 3.0, but I'm not
> at all sure how to go about removing the version that's already there.
>
How was the old version installed? It appears that SUSE uses RPMs, so
"rpm -e squid" ought to get rid if the old Squid version. Of course, it
will likely also remove the startup scripts, so you might not want to go
that route without knowing how to relocate/replace them.
http://wiki.squid-cache.org/SquidFaq/InstallingSquid has some generic
tips for starting Squid.
> Obviously I would much prefer that the 3.0 install simply overwrite the
> existing 2.5 install but I have no real idea how to go about that -
>
Run "squid -v" to find out how your current version of Squid was
compiled. Compile Squid 3 using the same arguments and "make install"
will overwrite it. But be aware, if you perform a software update and a
newer Squid 2.5 package is available, your compiled version will be
overwritten.
> That I have no idea where on the darn system it actually lives (aside from squid.conf)
> doesn't help and I'm not sure what if any config stuff I have to specify when it's built.
>
>
>> 2.15 does seem somewhat dated. I only have recently begun using Squid
>> again and I started with 2.6 or 2.7 but because I needed some features I now
>> find myself with the 3.x version.
>>
>
> I've downloaded the squid 3 stable tar.gz and unpacked it on another SLES10 box
> that also has Squid on it (2.15 again - out of the box).
>
No such version. The newest branch of the Squid 2.x tree is
2.7.STABLE6. While this might be construed as pedantic, without using
the same terminology, problems are REALLY hard to solve. Significant
differences exist between 2.5, 2.6 and 2.7.
>> To run Linux reliably you need to not let
>> the individual flavors get you into that Microsoft type thinking that you are
>> locked-in.
>>
>
> No problem with that. I just need to figure out how to do an in place upgrade of the
> existing (working) squid 2.15 without breaking anything else.
>
Assuming you really mean Squid 2.5 and further assuming the proxy is not
internet facing, you really don't. There are likely security
vulnerabilities in 2.5, it doesn't support websites that require NTLM
authentication and that branch has been relegated to the ravages of
history, so support will be harder to come by, but it still works. If
the version of SUSE you are using is still supported, perhaps that
community is able to give support.
That said, upgrading to a actively developed version (2.7 or 3.0) is
probably a good idea.
>> It appears you are dealing with some type of prod. env.
>>
>
> Yes, at present. We have just one dedicated proxy box. We used to use an 'appliance'
> a 'pizza box' with a dedicated cache, but it broke with the last round of hotmail changes
> so I was forced to employ squid since it seems there are no more upgrades for the pizza
> box - Cisco bought the cache manufacturer and it now seems to be part of their IronPort
> device. So it was squid or nothing... It doesn't perform as well as the Pizza box when it was
> working, but it's not too bad.
>
>
>> I would
>> like to suggest you get some Intel based box (almost anything will do as long
>> as it has around a gig of mem) and install Squid 3.x. and get aggressive with
>> the config such that you gain some confidence with getting your Linux env
>> ironment the way you want it.
>>
>
> Figuring out what half the crap in the squid.conf actually means/does is half the problem.
>
http://www.squid-cache.org/Doc/config/ :o) That vast majority of it
does not need to be adjusted. The important bit is ACLs
(http://wiki.squid-cache.org/SquidFaq/SquidAcl).
> But I have this other SLES10 box I can fiddle with - the squid on it is not being used for anything, so I can fiddle with that
> provided I don't need to restart the box itself. (it's our RELOAD server - a backup system for
> Novell Groupwise)
>
> Our squid use is fairly basic, we don't authenticate or log, we have an appliance that
> takes care of that part, so only interested in it caching and proxying as quick as possible
> and (hopefully) getting this port redirect sorted to kludge around this 8080 issue that seems
> not to want to play nice on 2.15.
>
Henrik gave you a copy (fill-in-the-variables) and paste for your
squid.conf (that should even work in Squid 2.5) that doesn't require
redirectors...
http://www.squid-cache.org/mail-archive/squid-users/200902/0275.html
If you supply the actual FQDN and IP of the docushare server (on list or
off), we can even take care of the "fill-in-the-variables" part. Put
your squid.conf in a paste-bin and we can even tell you where in the
config file to put those lines.
>> Getting things to work correctly in a beta or
>> dev. environment is much preferred and you can do a lot of config changes
>> without worry. So, take the plunge and upgrade to a better Squid. 8) David.
>>
>
> The redirect *seemed* to be quick and easy to implement, I should have known anything to do
> with changing *nix based stuff is rarely quick and easy.
Replace "*nix" with "computer" or even "electronic"...
http://xkcd.com/349/ :o)
> That much I *have* learned about it so far.
> The mere fact you need to have squid call script files in .php or perl to do the redirect is enough to put me off. I don't speak
> C, perl, php or java.
>
Again, a copy (fill-in-the-variables) and paste example was provided.
You did state that it didn't work but didn't reply to the request for
more information, which is the only way for us to help you fix it.
> I wish they'd just pick ONE script language and leave it at that.
>
Variety is the spice of life. :o) I'd hate to only see one car on the
roads, or one type of house in a neighborhood and I'd HATE to be forced
to use one scripting language for every problem.
> Thanks for all your help and advice, it's appreciated.
>
> Regards
Chris
Received on Mon Feb 16 2009 - 21:24:15 MST
This archive was generated by hypermail 2.2.0 : Tue Feb 17 2009 - 12:00:02 MST