Fixing a Linux AM agent install problem
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:
- cd /etc/res
- vi
- press a (to start append mode)
- hit enter (to add a blank line)
- hit ESC (to enter vi’s command mode)
- type :wq (to write and quit)
- 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:
- Edit the file
/etc/sysconfig/network(Go VI or go home ;) - Change the FQDN to whatever you want
- 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:
Tags: Automation Manager, libcrypto, Linux, Missing libraries, OpenSSL, Redhat
2012, Automation Manager, Technote | RESguru | 
February 20, 2013 23:27 | 
Comments (0)
From the Technotes-R-Us Dept. How often have you been in the situation that you need to make some changes to some computers out there, but no matter when you try, them pesky users seem to be logging in everywhere at any time! There is of course traditional ways to prevent this, but this article by my fellow RESguru writer 
Subscribe
