2 Replies Latest reply on Jun 6, 2005 7:54 AM by Aaron (Admin) Evans

    Solaris Patch Compliance

      Hi all,


      As mentioned in my thread re: HP-UX Patch Compliance, Capgemini are looking into automated patch compliance for all OS's.




      Much has been written in these forums dealing with issues arising from setting up Solaris patch compliance, but there don't seem to be many details on exactly how it is done.


      The guys at Capgemini have actually started work on this. I will post details of what they have worked out so far later.


      Could anybody who has addressed this issue please post details here of how they've done it.




        • 1. Re: Solaris Patch Compliance

          I had a prospect (soon to be a customer) who insists on using patchpro (sun's patching utility) to keep their solaris machines up to date. Sun requires them to do so so that they can receive support. The second reason is that the list of patches for each server will be unique depending on what is installed on them.


          So, I whipped up an integration with patchpro. I am working on a knowledge base article, but it is not ready yet.


          Note that the solaris machines require internet access to run the "analyze" and "download" phases, although patchpro can use a proxy. The "download" phase could be moved to a centralized server with internet access (see enhancements below), but I'm not sure the analyze phase could be.


          Here is basically how it works:


          1. I have a nsh script (and NSH job) that runs "smpatch analyze" on remote machines, parses the output and creates a two-column CONFIG FILE (not an extended object), called outstanding_recommended_patches.csv on each machine. The first column is the patchID, the second is the description. We'll use this file as a listing of patches we're going to install, but not before we've had a chance to review it and perhaps tweak it.


          2. Using an audit job, I audit the outstanding_recommended_patches.csv config file on each box. As the master, I use a snapshot of an EMPTY recommended_patches.csv. Thus the master says that there should be no outstanding patches. The audit report shows each target's list of outstanding patches.


          Here is where the beauty of using the config file comes in. You can now go through each target's list of patches and select patches that you do NOT want to deploy at this time. You simply package the delta and deploy and it will remove the unwanted patches from the target's list.


          3. I have a second NSH script (and job) that iterates through the patches in outstanding_recommended_patches.csv and runs "smpatch download" on each one, then writing the patchID and description to a second file, called queued_patches.csv (I also create an extended object on this second file so that you can browse the list of queued patches, but not modify it).


          4. I have a third NSH script (and job) that iterates through queued_patches.csv and runs "smpatch install" on each patch. If it is successful, the line is removed from queued_patches.csv (this is done in the script). If it fails, it will stay there. All the patchpro log message output is available in the job log.


          I have this working in my demo environment on my solaris x86 VMware instance. In order to streamline the process and make a slicker demo, I have put items 1 and 2 in a first batch job (note I use an NSH Job script to "wrap" the audit job so I can include it in a batch job) and I have put items 3 and 4 in a second batch job (although in practice you would want to separately schedule the download and instll phases).


          A few obvious enhancements to this:


          1. there is a patchpro command for configuring which types of patches that are permissable to be installed. You use it like so:


          pprosetup -i standard:singleuser:rebootafter:reconfigafter


          We were thinking we could set up a few script jobs that would for example, set patchpro so that only "standard" patches could be installed, so then a junior admin could safely go and run through the whole process and any patches requiring immediate reboot or single user mode would not be installed and be left in "queued_patches". You can see in the log why a patch was rejected, so you could even maintain other config files that keep a running list of outstanding patches that require say, singlesuser, that way you can plan to do them all at once.


          2. You could in theory have patchpro installed on a centralized solaris machine that would be responsible for downloading all patches and adding them to the depot. You could then create deploy jobs for each target machine, referencing the patches in the depot. As it is now, if each machine requires patch X and there are N machines, patch X will be downloaded N times. Further, there is no automatic rollback since we are not using bldeploy to deploy the patches.


          Anyway, I'll post a follow up when the KB article is ready. I am going to include all my scripts and step by step instructions for installing the whole thing, especially for AEs who want to put this in their demo environments.


          In the mean time, if you need more info, please email me at aaron@bladelogic.com.

          • 2. Re: Solaris Patch Compliance

            I have finally gotten around to posting the KB article:




            Note that this technique can be easily ported for any platform and 3rd party tool provided that the analyze,download and install phases can be done via the command line.