"Terminal Command" issues

Published 2 days ago

I would like to have the possibility to execute a rather lengthy shell skript on selected SSH Terminal connections on demand. Due to multiple reasons the usual anwser "just use ansible" is not usable here.

In general, I have this working using the "Terminal Command" type. I just have some special wishes that I just can't get to work

I cannot use "Custom Field" contents in the script. Is this really not possible, or am I missing something?
The string "{HOME}" is being replace by the "HOME"-key (carriage return). That's extremely unhelpful when using shell scripts, that are supposed to work for a multitude of different targets. (Not even discussing, what a headache the identification of this behaviour was, because I never new that this doesn't only happen for autotype makros)
What I really would like is a "copy the contents of a SHELL SCRIPT entry to a given filename and execute a number of shell commands afterwards" (move the file to one or more targets, depending on server-environment, change ownerships/permissions)

I've tried googling, reading documentation, experimented with a lot of different ideas, but I cannot work around (in the third case: implement) any of this points. I'm sure I've missed lot's of information, but I'm about to give up.

Does anyone have some hints what I might have missed?

Regards,
Jan

P.S.: My main target is RDM on Windows. Fun side-fact: A lot of the configuration options for this area of entry types seem to be (some more, some less) sublty different on MacOS, causing an interesting outlook if team-members using Apple devices need to use these entries.

All Comments (1)

janschnackenberg

Published 2 hours ago

Ok, I have a workaround that "works for me", even if it's not really what I would like to have.

I'm now encoding my script as BASE64 and do something like this:

base64 -d > /tmp/somefilename <<'SCRIPTROLLOUTEOT'
BASE64ENCODEDSCRIPT
SCRIPTROLLOUTEOT
chmod o+r /tmp/somefilename
# Code that copies the decoded script-file to all required destinations
rm -f /tmp/somefilename

What I would have liked to do was basically the same, but

without the extra steps to manually encode the script to BASE64 (and of course the decoding in this snippet)
Without the need to change the actual script code in the "Run"-field
- This introduces the risk of changing not only the line with the script code
- This in turn introduces the risk of destructive errors in the rollout-snippet each time the script content must be updated
- This issue could be prevented if the script content could just be put into CUSTOM_FIELD5 (for example), which is currently not possible because the custom field variables do not seem to be substituted when sending the "Run"-filed contents (even though the "{HOME}" string is replaced)