* Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
2016-11-15 19:05 ` Stanley Lieber
@ 2016-11-15 19:22 ` James A. Robinson
2016-11-15 19:52 ` Ole-Hjalmar Kristensen
2016-11-16 13:21 ` Anthony Sorace
2 siblings, 0 replies; 13+ messages in thread
From: James A. Robinson @ 2016-11-15 19:22 UTC (permalink / raw)
To: Stanley Lieber, Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
Ah, ok. I'll try that. Thank you!
On Tue, Nov 15, 2016 at 11:05 AM Stanley Lieber <sl@9front.org> wrote:
> "James A. Robinson" <jim.robinson@gmail.com> wrote:
>
> >So in a canonical installation the auth server mounts its root from the
> >file server?
> >
> >On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber <sl@9front.org> wrote:
> >
> >> The idea is that there is one file system shared by all the
> >neighboring
> >> systems. The canonical Plan 9 installation comprises one disk file
> >server
> >> and many diskless computing machines (auth servers, cpu servers,
> >terminals).
> >>
>
> Yes. You can arrange for hands-free booting by storing the same
> authid/authdom/password in the nvram of both the file server and the auth
> server. I usually boot the auth server from a 9fat partition or a USB key,
> then tcp (actually, tls) mount the root file system from the file server.
>
> sl
>
>
[-- Attachment #2: Type: text/html, Size: 1768 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
2016-11-15 19:05 ` Stanley Lieber
2016-11-15 19:22 ` James A. Robinson
@ 2016-11-15 19:52 ` Ole-Hjalmar Kristensen
2016-11-15 20:06 ` Stanley Lieber
2016-11-15 20:12 ` cinap_lenrek
2016-11-16 13:21 ` Anthony Sorace
2 siblings, 2 replies; 13+ messages in thread
From: Ole-Hjalmar Kristensen @ 2016-11-15 19:52 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
On Tue, Nov 15, 2016 at 8:05 PM, Stanley Lieber <sl@9front.org> wrote:
> "James A. Robinson" <jim.robinson@gmail.com> wrote:
>
> >So in a canonical installation the auth server mounts its root from the
> >file server?
> >
> >On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber <sl@9front.org> wrote:
> >
> >> The idea is that there is one file system shared by all the
> >neighboring
> >> systems. The canonical Plan 9 installation comprises one disk file
> >server
> >> and many diskless computing machines (auth servers, cpu servers,
> >terminals).
> >>
>
> Yes. You can arrange for hands-free booting by storing the same
> authid/authdom/password in the nvram of both the file server and the auth
> server. I usually boot the auth server from a 9fat partition or a USB key,
> then tcp (actually, tls) mount the root file system from the file server.
>
> sl
>
>
Is this the reason that it is actually possible to boot a combined
auth/cpu/file server at all? I mean, the auth server stores /adm/keys on
the file server, right? And normally you would need to authenticate
yourself to attach to the file server, which would be kind of difficult,
since it is the auth server that is trying to access the key file...
Ole-Hj.
[-- Attachment #2: Type: text/html, Size: 1875 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
2016-11-15 19:52 ` Ole-Hjalmar Kristensen
@ 2016-11-15 20:06 ` Stanley Lieber
2016-11-15 20:12 ` cinap_lenrek
1 sibling, 0 replies; 13+ messages in thread
From: Stanley Lieber @ 2016-11-15 20:06 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs, Ole-Hjalmar Kristensen
Ole-Hjalmar Kristensen <ole.hjalmar.kristensen@gmail.com> wrote:
>On Tue, Nov 15, 2016 at 8:05 PM, Stanley Lieber <sl@9front.org> wrote:
>
>> "James A. Robinson" <jim.robinson@gmail.com> wrote:
>>
>> >So in a canonical installation the auth server mounts its root from
>the
>> >file server?
>> >
>> >On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber <sl@9front.org>
>wrote:
>> >
>> >> The idea is that there is one file system shared by all the
>> >neighboring
>> >> systems. The canonical Plan 9 installation comprises one disk file
>> >server
>> >> and many diskless computing machines (auth servers, cpu servers,
>> >terminals).
>> >>
>>
>> Yes. You can arrange for hands-free booting by storing the same
>> authid/authdom/password in the nvram of both the file server and the
>auth
>> server. I usually boot the auth server from a 9fat partition or a USB
>key,
>> then tcp (actually, tls) mount the root file system from the file
>server.
>>
>> sl
>>
>>
>Is this the reason that it is actually possible to boot a combined
>auth/cpu/file server at all? I mean, the auth server stores /adm/keys
>on
>the file server, right? And normally you would need to authenticate
>yourself to attach to the file server, which would be kind of
>difficult,
>since it is the auth server that is trying to access the key file...
>
>Ole-Hj.
Yes. File server boots and loads it's key from nvram into factotum. Auth server does the same. If both credentials match, the two machines will agree to talk to each other. The ticket is "forged" and factotum realizes it has enough information to perform the authentication without needing to consult the actual auth server.
sl
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
2016-11-15 19:52 ` Ole-Hjalmar Kristensen
2016-11-15 20:06 ` Stanley Lieber
@ 2016-11-15 20:12 ` cinap_lenrek
1 sibling, 0 replies; 13+ messages in thread
From: cinap_lenrek @ 2016-11-15 20:12 UTC (permalink / raw)
To: 9fans
> Is this the reason that it is actually possible to boot a combined
> auth/cpu/file server at all?
no. the reason this works is that the fileserver and authserver share
the same key (authid and password) so factotum can make up auth tickets
using the key it already knows, skipping the authentication server.
this is expecially true if everything runs on a combined cpu/fs/auth,
then factotum basically talks to itself thru the 9p auth file thru the
fileserver :-)
note this also happens when you boot off a cpu server from its own
local fileserver. for a stand alone terminal with a local disk you
wont neccesarily have a key so you have to disable authentication
on your local disk fileserver in that case.
this mechanism is also usefull when your authentication server is
unreachable or offline. then you can still logon as the hostowner
of the affected machine.
the fact that the key comes from nvram is irrelevant. if it where not
there factotum will prompt for the information on boot (cpu/file
servers only).
--
cinap
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
2016-11-15 19:05 ` Stanley Lieber
2016-11-15 19:22 ` James A. Robinson
2016-11-15 19:52 ` Ole-Hjalmar Kristensen
@ 2016-11-16 13:21 ` Anthony Sorace
2016-11-16 15:31 ` Stanley Lieber
2 siblings, 1 reply; 13+ messages in thread
From: Anthony Sorace @ 2016-11-16 13:21 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
I'm not sure there's a single "canonical" answer, but many installations have run the auth server off its own file system, as James originally described. It's been several years now so my memory could be fuzzy, but I believe this is what they did at the main Bell Labs installation.
> On Nov 15, 2016, at 14:05, Stanley Lieber <sl@9front.org> wrote:
>
> "James A. Robinson" <jim.robinson@gmail.com> wrote:
>
>> So in a canonical installation the auth server mounts its root from the
>> file server?
>>
>>> On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber <sl@9front.org> wrote:
>>>
>>> The idea is that there is one file system shared by all the
>> neighboring
>>> systems. The canonical Plan 9 installation comprises one disk file
>> server
>>> and many diskless computing machines (auth servers, cpu servers,
>> terminals).
>>>
>
> Yes. You can arrange for hands-free booting by storing the same authid/authdom/password in the nvram of both the file server and the auth server. I usually boot the auth server from a 9fat partition or a USB key, then tcp (actually, tls) mount the root file system from the file server.
>
> sl
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] Maintenance of an auth server files vs a dns+dhcp+tftp server
2016-11-16 13:21 ` Anthony Sorace
@ 2016-11-16 15:31 ` Stanley Lieber
0 siblings, 0 replies; 13+ messages in thread
From: Stanley Lieber @ 2016-11-16 15:31 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs, Anthony Sorace
Anthony Sorace <a@9srv.net> wrote:
>I'm not sure there's a single "canonical" answer, but many
>installations have run the auth server off its own file system, as
>James originally described. It's been several years now so my memory
>could be fuzzy, but I believe this is what they did at the main Bell
>Labs installation.
>
>> On Nov 15, 2016, at 14:05, Stanley Lieber <sl@9front.org> wrote:
>>
>> "James A. Robinson" <jim.robinson@gmail.com> wrote:
>>
>>> So in a canonical installation the auth server mounts its root from
>the
>>> file server?
>>>
>>>> On Tue, Nov 15, 2016 at 10:47 AM Stanley Lieber <sl@9front.org>
>wrote:
>>>>
>>>> The idea is that there is one file system shared by all the
>>> neighboring
>>>> systems. The canonical Plan 9 installation comprises one disk file
>>> server
>>>> and many diskless computing machines (auth servers, cpu servers,
>>> terminals).
>>>>
>>
>> Yes. You can arrange for hands-free booting by storing the same
>authid/authdom/password in the nvram of both the file server and the
>auth server. I usually boot the auth server from a 9fat partition or a
>USB key, then tcp (actually, tls) mount the root file system from the
>file server.
>>
>> sl
>>
The reason I used the term "canonical" is because this was the arrangement described in the Plan 9 papers. The single file system was touted as one of the central features of the system, and one of its major benefits.
Example benefit: When a diskless system crashes, there is no danger of damage being done to the file system.
sl
^ permalink raw reply [flat|nested] 13+ messages in thread