Re:RPC (remote procedure calls) in BASH over SSH
by derekp7 on Tuesday October 22, 2019 @10:38PM
(#21330554)
In normal automation, Ansible (or similar) may be prefered. However this is for use cases where your app runs across multiple hosts, and some functions need to be done on the other host.
An example is if you have something inside a KVM instance or a docker container, and you need to ssh outside of it when it boots up (or a service starts) to play with IPtables settings on the base server.
For most cases, you would use a higher level language, that has clean remote procedure execution (in modern terms, doing "curl" to a remote node.js served API). This however is when you have a need to do everything in BASH scripts.
Re:RPC (remote procedure calls) in BASH over SSH
by derekp7 on Tuesday October 22, 2019 @10:33PM
(#21330526)
Can you elaborate? The only '>>' notation I'm familiar with is to append to a file.
The purpose of this technique is if you have a script running on, say, a master host, has a bunch of functions, but has a couple functions that need to run somewhere else (like a backup script that needs to put a remote database server in hot backup mode). You can either write the remote commands to a file, sync it to the remote host (somewhere), then execute it. Or, use this technique to pass the function "live" to the remote environment and run it unmodified.
I personally use it in the front-end client script (snebu-client) for the Snebu backup system.
Re:RPC (remote procedure calls) in BASH over SSH
by derekp7 on Tuesday October 22, 2019 @11:55PM
(#21330910)
Ah, hear documents -- had the arrows pointing the other way. The problem is that you still have to worry about escaping some special characters, such as the dollar sign.
Whereas by using the "declare" syntax, or the attached script in the gist, you can send a number of inter-dependent functions without escaping anything in them (treat them as if they are local), along with the additional complexity you can encapsulate into regular structured programming syntax.
Per POSIX, "If any part of word is quoted, the delimiter shall be formed by performing quote removal on word, and the here-document lines shall not be expanded. Otherwise, the delimiter shall be the word itself." "If no part of word is quoted, all lines of the here-document shall be expanded for parameter expansion, command substitution, and arithmetic expansion."
An example is if you have something inside a KVM instance or a docker container, and you need to ssh outside of it when it boots up (or a service starts) to play with IPtables settings on the base server.
For most cases, you would use a higher level language, that has clean remote procedure execution (in modern terms, doing "curl" to a remote node.js served API). This however is when you have a need to do everything in BASH scripts.
The purpose of this technique is if you have a script running on, say, a master host, has a bunch of functions, but has a couple functions that need to run somewhere else (like a backup script that needs to put a remote database server in hot backup mode). You can either write the remote commands to a file, sync it to the remote host (somewhere), then execute it. Or, use this technique to pass the function "live" to the remote environment and run it unmodified.
I personally use it in the front-end client script (snebu-client) for the Snebu backup system.
Whereas by using the "declare" syntax, or the attached script in the gist, you can send a number of inter-dependent functions without escaping anything in them (treat them as if they are local), along with the additional complexity you can encapsulate into regular structured programming syntax.