How to configure two RSCD agents on a single host
This page documents the steps for configuring two agents on a single host. Generally, the only reason why you would want to do this is when your TrueSight Server Automation Application Server is UNIX or Linux, and you want to be able to manage that server using TrueSight Server Automation.
Before reading this page, you should have a good understanding of the TrueSight-Server-Automation-architecture.
Background
By default, an Application Server does not need an agent to run. The application server needs to connect to a file server, which needs an agent to run. In order for the file server to function correctly, all users must have the same permissions to the file server storage directory. All users need write access to the file server in the same manner.
This causes a problem if you want to manage the operating system of the file server system, as well as use the system as the file server for TrueSight Server Automation and registered in the console. This is because when a server is in the console, that server should have access control lists (ACLs) pushed to it to prevent unauthorized users from accessing that machine. If the ACLs are left wide open (essentially a requirement of the file server), users who have access to the Application Server in the GUI will have unrestricted access to the file system.
If ACLs are pushed to a File server, long-term side effects can happen due to users writing to the file server directory using different user accounts on the file server. For example, if the BLAdmins user is mapped to 'root' and other users are mapped to 'nobody' or 'bladmin' and files are getting written to the file server using those accounts, problems can arise later as objects are shared within the console using those various roles.
By installing separate agents for the file server OS and the file server storage, you can configure them in a way that is secure while also allowing the Application Server to be managed within the console. To do this, watch the following video and follow the steps the sections that follow.
This diagram outlines the concept of configuring two agents on a single host. Note that the application server does not require an agent, while the file server does. The application server agent is used for the management of the application server.
Before You Begin
The first stage of this page documents steps that have been tested in a Solaris environment only. Slightly different steps apply to a Linux environment, and these steps have not yet been completely updated. If you have an existing Application Server installed, see the applicable section below for the detailed steps. Both sections can be referenced if you are installing on a brand new Linux Application Server.
Assumptions
Note the following assumptions:
- The file server is running a supported UNIX OS.
- The file server has two valid IP addresses, one reserved for the file server agent and one reserved for the normal server management agent.
- The <second rscd install dir> directory is the directory chosen to install the second agent and it is outside of the installation directory of any other BMC Software.
For example, if the first RSCD agent is installed in /opt/bmc/bladelogic/NSH, then the second RSCD agent could be installed in /opt/bmc/rscd-fs/NSH, but not /opt/bmc/bladelogic/NSH/rscd-fs/NSH.
Preparing for installation
Perform the following tasks to prepare for the installation.
- Add a second IP Address to the machine.
To do this, first run ifconfig -a to list the devices.
You need to find the correct interface to use if your system has multiple interfaces. It will help to know the correct network that you want this traffic to pass over.
Note that the network device name may not be as listed — for example, it might be ce or bge.
The procedure depends on OS type:- Solaris:Perform the following steps:
- Create the Logical Interface: ifconfig hme0:1 plumb
- Assign a new IP address to the device: ifconfig hme0:1 <ipaddress> netmask 255.255.255.0 broadcast <broadcastaddress> up
- Remove the logical interface: ifconfig hme0:1 unplumb
- Red Hat Linux:Perform the following steps:
Create or modify the ifcfg file, such as /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=none
HWADDR='<your mac>'
IPADDR='<your ip>'
ONBOOT=yes
GATEWAY='<your gateway>'For example:
DEVICE=eth0:1
BOOTPROTO=none
HWADDR=00:21:70:7b:5d:6b
IPADDR=192.168.100.248
ONBOOT=yes
GATEWAY=192.168.100.1- Bring up the interface by restarting the network: /etc/init.d/network restart
- SuSE Linux:Perform the following steps:
Modify the ifcfg file, such as /etc/sysconfig/network/ifcfg-<interface>:<mac> (for example, ifcfg-eth-id-00:1b:78:42:e5:d0).
Add these three lines to the end of the file:IPADDR_<your_label>='<your_ip>'
NETMASK_<your_label>='your_netmask'
LABEL_<your_label>='your_label'For example:
IPADDR_vip1='192.168.248.100'
NETMASK_vip1='255.255.255.128'
LABEL_vip1='vip1'- Bring up the interface by restarting the network: /etc/init.d/network restart
- Solaris:Perform the following steps:
Ping the new device to validate that it is up
ping <ipaddress>- Check broadcast address and netmask using the ifconfig -a command
The following sample lines illustrate how to use the ifconfig command.Solaris:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
dmfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.20.86.190 netmask fffff000 broadcast 10.20.95.255
ether 0:3:ba:6b:80:5e
#
# ifconfig dmfe0:1 plumb
#
# ifconfig dmfe0:1 10.20.86.191 netmask 255.255.240.0 broadcast 10.20.95.255
#
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
dmfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.20.86.190 netmask fffff000 broadcast 10.20.95.255
ether 0:3:ba:6b:80:5e
dmfe0:1: flags=1000842<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.20.86.191 netmask fffff000 broadcast 10.20.95.255{noformat}SuSE Linux:
# ifconfig <interface>:<your_label>
eg:
# ifconfig eth0:101vip1
eth0:101v Link encap:Ethernet HWaddr xx.xx.xx.xx.xx.xx
inet addr:xxx.xx.xx.xxx Bcast:xxx.xx.xx.xxx Mask:xxx.xxx.xxx.xxx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:169 Memory:f8000000-f8012100
- Make this setting persistent across reboot
- On Solaris — echo "<fs_dns_name>" > "/etc/hostname.dmfe0:1
- Linux — echo "<new ip> <fs_dns_name> <fs_short_name>" >> /etc/hosts
Installing the management (first) agent
Using either the RSCD agent installer, NSH, or TrueSight Server Automation installer, install the agent and the other desired components.
To configure the management agent
The agent used for server management needs to be configured so that it does not interfere with the second agent that will be installed, specifically the file server. Perform the following tasks:
- To stop the Application Server agent, run the following command if you are using a Linux system with systemd support:
systemctl stop rscd.service
If you are using a Linux system without systemd support, run the following command:
/etc/init.d/rscd stop - Ensure that the agent listens on the 'management' IP (the IP not dedicated for use by the file server agent):
- Edit the /usr/lib/rsc/secure file
Modify the 'rscd' line to the IP address/name of the 'management' interface, as follows:
rscd:host=<app_server_dns_name>:port... (rest of line unmodified)
- To start the Application Server agent, run the following command if you are using a Linux system with systemd support:
systemctl start rscd.service
If you are using a Linux system without systemd support, run the following command:
/etc/init.d/rscd start - Validate the Application Server agent using the agentinfo command.
Installing the File Server (second) agent
Complete the following steps to install the second, or file server, agent.
- To stop the management (first) agent before you install the second agent, run the following command if you are using a Linux system with systemd support:
systemctl stop rscd.service
If you are using a Linux system without systemd support, run the following command:
/etc/init.d/rscd stop - Start the local agent installation by passing in the -local option:
./<RSCD agent install script> -local Follow the instructions in the installation script and complete the agent installation.
This agent manages file server connections.- Stop the rscd service for the new agent, using the following command:
<second rscd install dir>/NSH/conf/rscd stop - Ensure that the agent is not running, using the following commands:
ps -ef | grep rsc
root 693 3062 0 14:53:06 pts/1 0:00 grep rsc - (Only applicable if you are using a Linux system without systemd support) Perform the following steps:
- Copy the "local" init script into the appropriate directory:
cp <second rscd install dir>/NSH/conf/rscd /etc/init.d/rscd-fs - Link the startup scripts to the new /etc/init.d/rscd-fs file. The method for doing this depends on the OS type:
- Solaris: Link S90rscd-fs to the new /etc/init.d/rscd-fs file: ln --s /etc/init.d/rscd-fs /etc/rc2.d/S90rscd-fs
- Linux: chkconfig --add rscd-fs
- Copy the "local" init script into the appropriate directory:
Edit <second rscd install dir>/NSH/conf/secure and add:
rscd:host=<fs_dns_name>:port... (or IP address)- Ensure that the two agents start and stop themselves without interfering with the other agent.
- If you are using a Linux system with systemd support then perform the following steps:
- systemctl start rscd.service; ps -ef |grep rsc
- systemctl stop rscd.service; ps -ef |grep rsc
- systemctl start rscdlocal1.service; ps -ef |grep rsc
- systemctl stop rscdlocal1.service; ps -ef |grep rsc
- If systemd is not supported then perform the following steps:
- /etc/init.d/rscd start
- /etc/init.d/rscd-fs start; ps -ef |grep rsc
- /etc/init.d/rscd stop; ps -ef |grep rsc
- /etc/init.d/rscd start; ps -ef |grep rsc
- /etc/init.d/rscd-fs stop; ps -ef |grep rsc
- If you are using a Linux system with systemd support then perform the following steps:
- If the second agent is to be used as a file server, configure the file server using the following steps:
Create a new OS user called blfsuser
This user can have a locked password. This user may be able to have a shell of /bin/false or /bin/nologin or /dev/null. The home directory can be the /path/to/fileserver if applicable.
On Linux, use the following command:
useradd -c "Bladelogic Fileserver User" -s /sbin/nologin blfsuserModify the rsc files for universal file server access.
Edit the <second rscd install dir>/NSH/conf/exports file:<appserver01> rw,user=blfsuser
<appserver01-fs.domain.com> rw,user=blfsuser- Ensure that the users and users.local files are blank.
Edit the <second rscd install dir>/NSH/conf/users and <second rscd install dir>/NSH/conf/users.local files and remove any entries. - Grant ownership on the storage directory to the blfsuser
chown -R /opt/bmc/bladelogic/NSH/storage blfsuser:blfsuser - Do not register this host in the console.
Additional security
It should be possible to use a certificate from the application server to allow only the appserver user (for example bladmin, or SYSTEM) to connect to the file server. Follow the normal nsh/certificate configuration, except use the 'bladmin' or 'SYSTEM' account on the appserver as opposed to your user account. Push the cert to the file server only.
After you have completed the installation of the file server agent, if you want an extra layer of security in user mapping, you can configure the users and users.local files, as described in Configuring-the-file-server-agent-ACLs.