We are using the "Run Command Line" action to run a command. In this case, it's IBM's IIB mqsideploy. But the command being used in the "Command Line String" input parameter could be anything. The input parameters are displayed below. In addition to these input parameters the action needs to run as a specific user - so we have configured the action's Credentials settings to use the user we want to use (details regarding how user impersonation has been implemented on the agent are also below). 

For example; we are using iib's mqsideploy to interact with IBM IIB. We're doing this using the following:

Command Line String [String]

/opt/ibm/mqsi/inst1/iib-10/server/bin/mqsideploy <brokerSpec> -e <integrationServerName> -a <BARFileName>

Work Directory [String]

/opt/ibm/mqsi/inst1/iib-10/server/bin

On the agent machine we have configured the conf/processes.properties with a cmd.to.execute=/path/to/customActionsRunner.sh

And, the customActionsRunner.sh is configured to use: echo $nolio_password | sudo -u $3 -S ./ActionsRunner.sh $1 $2 $3

While running this action it returns the following:

Run Command Line action has finished successfully.
Return value: 127
Std out:
Std err: /opt/ibm/mqsi/inst1/iib-10/server/bin/mqsideploy: error while loading shared libraries: libImbCmdLib.so: cannot open shared object file: No such file or directory
Command line executed: /bin/sh -c /opt/ibm/mqsi/inst1/iib-10/server/bin/mqsideploy <brokerSpec> -e <integrationServerName> -a <BARFileName>

Search Results

Web resultsIBM Integration Bus(IIB)

