From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 30076 invoked from network); 29 Mar 2023 17:48:42 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2023 17:48:42 -0000 Received: from pb-smtp21.pobox.com ([173.228.157.53]) by 9front; Wed Mar 29 13:45:42 -0400 2023 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 40CFB1EA24F for <9front@9front.org>; Wed, 29 Mar 2023 13:45:38 -0400 (EDT) (envelope-from unobe@cpan.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id :to:from:subject:date:mime-version:content-type :content-transfer-encoding; s=sasl; bh=DELNxSvmv/QFkCERFLXovrXP2 AX0a0RWUsJj6b6565o=; b=g7/NwVSKKsDXqOLsXerc81HIxu9qZASmJckJ8sFXE xpdrnce+fg4XhqVXFAC6Njzpk5Pi3w0TfW9qur0hC8pwUA8n720xtveM4PkqY/EE P/ElDYBGqjYC+MQKksQaLSjjuvqJG9U5zxMQq/M5nSaXIxPqSsLEgSnnzKdiNI1D OU= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 3A1B31EA24E for <9front@9front.org>; Wed, 29 Mar 2023 13:45:38 -0400 (EDT) (envelope-from unobe@cpan.org) Received: from strider.localdomain (unknown [75.204.169.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 045E91EA24C for <9front@9front.org>; Wed, 29 Mar 2023 13:45:34 -0400 (EDT) (envelope-from unobe@cpan.org) Message-ID: <33F010865FC9B2A02D0352D79A362A33@smtp.pobox.com> To: 9front@9front.org From: unobe@cpan.org Date: Wed, 29 Mar 2023 10:45:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 82403B2C-CE59-11ED-AEB2-B31D44D1D7AA-09620299!pb-smtp21.pobox.com List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: table GPU firewall pipelining controller Subject: [9front] srv(3) clone and srvid Reply-To: 9front@9front.org Precedence: bulk I'm trying to run ndb/dns in a separate namespace so that I can use it to forward requests (in the namespace) to another DNS server. Recently, ndb/dns was updated to use /srv instead of '#s', which is necessary to keep it separate from the primary devsrv. srv(3) states I can clone /srv and access that in two ways, via /srv/id or directly using srvspec: bind -c #s$srvspec /srv /srv/clone /srv/id/... /srv/service1 /srv/service2 The functionality is explained near the end of the man page: Opening the clone file allocates a new service directory. Reading clone returns the id of the new directory. This new service directory can then be accessed at /srv/id. Directo- ries are recursive; each new service directory contains its own clone file and sub-directories. Directories can be walked from the root such as #s/id1/id2/id3 which makes them globally addressable. As a convention, /lib/namespace accepts the path to the service directory from the environ- ment variable $srvspec, making it possible to start a new namespace using a specific service directory as a starting point. If I do: cpu% cat /srv/clone 15cpu% I get a new id. I expected to be able to go to the clone using /srv/15, but that is not available: cpu% lc /srv/15 ls: /srv/15: '/srv/15' file does not exist I can, however, specify the srvspec to (supposedly) bind to a new service directtory: cpu% srvspec=`{cat /srv/clone} bind -c '#s'^$srvspec /srv cpu% Yet I would have expected this cloned service directory to be disassociated from its parents so that manipulating it would not affect the parent. Right now, that is not the case. If I rm /srv/dns', after cloning the service directory, it is reflected across all namespaces. Is this a feature that hasn't been implemented? Am I misunderstanding how it's meant to work?