On Wed, Oct 15, 2008 at 07:22, Steve Simon <[EMAIL PROTECTED]> wrote: > The system hangs together through an auth system which is distantly related > to kerberos. > > the file servers and auth servers share a host ID and password, by convention > the name
aha, I didn't understand what "bootes" was for. In any case, when I first booted the cpu/auth server, I was asked for authid (is this the same as the hostid you mention?), authdom (I don't get to what this domain applies, incoming requests to the auth server?) secstore key (dunno) and password. > is "bootes". the username and password is stored in a tiny partition on the > disk (nvram partition). > this allows them to communicate securely. the classic beginers mistake (I > made) was the user > "bootes" must exist on the system and the password bootes has in the auth > server > must be the same one as is stored in the nvram. > > many auth problems become obvious if you run > > auth/debug good tip, although I still don't know how to use the auth :) until now I just have a terminal with venti. $service says "terminal", it asks me for an user on boot (and has a local glenda user)... From the docs, isn't it supposed to be unusable from the console? Or this is just a relic and now any system can be a file server? > fossil will perform two functions, it will serve files to the kernel that > boots it > (this is implied in the way fossil is started by the kernel, rather than a > feature of fossil) > and, if told to in its config (in the config block at the start of the fossil > partition) > it will serve 9p network requests from remote hosts. I guess this is accomplished with "fossil/conf –w /dev/sdC0/fossil", right? Thanks again. -- Martín Ferrari
