On the bright side, it gets the technician to load Linux over W2K, which is a hell of an improvement... (assuming it's a recent version - 7.2 is
----- Original Message ----- From: Chris Puttick <chris@centralmanclc.com> pretty
old like a 2.2 kernel I think). :-)
SSH is a very good way of remotely administering the box - have you tried this? No
I'm missing something here though - use MAC addresses for what? By using mac addresses we can allow access via known machines only. This prevents users spoofing their laptops with known friendly IPs.
The upgrade problem is probably that the SuSE install will still be there and the new one is not in the path, or later in the path so is not being started. Have you tried stopping the squid service then running the newly installed one from its install directory? We've uninstalled squid via yast, but yast doesn't allow one to select the build type - is there a build configuration file somewhere that can be tweaked?
----- Original Message ----- From: Tim Fletcher <tim@parrswood.manchester.sch.uk>
I would mention redhat but that might be consider impolite, another option is to do a suse upgrade from the latest cd or network install Yes lots of references to Red Hat & Squid - What are your reasons?
Or the squid web based proxy admin stuff, having said that you realise that your MAC based security system will break as soon as you have to go via a router to get to the proxy due to the nature of ethernet and ip networking The proxy, LAN and admin will all be this side of the router - would this still be a problem?
I suspect that the suse init scripts (/etc/rc.d/init.d/squid I belive) will be running the old verion of squid that is in /usr/sbin/squid, there are various options but the cleanest of them is a full upgrade to the latest version of suse and then rebuild the squid rpm with your custom configure flags (that I can talk you though) Ha, I think that this answers my question above - yes please
Adrian