How to restrict access to an NSH repeater agent
This topic was created 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
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.
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
mount -ato mount the new mount points.
rw access will be available to some of the directories, but not to the entire system.
In the exports file of the repeater agent, enter the following as the only entry in the file:
where <host> is the host name or IP address of the application server(s).
chrootthe 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
rootdir= in the exports file) '/' is actually relative to /opt/bmc/local/blrepeater.