Fixing a Linux AM agent install problem

By Max Ranzau

From the Mostly Nuts (and bolts) Dept. Today I was messing around with getting the RES Automation Manager SR3 Linux agent (res-am-6.5-3.125079.tgz) installed on a Redhat Enterprise 6.2. However, I ran into a snafu as apparently there were some prerequisites that weren’t met. After unpacking (read Iain’s article here how to do that) – when I tried to install the RPM file (For you Windows folks, that’s the Linux equivalent of a MSI), I got the following error:

# rpm -ivh res-am-agent-6.5-3.125079.x86_64.rpm
error: Failed dependencies:

libcrypto.so.6()(64bit) is needed by res-am-agent-6.5-3.125079.x86_64
libssl.so.6()(64bit) is needed by res-am-agent-6.5-3.125079.x86_64

Searching a bit, it turns out that these libraries become available if you install a certain version of OpenSSL on the computer first. Specifically OpenSSL098e seems to do the trick. I found a place here where you can download it. Once you’ve downloaded the OpenSSL package and saved it onto the Linux box, it’s just a matter of running it with the rpm -ivh command like shown above.

After that, you want to read the getting-started notes for the Linux agent. Really, please read this guide as the rest of this article will make less than no sense if you don’t!

Anyway the getting started guide describes the commands necessary to configure the firewall and it was all well until I tried to get the agent configured and started using the /usr/local/bin/resamad binary. Unfortunately I kept getting a weird error: No configuration file found, no matter what I did. This obviously shouldn’t happen, but hey, it did and this is how I got around it:

I decided to go for broke and try creating an empty config file, betting on the configuration code would be smart enough to build the proper contents (and yes, this works) The guide specifies that the resamad binary looks for it’s config file, which is located in /etc/res/resamad.xml If this file doesn’t exist, for the less UNIX savvy, here’s a quick step by step guide to creating a blank file using the VI editor:

1. cd /etc/res
2. vi
3. press a (to start append mode)
4. hit enter (to add a blank line)
5. hit ESC (to enter vi’s command mode)
6. type :wq (to write and quit)
7. hit enter

Once this file is in place, you should be able to fire up the agent again with /usr/local/bin/resamad -dd<nnn> where <nnn> is the ip address or FQDN of your dispatcher. I tried using the described resamad -d m parameter for automatic detection, but in my case it didn’t work for some reason. It kept reporting; No environment found. Instead I used the -dd parameter to specify the dispatcher. In this regard, if you want to know what’s going on, you can enable a verbose log by adding -v 3 (yes, there’s a space inbetween the v and the 3) as the first parameter before -dd. This will create a verbose log in /var/log/resamad.log.

Once I re-ran the resamad command (which in my case looked like this /usr/local/bin/resamad -ddbackend.demo.lab ), you will be prompted to select an environment. The prompt should look similar to this, displaying the Environment name, configured under the AM global settings:

1.    res-am@backend.demo.lab
Enter value:

Seeing this prompt tells us the Linux AM agent is talking to the dispatcher and has read the list of available environments (typically only one) When you type 1 and hit enter, the configuration file /etc/res/resamad.xml should be populated with settings for this , which might look something like this:

<?xml version=”1.0″?>
<Agent><FirstTryAutoDetect>1</FirstTryAutoDetect><DispatchersList>backend.demo.lab</DispatchersList><DoRetrieveCompleteList>1</DoRetrieveCompleteList><ProtocolEncryption>0</ProtocolEncryption><NetName>res-am@backend.demo.lab</NetName><NetGUID>{5FAFFEF3-245B-42A3-B47B-CEAFB2EF07E}</NetGUID><WUID>{6e1db5ef-b330-47d6-b4d1-92b22e4653af}</WUID><LastAgentStart>2146163056</LastAgentStart><RebootInTask>0</RebootInTask></Agent>

At this point the agent should show up in your Agents node in the AM console after a few seconds. If it doesn’t, chances are that you may need to set up a dispatcher list under Global options, as I did. Once you’ve done that you’ll need to stop the Linux agent. You can use the script located here /etc/init.d/resamad, which take the two parameters start or stop. This is the equivalent of a NET <STOP|START> RESWAS command line on a windows box. Anyway, do the following

• Use /etc/init.d/resamad stop to terminate the Linux AM agent.
• Configure a dispatcher list
• Start the agent again. Instead of /etc/init.d/resamad start, I did instead like before; /usr/local/bin/resamad -dd<dispatcher.fqdn> to ensure the config XML is written.

The last thing to address is that if you’re setting up a Linux box for the first time in your RES lab, you probably want to change the hostname and domain, as the agent per default will show up in the RES Automation Manager console with the name LOCALHOST.DOMAIN. You probably want to change this into something nicer:

1. Edit the file /etc/sysconfig/network (Go VI or go home ;)
2. Change the FQDN to whatever you want
3. Reboot the Linux box. This is necessary. Do it either by Automation Manager, from the Gnome GUI or, issue an init 6 command from the terminal prompt.

Note that while Windows jobs will continue to run, waiting for Windows agents to come back up, when you issue a reboot task in AM, Automation Manager does not wait for the Linux box to resurface before continuing. Either way, when the agent comes back up, the change should take place in the console:

Automation Manager SR2 – All the details

By Max Ranzau

From the There-we-fixed-it Dept. I guess this is one of the few downsides of living on the California coastline – the bloody 9 hour time diff to Europe! So while I certainly can't be the first to tell you about breaking RES news, I can at least fill in the blanks. Just think of me as Wolf Blitzer in his pyjamas :-) Aaaanyway, today RES Software released the Service Release 2 of Automation Manager 2012. This update and full installers can be downloaded from the RES Support Portal as usual. So what's in the box then? Well, besides the usual staple of fixes there's a handful of interesting enhancements:

• Conditions in AM now support for Windows 8 and Server 2012.
• Just like Worksspace Manager which can fill in it's tables into a pre-existing, empty database, AM can now do the same. This is great for situations where you are fresh out of bullets and the onsite DBA won't let you create a datastore for your pilot.
• Finally AM now also has uppercase and lowercase functions. These are now known as @UPPER[()] and @LOWER[()]
• A new global setting has been created to disable/enable the existing RunbookWho functionality. This setitng and associated $[runbookwho] parameter was created earlier to allow you to specify at scheduling what agent(s) should execute the runbook. See the releasenotes for further details.
• The exchange mailbox task has been updated to support creating alternative email addresses on Exchange 2010 which stores these on the Exchange server and not in Active Directory as previously.

For more information, have a look at the releasenotes here:

New Technote: Dispatcher+ and WebAPI

From the Technotes-R-Us Dept. With the Automation Manager 2012 currently available as RC2, a RESguru article describing the nuts, bolts and registry settings of the new Dispatcher+ has been overdue for a while. To the rescue comes Rob Aarts with a great article, which explains the ins and outs of the new dispatcher component. Also covered in the article is the Master Dispatcher/Cache feature. The most important registry settings to tweak the behavior of the Dispatcher are also covered. Finally the article also covers the new WebAPI for Automation Manager.

<<< Click here to read the article!