Unsupported content


This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

How to configure two RSCD agents on a single host

This topic was edited by a BMC Contributor and has not been approved.  More information.

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.


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.

 Click here to see the table of contents for this topic


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.

Two Agents one Host

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.


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.

  1. 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:
      1. Create the Logical Interface: ifconfig hme0:1 plumb
      2. Assign a new IP address to the device: ifconfig hme0:1 <ipaddress> netmask broadcast <broadcastaddress> up
      3. Remove the logical interface: ifconfig hme0:1 unplumb
    • Red Hat Linux:Perform the following steps:
      1. Create or modify the ifcfg file, such as /etc/sysconfig/network-scripts/ifcfg-eth0:1

        HWADDR='<your mac>'
        IPADDR='<your ip>'
        GATEWAY='<your gateway>'

        For example:

      2. Bring up the interface by restarting the network: /etc/init.d/network restart
    • SuSE Linux:Perform the following steps:
      1. 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:


        For example:

      2. Bring up the interface by restarting the network: /etc/init.d/network restart
  2. Ping the new device to validate that it is up
    ping <ipaddress>


    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

  3. 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 netmask ff000000
      dmfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet netmask fffff000 broadcast
      ether 0:3:ba:6b:80:5e
      # ifconfig dmfe0:1 plumb
      # ifconfig dmfe0:1 netmask broadcast
      # ifconfig -a
      lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
      inet netmask ff000000
      dmfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet netmask fffff000 broadcast
      ether 0:3:ba:6b:80:5e
      dmfe0:1: flags=1000842<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet netmask fffff000 broadcast{noformat}
    • SuSE Linux:

      # ifconfig <interface>:<your_label>
      # 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
      Interrupt:169 Memory:f8000000-f8012100

      You should see the listings for "x" above replaced with real values for MAC, IP Address, and so on.

  4. 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 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:

  1. Stop the Application Server agent
    /etc/init.d/rscd stop
  2. 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)
  3. Start the agent:
    /etc/init.d/rscd start
  4. 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.

  1. Stop the management (first) agent before installing the second agent, using the following command:/etc/init.d/rscd stop
  2. Start the local agent installation by passing in the -local option:
    ./<RSCD agent install script> -local
  3. 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.
  4. Stop the rscd service for the new agent, using the following command:
    <second rscd install dir>/NSH/conf/rscd stop
  5. 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
  6. Copy the "local" init script into the appropriate directory:
    cp <second rscd install dir>/NSH/conf/rscd /etc/init.d/rscd-fs
  7. 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
  8. Edit <second rscd install dir>/NSH/conf/secure and add:

    rscd:host=<fs_dns_name>:port... (or IP address)
  9. 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
  10. If the second agent is to be used as a file server, configure the file server using the following steps:
    1. 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


      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

    2. 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
    3. 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.
    4. Grant ownership on the storage directory to the blfsuser
      chown -R /opt/bmc/bladelogic/NSH/storage blfsuser:blfsuser
    5. 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.

Was this page helpful? Yes No Submitting... Thank you