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 restrict access to a NSH repeater agent

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

Similar to the Two Agents, One Host configuration for a file server agent, you might want to configure a repeater server in a similar fashion. The reason for such a configuration is to have one agent for the repeater and another agent to manage the OS of the repeater. Alternatively, you might want only a single agent on the server and need to lock that down. Typically, you need to map users to root on the the repeater because of the need to preserve file permissions, especially for a File Deploy Job. This creates a problematic situation, where users are mapped to root.

The following procedure lets you chroot the agent and provide limited root access to the roles that access the repeater. This procedure works for a UNIX repeater.

If you want two agents installed on the repeater, follow the procedure described in How to configure two RSCD agents on a single host, although you can ignore the sections about setting up the blfuser. If you want a single agent only, use the following procedure. Note that any agent on which you perform the chroot operation also needs to include an NSH install, so you should use the NSH installer and install both the RSCD and NSH Client. If you are installing two agents, this requirement is relevant only for the agent on which you perform the chroot operation.

  1. Assuming that the RSCD agent for the repeater is installed in /opt/bmc/local, run the following command to create the following directories:

    mkdir -p /opt/bmc/local/blrepeater
    cd /opt/bmc/local/blrepeater
    mkdir bin dev etc lib opt proc blstaging var tmp sys sbin
    

    If you have a x86_64 system, create lib64 instead of lib, and mount /lib64 in /etc/fstab.

  2. Add the following entries to the /etc/fstabfile (or equivalent):

    /bin /opt/bmc/local/blrepeater/bin none ro,bind 0 0
    /dev /opt/bmc/local/blrepeater/dev none rw,bind 0 0
    /etc /opt/bmc/local/blrepeater/etc none ro,bind 0 0
    /lib /opt/bmc/local/blrepeater/lib none ro,bind 0 0
    /opt /opt/bmc/local/blrepeater/opt none rw,bind 0 0
    /proc /opt/bmc/local/blrepeater/proc none rw,bind 0 0
    /root /opt/bmc/local/blrepeater/root none rw,bind 0 0
    /sbin /opt/bmc/local/blrepeater/sbin none ro,bind 0 0
    /sys /opt/bmc/local/blrepeater/sys none rw,bind 0 0
    /tmp /opt/bmc/local/blrepeater/tmp none rw,bind 0 0
    /usr /opt/bmc/local/blrepeater/usr none ro,bind 0 0
    /var /opt/bmc/local/blrepeater/var none rw,bind 0 0
    
  3. Run mount -a to mount the new mount points.
    rw access will be available to some of the directories, but not to the entire system.
  4. In the exports file of the repeater agent, enter the following as the only entry in the file:

    <host> rw,user=root,rootdir=/opt/bmc/local/blrepeater

    where <host> is the host name or IP address of the application server(s).
    This will chroot the connecting user into the /opt/bmc/local/blrepeater directory. You can still limit the access a bit more to some specific command authorizations. However, take into account that you need to grant nsh for the File Deploy Job runs.

When you set up the repeater in the Infrastructure Manager, use a staging directory of /blstaging. Because you have performed the chroot (the rootdir= in the exports file) '/' is actually relative to /opt/bmc/local/blrepeater.

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

Comments