New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support deployment keys in the container backend #759

wants to merge 3 commits into
base: master


None yet
3 participants

johbo commented Nov 1, 2017

We did try to use the deployment keys in the container backend and found out that the following tweaks were needed.

With the change around run_command I am not really sure. The problem could also be worked around by changing the order of the shell commands like the following example shows:

johannes@dev-johbo: ~/wo/nixops work-johbo
$ a=b echo test; (echo test)

johannes@dev-johbo: ~/wo/nixops keys-container-backend
$ a=b (echo test); echo test
-bash: syntax error near unexpected token `('

The shell commands are constructed in the function send_keys:

Depending on the order does feel wrong as well though. I am not sure if we really need the HOME=/root fragment in run_command for the container backend.

johbo added some commits Nov 1, 2017

Set common state in container backend
Found out that keys were not send to the container because the call to
set_common_state was missing. This call transfers the values from the machine
definition into the machine state object.
Send keys on start in the container backend
Compared to other backends, the call to send_keys was missing. Did intentionally
keep the same style as in the other backends even though the call to wait for
ssh is basically a noop in the container case.
Make run_command more solid in the container backend
Noticed that the setting of "HOME=/root" in the beginning of the line leads to

    $ a=b (echo $a)
    bash: syntax error near unexpected token `('

    $ a=b; (echo $a)

This issue became visible after fixing up the functionality around sending the
keys to the container. The call starts with a subshell as in the example above.
@@ -104,7 +104,7 @@ def wait_for_ssh(self, check=False):
def run_command(self, command, **kwargs):
command = command.replace("'", r"'\''")
return self.host_ssh.run_command(
"nixos-container run {0} -- bash --login -c 'HOME=/root {1}'".format(self.vm_id, command),
"nixos-container run {0} -- bash --login -c 'HOME=/root; {1}'".format(self.vm_id, command),

This comment has been minimized.


kevincox Dec 8, 2017


Should it be export HOME=... if it is its own statement?


This comment has been minimized.


domenkozar commented Dec 9, 2017

@johbo now that #804 is merged, can you retest?


This comment has been minimized.


johbo commented Dec 27, 2017

Checked, #804 does the trick. There is a pending bit around the usage of nixops start when trying to start a container which needs deployment keys. This does seem to have a bigger issue though, since it typically would deadlock: nixos-container start waits until the container is up, which will never happen if the deployment keys are not yet in the container, so calling send_keys would have to be done in parallel to sneak the keys in so that the container can actually finish the startup...

For this PR we are done due to #804. I'll close this one.

@johbo johbo closed this Dec 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment