Cross-Distro Remote Package Administration? 209
tobiasly writes "I administer several Ubuntu desktops and numerous CentOS servers. One of the biggest headaches is keeping them up-to-date with each distro's latest bugfix and security patches. I currently have to log in to each system, run the appropriate apt-get or yum command to list available updates, determine which ones I need, then run the appropriate install commands. I'd love to have a distro-independent equivalent of the Red Hat Network where I could do all of this remotely using a web-based interface. PackageKit seems to have solved some of the issues regarding cross-distro package maintenance, but their FAQ explicitly states that remote administration is not a goal of their project. Has anyone put together such a system?"
Re:Remote admin of a UNIX box? (Score:4, Insightful)
Re:Remote admin of a UNIX box? (Score:5, Insightful)
Uh, right. Like putting ssh commands into a script?
ssh user@host aptitude update
Set up key based login and you don't even have to type passwords. By the sounds of it he needs to pay some attention to each individual machine anyway, as he has multiple distros and wants to determine which patches he needs for each box.
Use script + scriptreplay (Score:3, Insightful)
Not very fancy, but it will get the job done, and it will work for more than just updates, you could also use it to e.g. changes setting or add packages. Or basically anything else you can do from a shell in a repeatable way.
Check man 1 script and man 1 scriptreplay for details.
Re:Can You Script? (Score:3, Insightful)
I have a question about Landscape.
Is it possible to run your own server?
If not, isn't it just another piece of vendor lock-in?
I'm interested in using it but I don't want to depend on Canonical. For example, what if my internet connection goes down? I'd lose the ability to use Landscape at all, right?
Re:Tools exist (Score:3, Insightful)
You sub 7-digit uid guys always do everything the hard way!
Re:Up2date ? (Score:3, Insightful)
that won't quite work - most likely, submitter does not want a particular list of packages to never update, but instead wants to evaluate individual patches, so decision is based on the exact patch, not made for all possibeel patchs to aa prticular package.
Re:In centos you could try (Score:4, Insightful)
Re:Tools exist: we do it this way. (Score:4, Insightful)
You could also use nagios and check_apt/check_yum to alert you of out of necessary security updates, put a script for installing updates on every box (different script for centos/ubuntu, but same syntax), create a user who is added to sudoers for only that script, and create an ssh key for authentication...
Then you can feed the list of hosts that need updating into a script which will ssh to each one in sequence and execute the update script followed if necessary by a reboot..
Re:Tools exist (Score:3, Insightful)
Assuming of course all boxes have the same version of the OS, the same packages installed, etc.
Regarding having the same packages installed, you "only" need to make sure your local repos have all the packages that are used across your install base. The machines will then pull only their own updates, with no fuss. Regarding the heterogeneity... tough cookie. Either you have something more or less homogeneous and you can automate the process, or you're stuck doing things by hand. Especially once you enter the realm of "review each available update by hand and determine whether it's relevant", as the OP asked for. You can't have that and useful automation with 10 different distro/version setups.
Look at the problem differently (Score:2, Insightful)
I think that you are not putting your efforts where it matters.
What is important is that the critical services run properly on each server. Sure that can be affected by patching but also by many other factors. So don't focus solely on the patching, focus instead on making sure all the services are running properly.
You should have your own scripts that check that each server is responding as required. Make your test suite as strong as you can and improve it each time a new problem crops up that wasn't caught by your spying tools.
Once you have this in place, you can safely do daily automatic updates and stop second guessing the package maintainers. You will have a more reliable system and you will save yourself a lot of work too over the years.
Answer: That's your job. (Score:3, Insightful)
That's your job. Bash CLI, the CLI toolkit, CLI Emacs, key-based ssh and a well-maintained, well-documented pack of own scripts in your favourite interpreted PL are just what it takes to do this sort of thing. No fancy bling-bling required or wanted. It would make your worse, not easyer in the long run.
Re:Don't fix it if it ain't broke. (Score:3, Insightful)
You must not handle any credit cards, financial data, or health records then. Some of us are forced to keep servers updated to within a couple weeks of the latest patches or risk a dreaded "uncompliance" status.
Personally, I wouldn't want any of my data trusted to an infrastructure that is only updated once every three years, but in some places that approach makes sense as well. We've certainly taken that approach with SLES servers since Novell's updates are usually more malicious that whatever hole they are patching.