1 Reply Latest reply on Jun 20, 2014 8:11 AM by Bill Robinson

    new to BLSAT, looking for info re patching/patch catalogs/how to use

      Good day all.  I have a bit of a complex question to put out here, so let me set up some background first:



      My environment: multiple tenants, several hundred servers, several dozen environments.  Mixture of platforms and OS versions - note that I am UNIX/Linux only.  I don't touch Windows.

      * In scope for this discussion: I have RHEL5 ranging from 5.1 to 5.11, and RHEL6 from 6.0 to 6.5.



      My personal background:

      * UNIX scripting ability: I've been doing ksh scripting since before fire was invented.  I was also a C programmer in a previous life, so functions and control logic don't scare me.

      * BL Server Automation: Barely out of greenhorn, but I have been making effective use of it to parallelize work.



      The challenge I am currently facing has to do with Patch Catalogs...  I don't entirely understand what BL is trying to do with these, so more info:



      my existing RH install base (all versions) are mostly registered to RHN, and for systems that cannot hit RHN, we do a download-only and copy directories of RPMs about as necessary.

      In short, we're well-accustomed to the model of using RHN or local repositories to provide updates or ad-hoc installations.



      From the time I've spent so far, including some with my org's BLAdmin guy, it looks like BL is approaching the entire matter of software repo & installation from a completely...  different thought model.



      I've experimented with creating a patch catalog, and it seems to download media just fine, but I don't know how to use this to meet my needs.  The documentation I've found on the subject covers the "use of" about as well as a tour of an auto factory prepares you for learning how to drive.



      A couple of use-cases:

      * updating RH servers: I need to be able to specify what minor-version to update to for a given server.  If I have a client running 5.2, I cannot yank them up to bleeding-edge - I need to be able to say "update to 5.3" or "update to 5.4".

        * This exists on a spectrum - for example, I'd update 5.2 servers to 5.4, and 5.6 server up to 5.8, and so on.  Basically I need to have the option of doing an "update to X" where X is any 5.X (or 6.X).  // How the heck do I do this? //



      * installing a particular package on /all/ servers.  Say I want to install a common utility, such as "screen" (and imagine for this purpose that it has a dependency chain), on all servers.

        * assuming that all servers were connected to RHN, I could theoretically issue a "yum install screen" via an NSH job and it would auto-resolve dependencies and install the appropriate version of screen.

        * how do I do something similar with BL?  I need the install process to resolve dependencies, but I also need it to use "version appropriate" repos - I would not want a 5.3 server using a 5.11 repo to install the package.



      The media-repo / update model that is in place is a necessitated by my client+environment structure, and I am not in a position where we can simply say "everyone using RHEL5 is getting updated to 5.11 next week".



      Is there a way to use Bladelogic and its capabilities to serve the model I'm working under?

        • 1. Re: new to BLSAT, looking for info re patching/patch catalogs/how to use
          Bill Robinson

          you might want to take a look here: BSA Best Practices Webinar - Patching with BMC Server Automation (BladeLogic)

          to get an overview of patching.


          in bsa you create a 'catalog'.  the catalog is like a yum repo, except it's not accessible via http.  when you run a 'patching job' bsa copies the patch metadata over to the target(s), runs a yum w/ this metadata and then determines what needs to be installed on a box.  when you deploy the patches, it will copy the needed patches over and install them w/ yum and the copied meta.  it will not use your existing yum repos or rhn that the box is subscribed to.


          to install 'screen' for example you would create a patching job but specify the 'install mode' option (2nd or 3rd panel in the job creation wizard) and the select 'screen' as an include.  the job will figure out the deps and then push to the target.


          the reason we don't expose our repo via http is that one of the design principles of bsa is a 'speak when spoken to' wrt the targets.  the targets never initiate connection back to the bsa infra so a yum repo via http would break that.


          now - if you need to only update to a particular level, you need to create different catalogs, and use the 'update level' filter - for each update level you need.  then you could create server smart groups that contain your 5.2, 5.3, etc targets and then have a patching job that would take the 5.3 catalog and run it against the 5.2 servers.


          unfortunately we don't have a way to strictly enforce the minor version in the patching jobs - so you could have a 5.10 catalog.  and run it against the 5.2 servers and the job would resolve the deps and go push the patches so that part will have to be handled by process.  though you kind of have the same issue if you do a 'yum install xxx' and it's subscribed to the default rhel 5 channel.