From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lemmer Webber Subject: Re: building "guix deploy" Date: Mon, 11 Mar 2019 10:41:52 -0400 Message-ID: <87zhq1mq1b.fsf@dustycloud.org> References: <87k2wx6t1e.fsf@fsf.org> <87h8da5u5k.fsf@dustycloud.org> <87h8ca1v92.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:35217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3MNt-0005qI-Ef for guix-devel@gnu.org; Mon, 11 Mar 2019 10:58:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3M7n-0002nd-Ts for guix-devel@gnu.org; Mon, 11 Mar 2019 10:41:57 -0400 In-reply-to: <87h8ca1v92.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel Ludovic Court=C3=A8s writes: > Hi there! Hi Ludo! Thanks for your reply. > "Thompson, David" 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: #> 541a220> >> Backtrace: >> 10 (apply-smob/1 #) >> In ice-9/boot-9.scm: >> 705:2 9 (call-with-prompt _ _ #) >> In ice-9/eval.scm: >> 619:8 8 (_ #(#(#))) >> 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 # =E2=80=A6) >> In guix/scripts/deploy.scm: >> 74:20 4 (_ _) >> In gnu/machine.scm: >> 58:22 3 (_ _ _ _) >> In guix/ssh.scm: >> 313:4 2 (send-files # _ _ # _ # = =E2=80=A6) >> In guix/store.scm: >> 1504:7 1 (export-paths # _ # =E2=80=A6) >> In unknown file: >> 0 (put-bytevector # =E2= =80=A6) >> >> ERROR: In procedure put-bytevector: >> Throw to key `guile-ssh-error' with args `("write_to_channel_port" >> "Remote channel is closed" # >> #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 =E2=80=98guix=E2=80=99 and =E2=80=98guile=E2=80=99 in $PATH on t= he remote machine, for > non-interactive shells? > > 2. Is =E2=80=98guix repl=E2=80=99 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 =E2=80=98guix copy=E2=80=99 fail similarly when sending files = to that host? It seems it does: cwebber@jasmine:~/devel/librelounge-audio$ guix copy --to=3Dtest.activitypu= b.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] Rem= ote channel is closed: # Backtrace: 11 (primitive-load "/home/cwebber/.config/guix/current/bin=E2=80= =A6") In guix/ui.scm: 1654:12 10 (run-guix-command _ . _) In ice-9/boot-9.scm: 829:9 9 (catch _ _ # =E2=80=A6) 829:9 8 (catch _ _ # =E2=80=A6) 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 # _ _ # _ # =E2= =80=A6) In guix/store.scm: 1505:12 4 (export-paths # _ # =E2=80=A6) 1485:22 3 (export-path # _ # =E2=80=A6) 683:13 2 (process-stderr _ _) 646:10 1 (dump-port # # =E2=80=A6) In unknown file: 0 (put-bytevector # =E2=80= =A6) ERROR: In procedure put-bytevector: Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote = channel is closed" # #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 =E2=80=98guix system reconfigure --host=3Dhost.example= .org=E2=80=99. > To do that, I thought about the following plan: > > 1. Isolate the effectful part of reconfigure (basically > =E2=80=98switch-to-system=E2=80=99). > > 2. Implement =E2=80=98remote-eval=E2=80=99, which takes a gexp and an S= SH session and > evaluates the expression remotely, copying the gexp inputs as > needed. > > 3. Have =E2=80=98reconfigure=E2=80=99 use either =E2=80=98eval=E2=80=99= or =E2=80=98remote-eval=E2=80=99 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 =E2=80=9Con the build side.=E2=80=9D In particular, I = think we=E2=80=99ll > have to change (guix graph), used by =E2=80=98upgrade-shepherd-services= =E2=80=99, so > that it no longer depends on =E2=80=98%store-monad=E2=80=99. > > That said, it=E2=80=99s probably a good idea to take a shorter path in the > meantime to unlock progress on =E2=80=98guix deploy=E2=80=99! > >> 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=E2=80=99. 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.