From: Nathan Zimmen-Myers <firstname.lastname@example.org>
Subject: Re: [9front] Two file servers sharing an auth server
Date: Wed, 2 Nov 2022 20:43:48 -0400 [thread overview]
Message-ID: <CABaXbEZEpJpbE2WOmbBsOzXkOFGuFEeqiGUTwZtM-NiJKn1y3A@mail.gmail.com> (raw)
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
On Wed, Nov 2, 2022 at 7:56 PM <email@example.com> 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 firstname.lastname@example.org:
> > Quoth Nathan Zimmen-Myers <email@example.com>:
> > > 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=18.104.22.168
> > auth=22.214.171.124
> > sys=bar ether=aabbccddeeff ip=126.96.36.199
> > auth=188.8.131.52
> > 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.
next prev parent reply other threads:[~2022-11-03 8:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-02 19:18 Nathan Zimmen-Myers
2022-11-02 20:23 ` ori
2022-11-02 23:53 ` william
2022-11-03 0:43 ` Nathan Zimmen-Myers [this message]
2022-11-03 9:28 ` Steve Simon
2022-11-03 10:33 ` sirjofri
2022-11-03 20:57 ` Steve Simon
2022-11-04 0:00 ` william
2022-11-04 6:58 ` sirjofri
2022-11-04 7:09 ` william
2022-11-04 8:29 ` sirjofri
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).