I have a use case where I need to run same set of shell instructions multiple times with different users and compare the results on remote hosts.
Thought about automating this using Rundeck, and since I am not allowed to use ssh keys password-less authentication in this case, Rundeck would be ideal.
below is a sample job listing (XML) for a parametric job that accepts username and a password and just prints the username in a simple embedded shell script.
<joblist>
<job>
<context>
<options preserveOrder='true'>
<option name='Password' required='true' secure='true' valueExposed='true' />
<option name='User_Name' required='true' value='App_User' />
</options>
</context>
<description></description>
<executionEnabled>true</executionEnabled>
<id>5e63d0fa-9bae-4d1d-bc09-a2d8429f8b19</id>
<loglevel>INFO</loglevel>
<name>Parametrized_job1</name>
<scheduleEnabled>true</scheduleEnabled>
<sequence keepgoing='false' strategy='node-first'>
<command>
<script><![CDATA[echo "This is a test Job"
echo 'using form $RD_OPTION_USER_NAME' $RD_OPTION_USER_NAME
echo 'using form ${option.User_name}' ${option.User_Name} #doesn't work :)
echo 'using form \@option.User_name\@' @option.User_Name@
]]></script>
<scriptargs />
</command>
</sequence>
<uuid>5e63d0fa-9bae-4d1d-bc09-a2d8429f8b19</uuid>
</job>
</joblist>
The job parameters are better accessed as passed by Rundeck env. as:$RD_OPTION_paramname
The above job option env. variable will be passed to all rundeck executed scripts so it is much easier to use it in this form than the one between @ signs.
The form ${option.User_Name} is not working in this case as Rundeck will use it as a command-line argument if we are running a commad step rather than an embedded script.
below is an example job definition:
<joblist>
<job>
<context>
<options preserveOrder='true'>
<option name='Password' required='true' secure='true' valueExposed='true' />
<option name='User_Name' required='true' value='App_User' />
</options>
</context>
<description></description>
<executionEnabled>true</executionEnabled>
<id>5d1db9a0-d381-49ec-8981-c483b375751c</id>
<loglevel>INFO</loglevel>
<name>Parametrized_job2</name>
<scheduleEnabled>true</scheduleEnabled>
<sequence keepgoing='false' strategy='node-first'>
<command>
<exec>echo ${option.User_Name}</exec>
</command>
</sequence>
<uuid>5d1db9a0-d381-49ec-8981-c483b375751c</uuid>
</job>
</joblist>
Rundeck parametric jobs will prove very useful for doing generic tasks and generic automation.
Please check more info in Rundeck documentation at: http://rundeck.org/1.6.2/manual/job-options.html#prompting-the-user
Thought about automating this using Rundeck, and since I am not allowed to use ssh keys password-less authentication in this case, Rundeck would be ideal.
below is a sample job listing (XML) for a parametric job that accepts username and a password and just prints the username in a simple embedded shell script.
<joblist>
<job>
<context>
<options preserveOrder='true'>
<option name='Password' required='true' secure='true' valueExposed='true' />
<option name='User_Name' required='true' value='App_User' />
</options>
</context>
<description></description>
<executionEnabled>true</executionEnabled>
<id>5e63d0fa-9bae-4d1d-bc09-a2d8429f8b19</id>
<loglevel>INFO</loglevel>
<name>Parametrized_job1</name>
<scheduleEnabled>true</scheduleEnabled>
<sequence keepgoing='false' strategy='node-first'>
<command>
<script><![CDATA[echo "This is a test Job"
echo 'using form $RD_OPTION_USER_NAME' $RD_OPTION_USER_NAME
echo 'using form ${option.User_name}' ${option.User_Name} #doesn't work :)
echo 'using form \@option.User_name\@' @option.User_Name@
]]></script>
<scriptargs />
</command>
</sequence>
<uuid>5e63d0fa-9bae-4d1d-bc09-a2d8429f8b19</uuid>
</job>
</joblist>
The job parameters are better accessed as passed by Rundeck env. as:$RD_OPTION_paramname
The above job option env. variable will be passed to all rundeck executed scripts so it is much easier to use it in this form than the one between @ signs.
The form ${option.User_Name} is not working in this case as Rundeck will use it as a command-line argument if we are running a commad step rather than an embedded script.
below is an example job definition:
<joblist>
<job>
<context>
<options preserveOrder='true'>
<option name='Password' required='true' secure='true' valueExposed='true' />
<option name='User_Name' required='true' value='App_User' />
</options>
</context>
<description></description>
<executionEnabled>true</executionEnabled>
<id>5d1db9a0-d381-49ec-8981-c483b375751c</id>
<loglevel>INFO</loglevel>
<name>Parametrized_job2</name>
<scheduleEnabled>true</scheduleEnabled>
<sequence keepgoing='false' strategy='node-first'>
<command>
<exec>echo ${option.User_Name}</exec>
</command>
</sequence>
<uuid>5d1db9a0-d381-49ec-8981-c483b375751c</uuid>
</job>
</joblist>
Rundeck parametric jobs will prove very useful for doing generic tasks and generic automation.
Please check more info in Rundeck documentation at: http://rundeck.org/1.6.2/manual/job-options.html#prompting-the-user
