From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 2PKPGLEuJ2ZtVQEAe85BDQ:P1 (envelope-from ) for ; Tue, 23 Apr 2024 05:44:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 2PKPGLEuJ2ZtVQEAe85BDQ (envelope-from ) for ; Tue, 23 Apr 2024 05:44:49 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=gUn22cTd; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1713843889; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=int6XIENawPA3n8E8O3ptBJu4245TP0o5IgMtKj2wsE=; b=UknyllBhY+7jll6gjzm0Wd+EM5/9BOiwWqP/bL7rXPC5Kw/xX3JMJRK8RAK2jLZ2KuK50w 6FhNDzqjvnF+nRksT5vcNwRvCBVKHwiaPEL7eunX7Pvdpszfd2D/ZL7v4vTrsdZfh+C4YI +YGT2OTC5F6vFZU3XUWwN3Vrsv//YAYgA29lAMl1/0baX3xzwoPC6zmdVCMlrmERL3e1nJ WTGEjTTmbybBXJI7m16PJecV96eUP3AxVJG918noHJEGeWJvg+YcqYLbJwOExJ8WCojvzP d9l9owI9JK1cTMoiJ0F5ONHtON1QCrBRVDwIRCwkygjEsj6mi0uC8NaPGlKzgw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=gUn22cTd; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1713843889; a=rsa-sha256; cv=none; b=UPVq1lce4+7MfR6X3nKziZ9a0CJuFs57uxiq/1mt7/6gRJU0BtPaRr6uSC0ATvCI+EL/Dt Ji7M6cJng/g1MUZf3ji/pW+qZ85jrZss3oL6p7/K86pG2LJoeniDfpf2bouJi8Q/wXIkdz /lCu5jjrEZNetM5mErxbB/x5gBj9f5A7+J11blZUoz8kp86X2pofFA4ZJD0dl0AIakiL1m t6l818zRGnBNfwW3qZLz7JETwgyaTmko5a+L1NV4+p4pCmbkqw9lf1hyGU8gw0ClihK+kn v7vXN5LbnKdl7p+hSmklXWPEsuurd1uk7AYXlKvZkL5SBeeV9iMhZ9I+hRUC7g== 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 B206672F3C for ; Tue, 23 Apr 2024 05:44:48 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rz74n-0007no-15; Mon, 22 Apr 2024 23:44:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rz74l-0007nU-Cj for guix-devel@gnu.org; Mon, 22 Apr 2024 23:44:11 -0400 Received: from mail-108-mta153.mxroute.com ([136.175.108.153]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rz74i-0007nd-S5 for guix-devel@gnu.org; Mon, 22 Apr 2024 23:44:11 -0400 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta153.mxroute.com (ZoneMTA) with ESMTPSA id 18f090db50e0003bea.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 23 Apr 2024 03:44:04 +0000 X-Zone-Loop: 3148d536212444b9c2a7f4bc25f12157bcc6ac000cdf X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freakingpenguin.com; s=x; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=int6XIENawPA3n8E8O3ptBJu4245TP0o5IgMtKj2wsE=; b=gUn22cTdYFm1uqo+T2gsi49GRv EamRCfQkrimOOA7sJnWXRULYSVbWSwMqSG9WthWWcJA4RJ6fp7iXwdczhUyIeCUtsxJjvyfTf+krd 5TBNd1U8OI7TJZJae/WPerE8qliTJrgdwVHae7w93zWsUFh4apaLQnl0JEc7Gxyg5IXI/VbZvSpaS MJXEAG4KniW237NFgSQvchB1DaLhqCtZwKOm787+oLfMy+JsFnWBI1VJaC+33qYNyAOKJmHnwOdcq QOTPtR+wUsPkzsVNcQaqjOmopn2TSG63TDlJU7uLLNUtyi/+kjUd/Iyd02/uNjSpIuvk5hUzHz1Tg 2VbKgPSg==; From: Richard Sent To: guix-devel@gnu.org Subject: Value in adding Shepherd requirements to file-systems entries? Date: Mon, 22 Apr 2024 23:43:49 -0400 Message-ID: <87le54hhfu.fsf@freakingpenguin.com> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: richard@freakingpenguin.com Received-SPF: pass client-ip=136.175.108.153; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta153.mxroute.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -5.38 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -5.38 X-Migadu-Queue-Id: B206672F3C X-TUID: 3k8bK6YPCHUU Hi Guix! I wanted to ask the Guix community for their thoughts on improving the support for adding networked file systems to an operating-system declaration. For some context, I started tackling adding CIFS support to file-system declarations, but I've hit a snag. CIFS is a networked file system, but Guix mounts all file systems specified in (operating-system-file-systems) either when booting the system from the initrd or as shepherd services after boot that depend on 'root-file-system and 'udev. Either way, these run before any networking service has been initialized. Ergo, a samba share like //192.168.1.102/share won't be found. (At least, not on a wireless network. Perhaps the timing is different for wired ones.) Obviously, adding shepherd requirements to needed-at-boot? file systems isn't possible. However, I think it should be possible to add shepherd services to other file system entries. (And yet, NFS is allegedly supported, although I can't figure out the mechanism for that and don't have one set up on my LAN for testing.) Before hacking away at this myself, I'd like to get other people's thoughts on the best way to proceed. Do others agree that (file-system) entries should support networked devices? Should this be transparent depending on the type, or require explicit configuration? e.g. --8<---------------cut here---------------start------------->8--- (file-system (device "//192.168.1.102/share") (options "guest") (mount-point "/mnt/share") (type "cifs") ;; Should we explicitly require network, or implicitly add it from ;; the type? If the latter, what to do about Avahi? (requirement 'networking) (mount-may-fail? #t) (create-mount-point? #t)) --8<---------------cut here---------------end--------------->8--- I could see this being challenging since it's not immediately clear to me what particular file-system-* service, if any, is provisioning 'file-systems, which other shepherd requirements the user may specify can depend on. I imagine adding a requirement to the wrong file-system could easily cause a deadlock. I know a custom shepherd service could be used to run, say, mount.cifs from userspace after networking is provisioned, but in my opinion it would be cleaner to encapsulate within the existing file-system block of the operating system. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.