2

What we would like to do:

We have short living virtual machines for running scripts. The virtual machines are used through SSH to perform "builds" (sequence of scripts) and discarded once all the scripts finish. Every script runs through a new SSH connection/session.

This works really well for almost all of the scenarios we have, except two major use cases:

  1. when the script have to control the iOS Simulator installed on the virtual machine (this is the primary use case we want to solve at the moment) - technical note: the iOS Simulator can only be properly controlled from a GUI context, right now we use a special Go based mini server (https://github.com/bitrise-io/xcodebuild-unittest-miniserver) which is started as a Launch Agent when the user signs in and so it has the user's GUI context
  2. to maintain access to OS X keychain (through SSH the OS X keychains can be opened and managed but the keychain locks once the SSH session is closed)

Both of these issues could be solved if we could somehow start an agent inside the virtual machine and later we could connect to that specific daemon/agent, send the commands we want to run to the daemon/agent, and have the daemon/agent perform it. A requirement is to have a stream of the output of the actual scripts/commands which run inside the virtual machine.

What we do right now is to perform the scripts/commands through a simple SSH command like ssh ssh-params 'bash -l -c "echo \"hello world\""'. Of course this is a seriously simplified example but it's close to what we have right now, and with this we can get the output of the command as a stream to fulfill the logging requirement and additionally we can get the command's exit code.

So what we would like to do is something similar in terms that the command is specified "from outside" of the virtual machine but executed inside the virtual machine and the output of the command is available for the "outside" (caller) process as a stream, not just after the script finishes, as well as the command's exit code can be retrieved easily by the "outside" process.

In terms of tools we're quite open (we don't have to depend on SSH, that's just how it works at the moment) but the tool should be available for OS X and if possible for Linux (although in this case OS X is the priority, as both of the problematic use cases are related to OS X).

TL;DR; we would like a tool which can be used similarly to the above mentioned SSH command but it can connect to an agent/daemon which is already running at the remote (virtual machine) end, and the output generated by the specified "remote command" should be available for the caller process as a stream, not just at the end of the command. In addition to collecting the remote command's outputs we also have to be able to get it's exit code.

Final words: we ultimately decided to create our own solution because we couldn't figure out an easier way. You can find it on GitHub: https://github.com/bitrise-io/cmd-bridge - it supports all the required things I described and additionally it has command environment variable handling support (to define environment variables just for that remote command).

  • You're probably looking for something like tmux or screen if you're wanting to connect to an already-running console session. – Bratchley Apr 15 '15 at 15:49
  • @Bratchley We tried but could not figure out a way to collect the logs in a similar way we do with SSH. Could you show an example call which works similarly in terms of log output? – Viktor Benei Apr 15 '15 at 15:59
  • What were the problems you were running into? – Bratchley Apr 15 '15 at 16:03
  • Mainly: to run the command and get it's output right in the caller process, and to collect the command's exit code as well. Additionally the remote should not terminate the screen/window in case a script fails because the scripts are expected to return with non zero exit code. – Viktor Benei Apr 15 '15 at 16:30
  • Neither of these should be true of tmux. As long as you're not telling tmux to run the script itself, it should survive the end of the script's execution. You might try feeding your script to bash using the --rcfile option. You may have to alter the script so that it sources the user's ~/.bashrc as the first thing if need be. – Bratchley Apr 15 '15 at 16:36
3

Could you just run your commands in a screen or tmux session in the VM? That would allow multiple steps to connect/send commands to the same session

  • We tried but could not figure out a way to collect the logs in a similar way we do with SSH. Could you show an example call which works similarly in terms of log output? – Viktor Benei Apr 15 '15 at 15:53
  • how about tee-ing the output of the commands to a file so that you can see on the screen and later collect from the session? – LhasaDad Apr 15 '15 at 16:19
  • @lhasadad We would preferably collect the logs through the caller process and also collect the command's exit code there because both have to be transferred to a server. Do you know an example we could use? – Viktor Benei Apr 15 '15 at 16:27
  • When you're talking about collecting logs, do you mean getting the output of stdout? If so I think lhasadad was probably on the right track. If you have the commands teeing their output, you could have another ssh session that is watching that file in "real time." If it's writing to a real log file you could have an ssh session tail-ing that file the whole time. If those won't work I'll need a bit more info about why they aren't meeting the need in order to help find a better answer – Eric Renouf Apr 15 '15 at 18:38
  • I'll also point at STAF (staf.sourceforge.net) as an option for managed remote command execution. I have used it for things like what your trying to do. just a thought. – LhasaDad Apr 15 '15 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.