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 BMC Server Automation Application Server is UNIX or Linux, and you want to be able to manage that server using BMC Server Automation.
Note
These steps are not possible in Microsoft Windows environments, as it is not possible to install two agents on a Windows server. These steps are also not possible on HP-UX systems, because HP-UX agents do not support the local installation method.
Before reading this page, you should have a good understanding of the BMC 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 BMC 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 runifconfig -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 bece
orbge
.
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
- Create the Logical Interface:
- 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>
Tip
If a device is not up, use the following commands:
Solaris — ifconfig hme0:1 up
Red Hat Linux — ifconfig eth0:1 up_ or _ifup eth0:1
SuSE Linux — ifconfig eth:vip1 up_ or _ifup eth:vip1- 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
You should see the listings for "x" above replaced with real values for MAC, IP Address, and so on.
- 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
- On Solaris —
Installing the management (first) agent
Using either the RSCD agent installer, NSH, or BMC Server Automation installer, install the agent and the other desired components.
Configuring 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:
- Stop the Application Server agent
/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)
- Start the agent:
/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.
- Stop the management (first) agent before installing the second agent, using the following command:
/etc/init.d/rscd stop
- Start the local agent installation by passing in the
-local
option:
./<RSCD agent install script> -local
- Run through the agent installation.
This agent will manage file server connections.
Do not install the agent under the existing install path (for example, /opt/bmc/bladelogic/NSH). Choose a path such as /opt/bmc/rscdfs.
Do not choose to set up any agent mappings during the installation. - 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
- 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
- Solaris: Link S90rscd-fs to the new /etc/init.d/rscd-fs file:
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:
/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 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 blfsuser
Note
This normally creates a group called blfsuser as well. If you want another group, you must first create the group using the following command:
groupadd blothergroup
Then add the blfs user to this group:
userdd -g blothergroup -c "Bladelogic Fileserver User" -s /sbin/nologin blfsuser
Modify 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.
Comments