Hi there!
"Thompson, David" <dthomps...@worcester.edu> skribis:
> Chris Webber and I spent the morning chatting about how we want to
> approach making "guix deploy" a reality and then started hacking on it
> in the afternoon. Although we weren't able to complete a working
> prototype by the end of the day, we were able to get pretty close. We
> created a 'guix deploy' CLI to build derivations for any number of
> remote systems on a local workstation and initiate the transfer to the
> remote systems, but we encountered a difficult to debug SSH error that
> blocked our progress:
>
> sending 85 store items (0 MiB) to 'test.activitypub.rocks'...
> exporting path
> `/gnu/store/ylcdmrj3vf00ixdcjvkl3mbs8f5i9w8l-git-minimal-2.20.1.drv'
> ;;; [2019/03/09 17:32:48.792589, 0] write_to_channel_port: [GSSH
> ERROR] Remote channel is closed: #<input-output: channel (open)
> 541a220>
> Backtrace:
> 10 (apply-smob/1 #<catch-closure a26900>)
> In ice-9/boot-9.scm:
> 705:2 9 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
> In ice-9/eval.scm:
> 619:8 8 (_ #(#(#<directory (guile-user) ab1140>)))
> In guix/ui.scm:
> 1654:12 7 (run-guix-command _ . _)
> In guix/scripts/deploy.scm:
> 72:8 6 (guix-deploy . _)
> In srfi/srfi-1.scm:
> 640:9 5 (for-each #<procedure 4e5c940 at guix/scripts/deploy.s…> …)
> In guix/scripts/deploy.scm:
> 74:20 4 (_ _)
> In gnu/machine.scm:
> 58:22 3 (_ _ _ _)
> In guix/ssh.scm:
> 313:4 2 (send-files #<store-connection 256.99 48000f0> _ _ # _ # …)
> In guix/store.scm:
> 1504:7 1 (export-paths #<store-connection 256.99 48000f0> _ #<i…> …)
> In unknown file:
> 0 (put-bytevector #<input-output: channel (open) 541a220> …)
>
> ERROR: In procedure put-bytevector:
> Throw to key `guile-ssh-error' with args `("write_to_channel_port"
> "Remote channel is closed" #<input-output: channel (open) 541a220>
> #f)'.
>
> If anyone knows what might be going on here and how we could resolve
> it, your input would be much appreciated! We verified via the sshd
> logs that we were indeed successfully establishing a connection.
Error reporting in (guix ssh) is, ahem, not as good as it could be.
Apparently the SSH channel was closed prematurely, which could be due to
a number of things:
1. Are ‘guix’ and ‘guile’ in $PATH on the remote machine, for
non-interactive shells?
2. Is ‘guix repl’ available in the remote machine?
You can test this with:
ssh HOST guile --version
ssh HOST guix repl --version
Also, does ‘guix copy’ fail similarly when sending files to that host?
> Once we're past this blocking issue and are able to transfer OS
> closures to remote systems, we plan to write a modified version of
> switch-to-system that uses guile-ssh to switch remote symlinks for the
> active system and run the activation script. We'll save
> upgrade-shepherd-services for later, as it is quite a bit more
> complex.
My plan is to have ‘guix system reconfigure --host=host.example.org’.
To do that, I thought about the following plan:
1. Isolate the effectful part of reconfigure (basically
‘switch-to-system’).
2. Implement ‘remote-eval’, which takes a gexp and an SSH session and
evaluates the expression remotely, copying the gexp inputs as
needed.
3. Have ‘reconfigure’ use either ‘eval’ or ‘remote-eval’ to evaluate
the effectful bits of reconfigure.
#1 is a bit annoying because we need to untangle code so that we can
easily put it all “on the build side.” In particular, I think we’ll
have to change (guix graph), used by ‘upgrade-shepherd-services’, so
that it no longer depends on ‘%store-monad’.
That said, it’s probably a good idea to take a shorter path in the
meantime to unlock progress on ‘guix deploy’!
> There's not a lot of code yet, but you can check it out in the
> wip-deploy2 branch. Currently, the only supported use-case is running
> the equivalent of 'guix system reconfigure' on machines already
> running GuixSD that have an OpenSSH daemon running, but the basic
> design allows for additional use-cases to be supported in the future.
Yay!
Thank you gentlefolks for resuming work on this!
Ludo’.
