I deployed my first Operations Manager 2007 R2 agent on to a SUSE Enterprise virtual machine running on Hyper-V today. It took a little work because the documentation downloads from MS don’t include this and the online documentation appears to be quite outdated – the dialogs are nothing like what they describe. I guess the guides are from the beta release.
I did a mass import of the latest management packs and included the Linux ones I’ll need in the future.
I set up an account to manage the server. This was a admin account. If your Linux boxes are grouped to share usernames and passwords then you can use this approach for this account:
- Create an account
- Install the agents
- Group the agents in OpsMgr
The account was then assigned to the Action and Privileged RunAs Profiles. You could use two accounts if you wanted. I didn’t.
Next up was the Linux box. Ensure that its firewall allows the follow TCP ports in:
- TCP 1270 for agent traffic inbound
- TCP 22 for SSH inbound
TCP 5723 will be used for the agent to talk to the OpsMgr server. WinRM is used as a part of this so you need to configure it on the OpsMgr 2007 R2 managment server:
winrm set winrm/config/client/auth @{Basic="true"}
Finally you need to ensure that the DNS records for the Linux box are set up:
- A (Forward) record for name to IP resolution
- PTR (reverse) record for IP to name resolution
The agent deployment would not work without the latter for me. I found no documentation of this. However, I did do a Linux discovery based on IP address. I need to test doing manual installations and a name based discovery. I’ve a funny feeling the PTR was only required to get the name of the machine for the trust generation in the absence of a name in the discovery process.
I kicked off the discovery via SSH. That took a wee while and eventually I saw the process … discovery, installation, cross certification via SSH. Finally I linked the computer object (you could use a group) to the 2 RunAs profiles. The agent was now monitoring correctly.
I went into Authoring and set up a log monitor. That was easy. Look for a string in the log you want to search for and another to test for (they might be the same). Enter the name of the computer to scan, the log file (and location) to scan and the alert string to check for. You can also enter a test string that is already in file. You can test the monitor whenever you want with this. I saved it and allowed time for it to download to the agent. To test I logged into the Linux machine via SSH (putty) and typed:
echo this is a failure >> test.log
I did this at /. Test.log was appended with “this is a failure”. My search string was “fail”. Moments later an alert was raised and notifications were sent. Perfect.
I quickly followed this up with a monitor to check the health of the MySQL daemon. I can’t test that because it’s in production but it was easy. The template wizard scanned the designated Linux box for “services” and allowed me to pick the mysqld process.
First impressions? This looks good. It’s pretty well integrated and seems scalable in administration compared to the pre-OpsMgr 2007 R2 attempt at cross platform extensions. The only downside is that “Computers” is different to “Linux Servers”. Computers has all the Windows servers and only the Windows servers. I’ll need to remember to check on both views for a health check.