From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4PSpCPQXCl9wRQAA0tVLHw (envelope-from ) for ; Sat, 11 Jul 2020 19:50:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id +FiHBPQXCl9HSAAAB5/wlQ (envelope-from ) for ; Sat, 11 Jul 2020 19:50:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8196B940225 for ; Sat, 11 Jul 2020 19:50:11 +0000 (UTC) Received: from localhost ([::1]:58820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1juLVh-0002lh-Gl for larch@yhetil.org; Sat, 11 Jul 2020 15:50:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1juLVZ-0002lX-T8 for bug-guix@gnu.org; Sat, 11 Jul 2020 15:50:01 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33380) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1juLVZ-0007tE-Kd for bug-guix@gnu.org; Sat, 11 Jul 2020 15:50:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1juLVZ-0000sE-Iv for bug-guix@gnu.org; Sat, 11 Jul 2020 15:50:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#42252: Not possible to reliably port forward with "guix system vm" anymore Resent-From: Christopher Lemmer Webber Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 11 Jul 2020 19:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42252 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Bengt Richter Received: via spool by 42252-submit@debbugs.gnu.org id=B42252.15944969703313 (code B ref 42252); Sat, 11 Jul 2020 19:50:01 +0000 Received: (at 42252) by debbugs.gnu.org; 11 Jul 2020 19:49:30 +0000 Received: from localhost ([127.0.0.1]:44926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juLV4-0000rN-Ao for submit@debbugs.gnu.org; Sat, 11 Jul 2020 15:49:30 -0400 Received: from dustycloud.org ([50.116.34.160]:47072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juLV1-0000rC-5u for 42252@debbugs.gnu.org; Sat, 11 Jul 2020 15:49:28 -0400 Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 70EF326617; Sat, 11 Jul 2020 15:49:26 -0400 (EDT) References: <87r1tnf496.fsf@dustycloud.org> <20200708094628.GA9946@LionPure> User-agent: mu4e 1.4.9; emacs 26.3 From: Christopher Lemmer Webber In-reply-to: <20200708094628.GA9946@LionPure> Date: Sat, 11 Jul 2020 15:49:26 -0400 Message-ID: <87tuyd96ih.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 42252@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: TmsHHV8TDDrj [+ Cc: Marius Bakke] because I don't have enough info to respond fully myself. Bengt Richter writes: > Hi > > On +2020-07-07 16:40:21 -0400, Christopher Lemmer Webber wrote: >> In commit 5379392731b52eef22b4936637eb592b93e04318, the following change >> was introduced: >> >> modified gnu/system/vm.scm >> @@ -941,6 +941,7 @@ with '-virtfs' options for the host file systems listed in SHARED-FS." >> '()) >> >> "-no-reboot" >> + "-nic" "user,model=virtio-net-pci" >> "-object" "rng-random,filename=/dev/urandom,id=guixsd-vm-rng" >> "-device" "virtio-rng-pci,rng=guixsd-vm-rng" >> >> Unfortunately, this means that in our docs where we suggest doing the >> following: >> >> `guix system vm config.scm` -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 >> >> Since we now provide our own similar "-nic" field this creates a >> *second* network interface at the same address and there is a race as in >> terms of which handles connections. Depending on the race result, >> connections to the forwarded port may hang indefinitely. >> >> Ironically, this regression was introduced to solve another regression! >> From the commit message: >> >> This fixes a regression introduced in 8e53fe2b91d2776bc1529e7b34967c8f1d9edc32 >> where 'guix system vm' would no longer be using virtio. >> > > This reminds a bit of doctors prescribing powerful medicine with side-effect so bad > that they have to prescribe a medicine for that, which in turn has side-effects, > in what I think is called prescription cascading, and people wind up on 25 pills a day. > > "First, do no harm." :) Well, I'm definitely not actively trying to harm ;) > I wouldn't say anything, except ISTM your fix on top of a fix > is not the first to remind me of cascading :) > >> What's the right solution? One could be that "guix system vm" itself >> could take an argument that sets up port forwarding in the generated >> shell script. Eg: >> >> guix system vm config.scm --hostfwd=tcp::10022-:22 --hostfwd=tcp::8888-:80 >> >> kind of ugly, but it could work. WDYT? >> >> - Chris > > I'm not saying your solution is bad, I'm just saying cascading fixes may be a symptom > to diagnose, in case it indicates something like bad mutations involving bad genes > that will compromise the health of the guix ecology. > > How is a "fix" judged with respect to the big picture? You raise a point in that my "fix to a fix" was a solution when I don't fully understand the problem that was being fixed. Of course, this isn't uncommon in software development, but that doesn't make it great. I only understood as much context as I could to make my workaround to the problem. Is it the right long-term solution? I'm not sure, but I think Marius Bakke has more context to be able to reply than I do. What I do know is that the present instructions we have for port forwarding are now effectively broken, and this at least provides a way to get back there. It might not be the right one. For the rest of your email, I do think Guix is well layered... but even well layered systems sometimes have intermediate proposed solutions to bugs. Sometimes the right design is found along the way. But part of the goal of submitting such a patch is to get code review and provoke discussion of what the right thing is. I *did* make it clear that I thought it was ugly, but workable. :) It might not be the totally wrong thing either though... if there are enough modifications that users might make to the -nic flag, but we don't know how to nicely abstract over all of them yet, but for now we do need to supply a default, this can be an escape hatch at least for now. This wouldn't be uncommon; that's very similar to how Guix system configuration tends to go (we supply configuration builders for the most common options but sometimes provide a way to just slot in a manual config file when need be). - Chris