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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3804 invoked from network); 3 Nov 2022 09:30:31 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 3 Nov 2022 09:30:31 -0000 Received: from mx2.mythic-beasts.com ([46.235.227.24]) by 9front; Thu Nov 3 05:28:58 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=quintile.net; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=XnpVX37J1FFDwv2UY0tE5ZzegdXgfZLK9CDVB1xQ1tQ=; b=Bb57kpZt6Col6qEqLptiG6JsOu DcVXkdUznrhjKV8aSjwbTORzrMziLfKFVcYdMqcwkh1UkWZm4IYxa1/pXtcz1EX55ShNojH+Qq04s xerdmBC8ezCD5PGFS5a2bJxOhVrI18NbMI/zTjrP2JCOtKN72ZgJOX7r4uXh8AB0PL7yXq/wZs83F qPQePbCupkG/IgKWoe0/iuS6KqNJ+4cH9mhi+9WnEdjY7VvmAUJq5sKN75MlbdV7VsOdu1SMVTXQ0 nAKeWm4fJKlHiD1VjkW3BmSsKHBjSBz/gEaT2aJegezYDBmzhdoFC6q+g2zcVenX6fSLYMkeoABF/ 5x+VWqXQ==; Received: from [81.187.198.132] (port=49473 helo=smtpclient.apple) by mailhub-hex-d.mythic-beasts.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oqWWu-006hUt-N8 for 9front@9front.org; Thu, 03 Nov 2022 09:28:57 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Steve Simon Mime-Version: 1.0 (1.0) Date: Thu, 3 Nov 2022 09:28:44 +0000 Message-Id: References: In-Reply-To: To: 9front@9front.org X-Mailer: iPhone Mail (20A392) X-BlackCat-Spam-Score: 4 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: open open-source element high-performance factory map/reduce-based backend Subject: Re: [9front] Two file servers sharing an auth server Reply-To: 9front@9front.org Precedence: bulk having the web server boot diskless is very nice, if its content is small th= at is enough. for a little extra performance you can copy the web content to a ramfs at bo= ot. if the content is big you could mount a local spinning/ssd at boot onto /usr= /web and serve that, but having a diskless web and cpu servers makes things v= ery clean and easy to maintain. > On 3 Nov 2022, at 08:32, Nathan Zimmen-Myers wrote: >=20 > =EF=BB=BFWilliam's question is important, the reality is that I'm just > separating out which systems have access to what on their primary > fileservers. This is just personal infrastructure and trying to have > multiple accounts might just be a mental holdover from unix. All that > I'm doing now with web1 is serving my personal website, and fs1 will > eventually be used as a backend fs for "compute" nodes - temporary > cloud servers for running compilations and other cpu-heavy tasks. >=20 > As per Ori's response, I think I misunderstood a piece of the > documentation and didn't tab the auth=3Dip on web1 or fs1, which > explains some of the confusing error messages. >=20 > I think for now I'll just cache web files on web1's hard drive, with > web1 booting off of fs1. I don't see any reason why that would be too > slow, and while I'm still learning the system I want to cut down the > amount of work I do to keep configuration changes the same across both > systems. >=20 >> On Wed, Nov 2, 2022 at 7:56 PM wrote: >>=20 >> On a bigger note. I was curious about the users. Its nice to have a singl= e auth >> as mentioned by ori. But what's the bigger goal. Do you plan to have a lo= t of users. >> Do those users know basic unix commands to navigate around? What type of f= iles >> or media to you plan to serve? >>=20 >>=20 >> Quoth ori@eigenstate.org: >>> 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? >>>=20 >>> No; I thought you wanted to move or replicate the users between the >>> auth servers. >>>=20 >>>> 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? >>>=20 >>> Just give them the same auth server: >>>=20 >>> sys=3Dfoo ether=3Daabbccddeeff ip=3D1.2.3.4 >>> auth=3D1.2.3.4 >>>=20 >>> sys=3Dbar ether=3Daabbccddeeff ip=3D2.4.6.8 >>> auth=3D1.2.3.4 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>=20