-1

I'm doing a internship to setup a Linux patch management system. It's a IT infrastructure management company with focus on Microsoft systems. They currently have ~15 Linux servers to manage and variate from RHEL5 and 6, Centos 6, OEL5 and 6 to SLES 10 and 11. Most systems are geographically separated over different clients/custommers.

A few requirements:

  • has to work over WAN behind a firewall/nat router (agent)
  • a dashboard for update control (push updates, blacklist updates, alert when updates are available)
  • support for RHEL5+6+derivatives, SLES10+11 and Ubuntu 12.04.

The commercial solutions only seem to support their own distributions (RHN Sattelite, SUSE Manager, Landscape)

I had a little test run with puppet and ansible. Ansible felt quite good but does not work behind nat/firewall because of it's agent-less design. Puppet seemed to be overcomplicated to get patch management working and the dashboard is lacking a good view.

Whenever i try to accomplish patch management with a CM system it does not feel right. It feels like working with the wrong tools.

What are your idea's/experiences about Linux patch management? Is their any solutions which does fit my needs?

closed as off-topic by TheCleaner, Sven, MadHatter, dawud, Dave M Oct 1 '13 at 18:41

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking product, service, or learning material recommendations are off-topic because they tend to become obsolete quickly. Instead, describe your situation and the specific problem you're trying to solve." – TheCleaner, Sven, dawud, Dave M
If this question can be reworded to fit the rules in the help center, please edit the question.

1

Disclaimer: this seems like a very opinion-based question, and the answer I'm about to give is mostly opinion.

CM is the wrong tool for what you're being asked to provide. Because of the disparity of OSes, you probably won't find "one tool to rule them all" - you'll have to make something homegrown, and with that comes all sorts of possible pitfalls, errors, and snafus. There are so many things wrong with this situation that the only way to summarize it is:

"Because Racecar!"

0

In my environment, I utilize Puppet for all server management. However, I also don't ever use a GUI and do everything via the Command Line -- so, I don't really take a web interface as a selling point.

My Puppet installation deploys a script that automatically runs and installs any security updates, which is of course controlled by a daily cron job. You could do this by hand by and put the script (which is essentially something like yum -y update --security) and have cron run it daily (/etc/cron.daily).

However, Puppet is a good way centrally manage all servers from one master and send out any updates you want. Whether you're applying a SSHD_CONFIG config to all servers, or just want to run a new cron job. Manually touching 15 servers? NTHX.

However, another script runs once a week and lets me know what updates are available for a given server. Some packages I may not want to just automatically update to the newest version for functionality reasons, etc. However, I do always want to make sure security patches are applied.

So -- I mean, in a small Linux environment like yours that make the most sense. Puppet is free, and there are a lot of Puppet Modules already created and available in addition to a lot of documentation being available.

Chef is also an alternative to Puppet, though I've never used it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.