Arrrgghhhh! :-). I look after a few remote machines, and don't consider automated update mechanisms an option. It only takes a vendor to release one lousy patch and you can have a very bad night/day/week. Explaining to a customer what happened after an oops like that can be very hard.
My 2c on remote support, for what it's worth.. If you're seriously going to have remote sites, build a machine of the same or very similar config, and test updates on your machine first. Join the patch list for the distro you're using, and filter all of the patches with a bit of common sense before applying them. ie: if the machine you're supporting is behind a good firewall, don't bother applying local exploit patches for the fun of it at 2am. Leave it till during the day when you can dig yourself out of a hole more easily if need-be. Unless the patch is for a major external exploit, run it for a day or two on your own server.. For eg. a recent glibc update for RH 7.1 stopped ODBC to mysql working... I tested the patch, but didn't test mysql.. I applied the patch to all my sites, and two of them had problems the next morning with their main business app which uses ODBC connections for an app on Windows workstations that I wrote, oops... The lesson there is understand what your customer uses the server for, and test that functionality on your box before you stuff theirs, and be prepared to back out stuff, and know how to do it remotely. Make sure the customer appreciates what you're doing from off-site, or get them on a support contract. If you've got 2 or 3 sites, and a big run of patches come out like the glibc mess early this year with RH, you can spend a whole lot of time testing patches, applying them, etc. You want to make sure you're getting paid for it, or at least getting some good will from the effort. The users certainly wont know that you spent five hours on the net looking for a solution to their ODBC problems.. (Bugga) Lastly... Keep site logs. A log of everything you do to the remote servers. Partially for your own reference, and partially so you can say to the customer 'look what I did, aren't I a nice chap' when you send the bill... It'll also help if you have to rebuild the server from a drive crash, you'll know what config was not standard, and you'll know what patches were on it. Backups.. make sure they happen. You often have to rely on non-techo folks for this, keep a scheduled contact with them to check on backups. It may not be your fault if the backups don't work, but it's really hard to look good as the IT guy when it goes wrong. Oh, and I use screen with wget scripts to get the patches, and rpm -Fvh them manually, so at least I'm watching when it goes wrong! Good luck :-). Cheers, me. ----- Original Message ----- From: "Andrew J Sands" <[EMAIL PROTECTED]> To: "CLUG" <[EMAIL PROTECTED]> Sent: Saturday, November 30, 2002 10:21 AM Subject: apt-get for RPM's and remote update? > > Hi dee ho... list dwellers, > > I have a remote ( to me ) machine which currently runs a RedHat 7.1 install > that needs a few updates. I was considering the use of apt-get to enable > this to be done mostly whilst I wasn't logged in via ssh nor physically > onsite. > > Can I have war chants, fables, quotes or knowledgeable verse from those whom > may have tried this experiment?? > > later, Andrew Sands >
