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.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4511 invoked from network); 2 Nov 2022 20:24:59 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 2 Nov 2022 20:24:59 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Nov 2 16:23:06 -0400 2022 Received: from abbatoir (pool-108-27-53-161.nycmny.fios.verizon.net [108.27.53.161]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 6bf734fb (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Wed, 2 Nov 2022 13:23:05 -0700 (PDT) Message-ID: <79E17F00FA0C76BA833463939866386D@eigenstate.org> To: 9front@9front.org Date: Wed, 02 Nov 2022 16:23:03 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtualized immutable HTTP element callback realtime backend Subject: Re: [9front] Two file servers sharing an auth server Reply-To: 9front@9front.org Precedence: bulk Quoth Nathan Zimmen-Myers : > As ori mentioned in IRC, keyfs is used to maintain the authentication > database which can be queried remotely (I believe? this might not be a > correct interpretation), is it correct to simply mount keyfs on web1 > from fs1? No; I thought you wanted to move or replicate the users between the auth servers. > The other option which comes to mind, is to boot web1 from fs1, and > use web1's disk for documents to be connected to httpd, which may make > long-term maintenance easier. Would this be a more common > configuration? Just give them the same auth server: sys=foo ether=aabbccddeeff ip=1.2.3.4 auth=1.2.3.4 sys=bar ether=aabbccddeeff ip=2.4.6.8 auth=1.2.3.4 even better if you can share an fs, and therefore share the ndb, but you don't need to; just point at the auth server you want to use. you don't even need to *own* that auth server, though you'll need the owner of the auth server to add a speaksfor line if your hostowner is different.