I've used"RSCD760-115-RHASX86_64.SH" to install the RSCD agent on a Oracle Enterprise Linux 5.4 which is a distro of Red Hat under the hood.
SELinux is set to enforcing.
I logged in to the system as root (did not sudo or su to root) and ran the installation.SH file. During the installation, it asked if I wanted to allow the installation to alter SELinux. I indicated I did with a 'y' and pressed on with the install. Everything went as expected. The RSCD agent fired up and started listening on 4750.
I could telnet to the newly installed agent over 4750 FROM the application server.
I added the server to the OM. This is where it starts to get wierd. The server's RSCD property is set to "Agent is not licensed" even though it was just installed and is under that 10 day grace period.
I can't expand the Live view of the server in the OM. I get the "software is not licensed" error.
When I crack open the RSCD log on the target system, i see some strange errors.
WARN rscd - <ip address> (BLAdmins:chris): CM: Bad command ("bladmin"). Probably wrong encryption type/key
A "tail -f" on the rscd.log demonstrates there is one of those WARN lines for each time I try to expand something in the Live view of the server from the OM.
Confused, I started poking around in my exports, secure, users.local file, etc.
I had told the install script that I did not want to set root equivalancy, but that I DID want to map a user.
I opened each of the files is this is what I found:
- * rw
- blank (that is, all of the commented text was there, but no actual entries)
- blank (again, it had commented text, but no entries)
- Was expecting "BLAdmins:* rw,map=root"
The files obviously did not write correctly during installation. I manually corrected users.local and copied the secure file from the application server down to the target RSCD system. Now, I get the old WARN entry in the log as before, but also get a new error.
WARN rscd - <ip address> (???): ???: TLS setup failed for agent: Protocol mismatch. Check that client and server "secure" files match. Exiting and terminating connection.
Has anyone seen this before and know what is going on? I'm suspecting SELinux is stepping on something...