Local command vs Command vs Adhoc issue with &&

[kcd]

Hi

What I really want to do is run a local command/script against a node.hostname and correctly error out if it fails.

I'm having issues with shell execution and escaping with multiple commands (&& or ||). I've tried many workarounds like /bin/bash -c "echo one && echo two" but nothing worked for me.

Adhoc run of echo one && echo two

12:07:26	one
	12:07:26	two

Local command execution of echo one && echo two

12:15:24

one && echo two

Command execution echo one && echo two

(nothing, just error)

12:26:19	[workflow] Finish execution: rundeck-workflow-node-first: [Workflow , Node failures: {somenode=[]}]
	12:26:19	[Workflow , Node failures: {somenode=[]}]

This is what I would like:

res=$(/usr/bin/curl -k -w %{http_code} -s --output /dev/null http://${node.hostname}/) && echo $res && if [ $res -eq 200 ]; then exit 0; else exit 1; fi

A better way to do this would have been a local job with a script that used an option "host" and then call it as a workflow from a remote job passing it's hostname, however... You cannot call a workflow with the parameters "-host ${node.hostname}", it simply does not resolve. A worthwhile feature request?

Cheers

k

[Moses Lei]

The hostname attribute is only passed on non-local commands. You could try a couple of things... the most obvious is to execute this from the client, i.e. use a script step and put this code in there, but use http://localhost/ instead of http://${node.hostname}

Another option is to pass in the node filter as an option and get the list of nodes using "dispatch", then loop on them (the job itself would execute only on the server). i.e. pass a regex in as ${option.hosts} or something, then run "dispatch -I ${option.hosts}" in your script to get the list.

Another alternative is to use a script-based node step plugin:

http://rundeck.org/docs/developer/workflow-step-plugin-development.html#script-based-step-plugins

Moses

--

Moses Lei

Principal, Village Chime LLC

mobile: +1 703 901 5969 | skype: moseslei | yahoo: moseslei

k

--
You received this message because you are subscribed to the Google Groups "rundeck-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rundeck-discu...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[kcd]

Thanks Moses, some good suggestions there.

Not quite true however, I am successfully using ${node.hostname} in one line Local Commands. It just doesn't work in "Job Reference" steps (perhaps it should?).

I want to avoid running on localhost because these are windows boxes with limited scripting ability and it wouldn't check the firewall. I like your idea of using the node filter, one wouldn't be able to manually alter the node selection however.

I'm experimenting further with the escaping required for Local Command ... see the \n in the following. I still cannot fine anyway to escape quotes, possibly an encoding issue...

curl -k -w Response:%{http_code}\\\n -s http://${node.hostname}/

Thanks

k

[Moses Lei]

Oh, I see-- you're using the Local Commands step plugin, is that right? I believe that's a pretty new plugin and it's definitely possible there are some bugs in it in terms of quoting/escaping. Can you formulate some test cases in which case it doesn't work but it should, and put them in a tracker item on github? RunDeck being a java app has different notions of quoting (generally approaching "none") than shell. This is the same reason we have both "command" and "script"...

I think the script-based node step might be your best bet. It executes on the server side and gets the correct information, and you can put whatever script you need in there.

Moses

--

Moses Lei

Principal, Village Chime LLC

mobile: +1 703 901 5969 | skype: moseslei | yahoo: moseslei

[kcd]

Yes that is right, I find the Local Command concept more intuitive for the user than a job that takes an option that just happens to be a node. However from the point of view of writing the job it is backwards. 

As far as I know there is no "Local Script" step which would alleviate the escaping issue. The script-based node step copies the script to the target node and executes it there, not on localhost, so that doesn't work either.

I've opened an issue about Local Command escaping - https://github.com/dtolabs/rundeck/issues/395

Cheers

k

[kcd]

Of course calling a local script from the LocalCommand would work... which is probably what you meant