normally there should not be any user mapped in exports. typically in exports there is an entry w/ the ip address or hostname of the bsa appservers and a rw or ro mapping like:
then in the users and users.local file there are mappings for specific bsa roles;users to the local account those roles should act on the target as like:
as bill said, you have to map local users in users/users.local file.
the user you will map to BSA Roles:Users should have permissions to perform the activities which you planned to implement through BSA on those target servers.
have a look at below doc:
I have done several tests regarding the configuration of the new user and RSCD agent.
The user is part of the same groups that the user "root"
The file "exports" have the default configuration:
The "users.local" file has been included the following line
However when using it, using RPD, an error message 2 is obtained and the script is not running on the target server
is not valid syntax for the users or users.local file.
* rw will do an initial rw mapping to nobody
can you elaborate on what you are trying to accomplish here ?
If you want to have any request to the bladelogic agent mapped to rlmuser, then you need to empty the users.local and users file and to have the following line in the exports file:
If you want now to secure a little bit and allow only the RPD dispatchers to access to the agent, then you need to have the following kind of line in your exports file:
dispatch1, dispatch2 rw,user=rlmuser
That said, that means that all BRPD actions will be run on the target as rlmuser who needs to exist on the target and to have enough privileges to be able to execute the action.
To get more about how to setup RSCD and BRPD to work together, go to https://docs.bmc.com/docs/display/public/brpd44/Integrating+with+NSH+and+RSCD+agents
I hope this help.
Fred all that you mentioned, we already did to map the rlmuser user to the request in the RSCD agent; and it presents the following news:
During the execution of the RPD process, the script is created on the target server with read / write / execution permisions, however it fails; in the RPD log we found the message "Exit Code 2".
If we execute the script using the OS console (the same script that was already copied by the tool), the result is succesfull
Are you executing the script in the OS console being log with same user, I mean rlmuser?
If yes, are you sure that your script doesn't need any environment variable that are sourced when you are on OS console but not when it is run with BladeLogic (same as with cron)?
The scripts has been execute using the rlmuser user.
We have two scripts with which the tests were performed, the first one require environment variables, this variables are setup by RPD, and the second one does not require variables. With both scripts we get the same result.
And does simple Copy File Directory action work? This action comes with the product.
The second script is a copy of a file and reading the directory
If you want to properly troubleshoot this, you need to start with a simple test, and work your way up. Trying to execute a script right off the bat is not the proper way to test basic functionality.
First, you need to confirm that your agent user mapping is done properly. To do so, right-click on the target and click Run Custom Command, then double-click on Agent Information.
In the output provided (if it's not giving you an error), look at the Permissions column.
It should show the uid/gid (user/group) that you should be mapping to. If it shows nobody, it's because you did the mapping wrong in users.local. Don't bother troubleshooting anything else until you get that right.
Start with that, and once you confirm it's using the right user there, you can proceed with testing bigger scripts, which then come down to Unix permission management. If you need to run specific commands through BladeLogic, the user you map too needs to be able to run the same commands locally, so a good way to test it is to login as that user using SSH and try the commands manually.
also * in the exports file is pretty insecure. i would atleast put in an ip limitation, it would be better to put a mapping entry in the users or users.local for the os user running the rlm bits on the rlm server and map to the local rlm user, and restrict to the rlm host.