This specific command (IBM's IIB mqsideploy command) has prerequisites. The exact prerequisites are not clear. But, maybe it was a modified $PATH or maybe some Environment variables need to be set - similar to how ORACLE_HOME, ORACLE_BASE, ORACLE_SID, etc.. are needed to run oracle commands. 

Release : 6.6

Component : CA RELEASE AUTOMATION RELEASE OPERATIONS CENTER

One solution to solve this problem was loading the user's profile (.bash_profile) before running the mqsideploy command. In full, the solution looked like this:

1. Make sure your conf/processes.properties file was configured with: cmd.to.execute=/path/to/customActionsRunner.sh
2. Configure the action's Credentials settings to use the username you need to use to successfully execute the command.
3. Configure the action's Command Line String to use the following: source /path/to/user's/.bash_profile && /opt/ibm/mqsi/inst1/iib-10/server/bin/mqsideploy <brokerSpec> -e <integrationServerName> -a /path/to/<BARFileName>

The main piece here is prefixing the "Command Line String" command with: source /path/to/user's/.bash_profile

Sourcing the user's .bash_profile, in this case, prepared the environment with all of the prerequisites needed to successfully run the mqsideploy command. 

Considerations:

While needing this kind of solution, where a CLI has requirements that are not met while using sudo -u, there are some considerations that should be made when using this solution for multiple systems. Here are some of those considerations:

1. The prerequisites for successfully running mqsideploy is defined by IBM's IIB mqsideploy CLI. It is recommended to better understand the prerequisites for using this CLI instead of simply loading the user's profile. After understanding the prerequisites for using the CLI then it can be better evaluated whether loading the profile is necessary or maybe an overkill. But it might be less intrusive, more efficient, more easily portable, and effective to exclusively handle the prerequisites before running the command (likely within the same command line string).
2. Different usernames might be used across different servers and the location of user's .bash_profile might be different.

Recommendations:

Whenever trying to use the Nolio RA "Run Command Line" action to accomplish an advanced task (like interacting with a 3rd party application), it is recommended to take a phased approach to this. The approach looks like this:

1. Define your objective for any particular action/instruction. This should include considerations into the behavior of the action/instruction. For example, if the desired outcome of starting a task is to wait for the task to complete (synchronous - vs starting a task and returning immediately to do other tasks while the task is processing; asynchronously) then things get more complicated. Tasks achieved through web interfaces do not always translate into a single task. Understanding the requirements before hand can help reduce the time it takes you find a solution.
2. Once your objective have been clearly defined then you can investigate options. Some possible options include (but are not limited to):
   • The API used by the action does does offer a way to achieve the desired outcome. In which case you can investigate, test and/or inquire whether or not the action pack has a way to use this option (or uses it by default). 
   • The API used by the action pack does not offer a way to achieve the desired outcome. In which case there are two options:
   1. Determine if another API is available (Rest, CLI, WSDL, program, script, maybe Selenium webdriver script, etc..) that completes the task from start to finish. If yes then it is likely that Nolio RA can wrap around that API. 
   2. Investigate how the desired outcome can be tested so that the Nolio RA workflow can be designed accordingly. See 2.b.
   • Submit an "Idea" on the community for a new action pack, action or capability. 
   • Investigate how the desired outcome can be tested so that the Nolio RA workflow can be designed accordingly. This may involve flows designed to loop with a delay to wait every X seconds/minutes before testing for a condition to be true or false. In this case:
   1. Sometimes there are things that may differ from one environment to another. For example, maybe it will take only 5 minutes for a task to complete in a lower environment while it takes 20 minutes to complete in a higher environment. So you will want/need to tailor the behavior of the workflow to the environment in which it's being run. You can use Nolio RA Environment parameters for these situations. 
   2. If you need to test for the success of something then it is recommended to also test the failure of that same something. This way you can design the workflow to act accordingly instead of dealing with uncertain/ambiguous results. 
• Determine if an action pack is available that seems to meet your needs. If there are specific behaviors that you seek then understanding the following will help you identify solutions and the design of your workflow. For example, if an action pack is available and you determine that you want to start an application and wait for that application to finish starting before doing anything else then you can investigate or inquire what API’s are used by an action pack and whether or not that api (or other api’s) do what you want. This will usually result in one of three ways:
• If there is no action pack or the existing action pack does not meet your needs then you can:

Investigating:

While investigating whether an existing action pack behaves the way you need it to, the following is recommended:

1. Inquire/investigate the API used by the action pack to interact with the 3rd party tool/application. 
2. Inquire/investigate whether or not that specific API offers a way to accomplish what you want to do in a way you prefer.
3. Test the solution without using Nolio RA. This may reveal nuances, pre-requisites, expectations, etc.. that will result in a more stable and predictable solution. 
4. Apply to Nolio RA. It is helpful to also consider how Nolio RA goes about accomplishing tasks while performing #3. This is because Nolio RA may need to impersonate another user in order to accomplish those tasks. Depending on which option the agent is configured to use (or should be configured), to impersonate other users, it may behave differently. Knowing what option you want/need can allow you to test  accordingly. There are 3 different ways that Nolio RA can currently handle impersonating users on Linux. There is only one way on Windows. The three methods available for Linux are:
1. Default: it ssh's into 127.0.01 with the username/password you provide in the action's Credentials settings.
2. sudo: this involves configuring sudo and the customActionsRunner.sh to use: sudo -u <username>. This carries with it some implications. One example of this is sudo -u <username> does not behave the same as logging in as that user. 
3. su: this involves configuring and the customActionsRunner.sh to use: su - <username> -c. This method, too, carries implications with it. For example, unless the agent is running as root then su usually requires a password to be given. Sudo can get around being prompted for a password by utilizing its "NOPASSWD" option.  

Variations of implementation options:

Some of the variations below may be considered. However, these variations have not been thoroughly tested. Even if they were, it is important to consider how these variations may impact other deployments. 

SSH: 

The SSH implementation of user impersonation requires a password to be specified in an action's Credentials settings. A variation of this implementation is available that would not require a password to be specified. That variation involves setting up SSH keys on the agent machine, for the user that that you're specifying in the Credentials settings window. If the SSH keys are setup to not require a password or passphrase then the password field will not need a value. 

Sudo:

By default, sudo will not try and load a user's profile. However, there is an option (-i) that instructs sudo to run the shell specified by the target user's password database entry as a login shell. This means that login-specific resources (such as profiles) will be read by the shell. If you want to use this variation then you could use something like this in your customActionsRunner.sh:

echo $nolio_password | sudo -u $3 -i -S -- sh -c "cd /path/to/RA_Agent_Home && ./ActionsRunner.sh $1 $2 $3" 

Su:

By default, the su command requires a password. For this reason you need to make sure that, at a minimum, you use it with the customActionsRunner.sh set to use:

echo $nolio_password | su - $3 -c "cd /path/to/RA_Agent_Home ; ./customActionsRunner.sh $1 $2 $3"

The command above uses the "-" (aka -l, aka --login) option which starts the shell as login shell with an environment similar to a real login. See `man su` for more information. If for some reason you need to specify a shell different than the users default shell then you can specify the shell to use by configuring customActionsRunner.sh with the following:

echo $nolio_password | su - $3 -s /bin/bash -c "cd /path/to/RA_Agent_Home ; ./ActionsRunner.sh $1 $2 $3"