Skip navigation

Simplify RSCD Agent installation and upgrade process

score 375
You have not voted. On Roadmap

In large environments containing thousands of targets of different OS flavors, considering the frequency of BMC BladeLogic service packs, hotfixes and patches, upgrading RSCD agents on all targets can be a very tedious and costly task to perform every year. This is often the reason customers can't keep up with releases.


As it is now (up to the latest available release at this time), each operating system has a different type of installable, some being os-specific install packages (rpm, Install Shield, etc...) and some simple archives or os shell scripts. Some are graphically interactive and some command-line based. Some can easily be made silent (unattended) while others require more work to do so.


For a product that is made to be a server automation application, having interactive (GUI based on Windows) installables makes no good sense in my opinion.


This poses several problems:


  1. Customers can't keep up with releases due to the time it takes to package and prepare upgrade jobs
  2. Customers often encounter problems (mostly on Windows) because of certain unpredictabilities in large environments (i.e. servers in need of reboot, servers with unusual configurations and security settings, etc...) and the way Install Shield packages behave.
  3. Upgrades are complex and costly to prepare, perform and troubleshoot (in man hours)
  4. A proper test environment, with an operating system of each flavor, is required to test and prepare upgrade packages properly and ensure a smooth upgrade across all targets.


Here is what I suggest to improve this whole process:


The first thing to do would be to fundamentally change the way RSCD agents install and process upgrades. The easiest and simpliest way to do it in my opinion, would be this:


  1. Get rid of all installable packages and only distribute RSCD agents as archives (i.e. zip or tar.gz)
  2. Make all files of the agent contained inside the directory where it's installed. No more /usr/lib/rsc (Unix) or c:\Windows\rsc (Windows). Keep all files inside the same directory tree. This will make it easier to distribute and also easier to manage in cases where servers are heavily hardenned (security wise).
  3. Modify the agent's service/daemon binary (rscd) so that when you execute it, it checks if it's been started for the first time. If so, perform first time configuration (unattended), which means for example, to create and register the service on Windows and startup scripts on Unix, and to do any other type of post installation configuration required to properly run the agent.
  4. Within the same mindset as point 3, distribute upgrades and patches as patch files and apply them automatically and unattended when the agent restarts. An agent upgrade would then simply become a file deploy/copy with a post-command to restart the agent. Since patch files have to be based on a specific release (i.e. patch from a specific build to another), upgrade patches would have to be cummulative and based on the major/minor release. (i.e. from 7.6.x to 8.1.latest, from 8.1.x to 8.1.latest, from 8.1.x to 8.2.latest, from 8.2.x to 8.2.latest, etc...). This would be a good compromise to keep the file size as small as possible without creating hundreds of different patches.


The above suggestion alone would make it much simplier to perform agent upgrades without having to spend too much time packaging the solution and wrapping it in package deploy jobs.


Then, to go a step further, the following could also be done:


  1. Create a new type of job: RSCD Agent Upgrade Job
  2. This job would read an archived upgrade package from a specific location on the file server based on the operating system and plateform of the target, copy it to the target, unpackage it (unzip or untar), copy any pre/post-upgrade script, restart the agent to perform the upgrade, wait for the agent to come back online and validate the upgrade, cleanup any leftover from the previous version if any (could also be done during the upgrade process).
  3. To make it even nicer, the upgrade packages could be fetched live from the BMC support site (similar to the way Shavlik XML files of the Patch Configuration window are downloaded) and cached on the file server based on the version of BSA that is currently running. In other words it would only download the latest versions compatible with your BSA server(s) in case you have not yet upgraded your BSA infrastructure to the bleeding egde release.




I believe this solution as a whole would be beneficial to both customers and BMC Software, since customers would be able to follow patch releases more easily and therefore reduce their support cost, while being more aligned with the direction BMC Software is taking with BSA (by reducing the number of legacy versions).


Vote history