agent – Virtual Engine Ltd

There comes a time when RES Automation Manager Linux agents need upgrading. A typical example is with the GA release of RES HyperDrive. Now that RES Automation Manager 2012 SR1 has been released, there is a newer Linux agent that isn’t (currently) is the RES HyperDrive appliance.

If you’re like me, you’ll want to upgrade this. The Getting Started with RES Automation Manager Agent for Linux guide will point you in the right direction, but unless you’re a fairly competent Linux administrator you may struggle with certain aspects. For example, to upgrade the RES AM Linux agent all you need to do is:

1. Stop the currently installed RES Automation Manager Agent for Linux by using the command /etc/init.d/resamad stop.
2. Uninstall the RES Automation Manager Agent for Linux.
3. Install the new version of the RES Automation Manager Agent for Linux.
4. Start the new RES Automation Manager Agent for Linux.

So there you have it – simple!

I’ll actually take you through the individual steps to upgrade the Linux agent installed in a RES HyperDrive appliance. These steps are equally applicable to any Linux installation but this will no doubt be a common scenario. As an overview the steps required are:

Find installed RES Automation Manager Agent for Linux version;
Uninstall existing RES Automation Manager Agent for Linux;
Copy new RES Automation Manager Agent for Linux;
Extract RES Automation Manager Agent for Linux;
Install RES Automation Manager Agent for Linux;
Configure RES Automation Manager Agent for Linux;
Start the RES Automation Manager Agent for Linux.

Connecting

Firstly you’ll need to connect to the RES HyperDrive virtual appliance via SSH (see Remotely Administering RES HyperDrive) or connect to the console session.

Uninstall Existing Version

To uninstall the existing RES Automation Manager Agent for Linux you’ll need to find the currently installed version before you can actually remove it. To find the existing version run:

[code]rpm –qa | grep –i res-am[/code]
This will display the current version. Make a note as you’ll need it in a minute or two! Here’s an example screenshot from the RC2 appliance:

To uninstall the agent run:

[code]rpm –e <res-am-agent-version>[/code]

The <res-am-agent-version> is listed in the first command, for example res-am-agent-6.5-0.102354. If successful the agent service should be stopped and the agent uninstalled.

Note: I have seen multiple agents installed in both the RC2 and GA releases. It looks like an oversight and the 6.4-2 version is not actually installed. If you want to remove both entries then the second rpm –e command may give you an error but it will be removed from the list.

Copy Agent Files

You will need to download the latest Linux agent version from the RES support portal as they’re not included in the management console like the Windows clients. Once you’ve downloaded the tarball, copy it to the RES HyperDrive appliance (see Transferring Files to RES HyperDrive) into the /home/hyperdrive directory.

From your SSH/console session run:

[code]mv /home/hyperdrive/res-am-agent-<version>.tgz /tmp[/code]

This will move the file into the /tmp directory. Note: If you don’t have permissions to do this run the ‘su –‘ command first, enter the root password and try again.

Extracting the Agent Installer

As the RES Automation Manager Agent for Linux is compressed it needs extracting before it can be installed. Change the working directory and extract the archive by running the tar command:

[code]cd /tmp
tar xvzf ./res-am-agent-<version>.tgz[/code]

This expands the files into the /tmp/AIX, /tmp/RedHat and /tmp/Suse directories. As CentOS is based on RedHat 5 we need to install this agent version. Install the new agent version by running:

[code]rpm –i /tmp/RedHat/Release5/x86_64/res-am-agent-<version>.x86_64.rpm[/code]

Configuring the Agent

To connect the RES Automation Manager Agent for Linux, we either need to enable auto discovery or specify a Dispatcher list. If you wish to enable auto discovery you can configure the agent with the following command:

[code]/usr/local/bin/resamad –d m[/code]

If you wish to specify a Dispatcher run this instead:

[code]/usr/local/bin/resamad –dd<Dispatcher>[/code]

For example, if your Dispatcher was called RESAMDISP01 (with an IP address of 192.168.0.100) you could either run

[code]/usr/local/bin/resamad –ddRESAMDISP01[/code]

[code]/usr/local/bin/resamad –dd192.168.0.100[/code]

Starting/Stopping the Agent

After the upgrade you’ll probably need to start the agent. To do this you can simply run:

[code]service resamad start[/code]

If you check the RES Automation Manager console you should see your agent online. The version shown below (6.00.111676) is the RES Automation Manager 2012 SR1 Agent for Linux.

