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=1.3 required=5.0 tests=DATE_IN_PAST_06_12, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 29319 invoked from network); 3 Nov 2022 08:33:30 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 3 Nov 2022 08:33:30 -0000 Received: from mail-il1-f173.google.com ([209.85.166.173]) by 9front; Thu Nov 3 04:30:45 -0400 2022 Received: by mail-il1-f173.google.com with SMTP id s9so712511ilu.1 for <9front@9front.org>; Thu, 03 Nov 2022 01:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nzm-ca.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=isohAZqwQRv9sR7VrB0BZns6NQp2NdoOfEbOf63RFTU=; b=1M+srptl4KW//ViD3qA5jWbKmBOpXYWqAR9aqdRhGRSH3mCxm/cfN7YMS11fzCBH2A JdX7ax8v81rhpuPzBSOPqSBUIsX4pDNgbdNmcfLbdq9UEPoI0mfBvUQeIW/Nacz+UiwJ fRp5w3M/7WCB/WRnvLpLQEeeoMXGrXOIclslsXzScVZSnDxLLvVsUOS4TewSi65dwkN9 EXpMmNETk8GU6V9rB4Jk394Aqwiga8PF/iK93tfYBJbxBuNh40bwZUckWt4Ali/zZWPd rSmF9JEzwOUSkmzVZGwMYY+p354w69LU1/IHAfhOcPMcwLpUp6WYD2uuDsxKEFqK9SuA TccQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=isohAZqwQRv9sR7VrB0BZns6NQp2NdoOfEbOf63RFTU=; b=Cd2vwkqPIU1UocGh973K7R5uHfM11AUEtXkMs+aKqpp/PG8PX0foBE+GxxerfNOdC2 yWabw8SN1RWWv8q7WnZ6amFDDNDq9FkJMON8aybv122tGqiEjJyt0VRY6CuSv9CM2mlW jLlWW4oMYx4KFDVqVeGFkgOBIPy7/LHs+qZR8IIv0n469RcCNrXvREYuo+vwbhgLkJ1Y forH5OfXrdbJwaUqIWhgoPRZXywFAmbH/n4Dp2V7XGxm0XIr1+baNnnaLKLC/DxCjbL5 bIVv6MSJdzsM887cLyJF+KUVGVzjVIRUY+nXzmA/Z8Meen/J8xkW4J9mXSdmRGISFtRq tNNQ== X-Gm-Message-State: ACrzQf1Fu5wAG+Dwjm05jS50Ejn5Rq7BVSheSNkoQBB8qF4uWw4NNoV6 Uv3JNLS88GSrYIiamOV4jYunRf6+3sQX63u9zP2GsI35yfk= X-Google-Smtp-Source: AMsMyM6AB2XaWaKlJdNgDwKUNlEycfZZ/NmWBz3M2oIB65EAEMSbLkWNME0G7dRGxgAT84QixkyUdsLEts7EYr3lfwY= X-Received: by 2002:a63:d60b:0:b0:46f:8e44:9ce4 with SMTP id q11-20020a63d60b000000b0046f8e449ce4mr20783616pgg.308.1667436239394; Wed, 02 Nov 2022 17:43:59 -0700 (PDT) MIME-Version: 1.0 References: <79E17F00FA0C76BA833463939866386D@eigenstate.org> In-Reply-To: From: Nathan Zimmen-Myers Date: Wed, 2 Nov 2022 20:43:48 -0400 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: shared stable interface reduce/map control Subject: Re: [9front] Two file servers sharing an auth server Reply-To: 9front@9front.org Precedence: bulk William'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. As per Ori's response, I think I misunderstood a piece of the documentation and didn't tab the auth=ip on web1 or fs1, which explains some of the confusing error messages. 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. On Wed, Nov 2, 2022 at 7:56 PM wrote: > > On a bigger note. I was curious about the users. Its nice to have a single auth > as mentioned by ori. But what's the bigger goal. Do you plan to have a lot of users. > Do those users know basic unix commands to navigate around? What type of files > or media to you plan to serve? > > > 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? > > > > 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. > > > > >