unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Lemmer Webber <cwebber@dustycloud.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: building "guix deploy"
Date: Mon, 11 Mar 2019 10:41:52 -0400	[thread overview]
Message-ID: <87zhq1mq1b.fsf@dustycloud.org> (raw)
In-Reply-To: <87h8ca1v92.fsf@gnu.org>

Ludovic Courtès writes:

> Hi there!

Hi Ludo!  Thanks for your reply.

> "Thompson, David" <dthompson2@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

Yep, both respond with
  guile (GNU Guile) 2.2.4
and
  guix (GNU Guix) 0.16.0-10.2637cfd
respectively.

> Also, does ‘guix copy’ fail similarly when sending files to that host?

It seems it does:

cwebber@jasmine:~/devel/librelounge-audio$ guix copy --to=test.activitypub.rocks pidgin
guile: warning: failed to install locale
sending 37 store items (336 MiB) to 'test.activitypub.rocks'...
;;; [2019/03/11 10:39:25.573104, 0] write_to_channel_port: [GSSH ERROR] Remote channel is closed: #<input-output: channel (open) 46f5e60>
Backtrace:
          11 (primitive-load "/home/cwebber/.config/guix/current/bin…")
In guix/ui.scm:
  1654:12 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9  9 (catch _ _ #<procedure 7fca74f959b8 at guix/ui.scm:624…> …)
    829:9  8 (catch _ _ #<procedure 7fca74f959d0 at guix/ui.scm:750…> …)
In guix/status.scm:
    810:4  7 (call-with-status-report _ _)
In guix/scripts/copy.scm:
    81:27  6 (send-to-remote-host _ _)
In guix/ssh.scm:
    313:4  5 (send-files #<store-connection 256.97 27a5eb0> _ _ # _ # …)
In guix/store.scm:
  1505:12  4 (export-paths #<store-connection 256.97 27a5eb0> _ #<i…> …)
  1485:22  3 (export-path #<store-connection 256.97 27a5eb0> _ #<in…> …)
   683:13  2 (process-stderr _ _)
   646:10  1 (dump-port #<input-output: socket 14> #<input-output: …> …)
In unknown file:
           0 (put-bytevector #<input-output: channel (open) 46f5e60> …)

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) 46f5e60> #f)'.

I wonder what got screwed up!

>> 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.

This sounds like the right approach to me.

> #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’.

Thank you for your response!

By the way, since the problem somehow seems to be a problem with my
server and ssh + guile-ssh (!!!) I wonder if someone else has a server
set up they'd be brave enough to try the above branch with?  It appears
that the problem is not Dave's code, given that "guix copy" also fails.

  reply	other threads:[~2019-03-11 14:58 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 23:38 Guix "ops" David Thompson
2015-04-30 15:25 ` Ludovic Courtès
2015-04-30 16:53   ` David Thompson
2015-05-01 14:48     ` Ludovic Courtès
2015-05-04 23:51       ` Carlos Sosa
2015-05-05  2:00         ` David Thompson
2015-05-05  7:57           ` Ludovic Courtès
2015-05-07  3:02             ` Christopher Allan Webber
2015-05-22 14:59         ` David Thompson
2015-05-22 16:06           ` Ludovic Courtès
2015-05-22 16:24             ` David Thompson
2015-05-27 18:47               ` Carlos Sosa
2015-05-28 16:10                 ` Thompson, David
2015-05-27 19:41               ` Ludovic Courtès
2015-05-28 16:13                 ` Thompson, David
2015-07-09 18:27               ` OpenStack and GuixOps (was: Re: Guix "ops") Christopher Allan Webber
2015-07-10  2:18                 ` Ian Denhardt
2015-07-10 17:24                 ` OpenStack and GuixOps Ludovic Courtès
2015-06-01 15:18           ` Guix "ops" Pjotr Prins
2015-06-01 16:49             ` Thompson, David
2015-06-01 19:35               ` Guix deploy (and replace Puppet/Chef) Pjotr Prins
2015-07-10 16:37           ` Guix "ops" Christopher Allan Webber
2016-10-16 23:36           ` Christopher Allan Webber
2016-10-17 14:51             ` Ludovic Courtès
2016-10-19 21:10               ` Christopher Allan Webber
2016-10-20 13:29                 ` Ludovic Courtès
2016-10-20 17:01                   ` Christopher Allan Webber
2016-10-20 19:41                     ` Ludovic Courtès
2019-02-11 13:31 ` It's time to build "guix deploy" Christopher Lemmer Webber
2019-02-11 14:02   ` Pjotr Prins
2019-02-11 14:47     ` Christopher Lemmer Webber
2019-02-11 18:11       ` Amirouche Boubekki
2019-02-11 14:57     ` Christopher Lemmer Webber
2019-02-11 15:25       ` Pjotr Prins
2019-02-11 16:58   ` Thompson, David
2019-02-11 20:49     ` Ricardo Wurmus
2019-02-13 19:04       ` Giovanni Biscuolo
2019-02-14  7:14         ` swedebugia
2019-02-14  8:17           ` Pjotr Prins
2019-02-14 15:35             ` Giovanni Biscuolo
2019-02-14 16:55               ` Pjotr Prins
2019-02-14 14:17           ` Giovanni Biscuolo
2019-02-17  8:41             ` swedebugia
2019-02-17 15:42               ` Giovanni Biscuolo
2019-02-12 13:34     ` Christopher Lemmer Webber
2019-02-12 14:53       ` Thompson, David
2019-03-09 23:29   ` building " Thompson, David
2019-03-10 17:42     ` Ludovic Courtès
2019-03-11 14:41       ` Christopher Lemmer Webber [this message]
2019-03-12 13:08         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zhq1mq1b.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).