If you need to restart the RES Automation Manager Agent for Linux run service resamad stop and then service resamad start. Why there is no service resamad restart command I don’t know! If I wasn’t lazy I’d create the required script but as the appliance is supposed to be “rip and replace” I don’t think I’ll bother 🙂

Phew – hopefully someone finds this useful? Iain

Disclaimer: This is definitely something that is not supported or endorsed by RES Software in any way shape or form. If you can avoid doing this then do not use it. Use at your own risk!

In large RES PowerFuse deployments where RES PowerFuse agents are located over a WAN link, deploying RES PowerFuse can place an unwanted strain on those WAN links during initial deployment. When the RES PowerFuse agent is first installed, it connects to the database and downloads the cache. Until this is complete (and if the Workspace Composer is enabled) a user is unable to log in.

In instances like this it is ideal to have database instances located on the local sites but this is not always possible due to licensing issues etc. If this is the case, then having 100+ agents download 50MB+ leads to a lot of unwanted bandwidth being consumed! This guide will help you stage the deployment so that the agents only download the deltas from our “database snapshot” that is deployed as and when we install RES PowerFuse.

To accomplish this, we need to think about the database structure and how the agent caches its information. The RES PowerFuse 2010 database contains GUIDs for each of the configuration database tables and a master GUID. Whenever anything is updated within the Management Console, the master GUID is updated and this update is cascaded to all corresponding configuration tables that have changed, updating their GUIDs in turn. When an agent connects it checks the master GUID and if different from its own master GUID, compares the GUIDs on each table and downloads the differences. The agent stores its cache and state information in a few places:

The local state of the database cache is maintained in the registry (HKLM\Software\RES\PowerFuse\UpdateGUIDs). These values are the GUIDs that the agent uses when connecting to the database. If any database configuration table GUID is different from what is stored here, an update is performed and the GUID changed to match the GUID in the central database.
The cached database tables are stored in XML format in the ‘%RESPFDIR%\Data\DBCache\Objects’ directory.
All other supporting resources are located within the ‘%RESPFDIR%\Data\DBCache\Resources’ directory and ‘%RESPFDIR%\Data\DBCache\IconCache’ directories.

Now, in theory all we need to do to pre-stage the agent cache is make sure that the UpdateGUIDs in the registry match what is in the \Objects, \Resources and \IconCache folders when the agent service is started. To capture our pre-staged “snapshot” we need to perform the following actions:

Stop the RES PowerFuse agent service.
Copy the \Objects, \Resources and \IconCache folders somewhere safe.
Copy all the UpdateGUIDs from HKLM\Software\RES\PowerFuse\UpdateGUIDs (probably an export to a .REG file)

Herein lies the key to this operation. When we deploy the agent, the RES PowerFuse agent service is going to automatically start and proceed to populate the local cache and update the UpdateGUIDs in the registry. We do not want this to happen until we’re ready. Therefore, this is the process that we need to achieve:

Install the RES PowerFuse agent unattended in the supported fashion, i.e. with Wisdom, ensuring that the agent service does not start.
Copy our “snapshot” files to the \Objects, \Resources and \IconCache folders. How we do this depends on your deployment methodology. Typically the “snapshot” files would be captured as a RES Wisdom Resource Package, but it doesn’t really matter.
Set the HKLM\Software\RES\PowerFuse\UpdateGUIDs registry values to our point-in-time ““snapshot” to match what is representative of the “snapshot cache” folders. Again, this can be achieved quite simply with a RES Wisdom “Apply Registry Settings” task, but could also be achieved via a batch file calling REG.EXE.
Start the agent service (a reboot is still required for the kernel mode drivers to start). If we just reboot the service state is left as “Automatic” and will start after just a reboot.
The agent will check the database and only download the deltas from the point-in-time “snapshot” hopefully saving a whole load of bandwidth!

The only real “gotcha” in this entire process is ensuring that the agent service does not start when the agent is installed, e.g. in Step #1 above. As the agent does not support the public properties to accomplish this we need to do it via a .MST file. To save you a whole load of time and pain we’ve kindly left one here for you called “RPF-NoServiceStartAfterInstall”.

Our example deployment command for Step #1 might look a little like this: MSIEXEC.EXE /i RES-PowerFuse-2010-SR2.msi TRANSFORMS=RPF-NoServiceStartAfterInstall.mst DBTYPE=MSSQL DBSERVER=<DatabaseServer> DBNAME=<DatabaseName> DBUSER=<DatabaseUser> DBPASSWORD=<DatabasePassword> /norestart /qn

Please remember; test and test again!

Tag: agent

Upgrading RES AM Linux Agents