On Thu, 2007-11-01 at 10:56 -0400, Phil Smith III wrote:
> A friend asks what's the easiest way to apply updates to multiple
> z/Linux servers.
>
> Aduva isn't an option for political reasons (they had a bad
> experience with Aduva before).  What's the conventional wisdom here?

Our Unix patching group used to use Novell's ZENworks, and is probably
going to move over to a home-grown solution based on their own YUM
repositories.  They've also looked at Bigfix and Altiris.  The former
seemed promising because it focused on maintenance and didn't try to
be a build tool; the latter was attractive to management because the
Windows group had some licenses to experiment with.

ZENworks had these advantages:
 * They had a central database so you could (in principle) schedule
   and run updates for individual servers and see what was installed
   on a given server.
 * It was fairly straightfoward to keep a cluster of patches for a
   particular point in time---as long as you had a fast server and a
   lot of disk space.
 * One could roll updates on a server back to a particular date.
 * You can do anything with a CLI so it was easy to script things.
   Given how complicated our update procedure was (for reasons mostly
   unrelated to Zenworks), this was a *BIG* advantage.

It turns out some of these didn't matter:
 * Our maintenance model and builds meant that we always had to reboot
   a server before and after updates.  No automated package does that
   reliably.
 * Rollbacks, while a good feature when presenting to application
   owners, rarely fix anything.

Our version of ZENworks is getting badly out of date.  Novell has
changed enough of the internals that there's a big learning curve
coming up, and so the patch team is looking elsewhere.  We're
switching to either our own yum repositories (which work well with our
maintenance model and are very simple to maintain), or to using a new
build tool for updates.

One problem with a yum repository is that one needs a tool to keep
it synced with the OS vendor.  If you use RHEL this isn't easy (we
may keep Zenworks just to do that); I don't know about SLES.

Personally, I have fond memories of ZENworks but I gave it up a year
ago to learn VM...

The VM group is probably going to go to our own yum repositories as we
get out of Levanta, but that's a different discussion.

Ted Rodriguez-Bell
Enterprise Hosting Services - z/VM and z/Linux
[EMAIL PROTECTED], 415-243-6291 (w)
--
Company policy requires:  This message may contain confidential and/or 
privileged information.  If you are not the addressee or authorized to receive 
this for the addressee, you must not use, copy, disclose, or take any action 
based on this message or any information herein.  If you have received this 
message in error, please advise the sender immediately by reply e-mail and 
delete this message.  Thank you for your cooperation.

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to