Re: [9fans] a few Q's regarding cpu/auth server

[Anthony Sorace <anothy@gmail.com>]

> "/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory"
>
> ... not quite sure what to make of that.

that's weird. it shouldn't be a directory, just an append-only file
like most of the others in /sys/log. not sure how it got directoried.
remove and replace.

> * Could anyone explain or tell me where I can find more information
> regarding what all is going on with the following:
>
>   con -l /srv/fscons
>   prompt: uname bootes bootes
>   prompt: uname sys +bootes
>   prompt: uname adm +bootes
>   prompt: fsys main
> main: create /active/cron/bootes bootes bootes d775
> main: create /active/sys/log/cron bootes bootes a664
>
> ... I've read con(1), and I can fathom the obvious basic premise:
> I'm creating a user and assigning it to groups. But what is '/srv/fscons',
> and what is 'fsys main' doing, and where can I find what other commands
> are available and what they do?

/srv/fscons is the conventional location for you fossil console; see
fossilcons(8) for more information, including what uname, fsys, and
create do.

> * At one point I created a new user with 'auth/changeuser' that I didn't
> need/want. What's the suggested means of removing this user?

see keyfs(4). remove the directory.

> * Similarly to the question above, how should I delete a user created
> with uname via fscons?

you may or may not realize this, but it's sometimes non-obvious: users
on the auth server are different from users on a file server, and they
don't need to be the same (depending on what you want). changeuser and
keyfs work on the auth server; anything done on fossil's console
(/srv/fscons) is on the file server. again, see fossilcons(8).

> * I hope I don't get beat up on this one (well, I hope I don't get too beat up
> on _any_ of these questions...), but it seems strange that something as
> important as a cpu/auth server would just go and boot up right into the
> hostowner... apparently this a non issue - so what am I not understanding?

philosophy. plan9, like research unix before it, recognizes that if
you have physical access to the box, all bets are off anyway. security
consists of locking your door.

if you really, really need to get around that, you have a few options.
the closest to "out of the box" is to install and run a screen locker;
a few people have written those, although i'm not entirely certain any
are current. more ambitiously, there was a 3rd edition patch to detach
the console devices from the cpu server itself, asking for login and
treating it as an attached terminal. those are assuredly out of date,
but if you really need the functionality, that's where to start.

alternately, just run something on the console that doesn't have a
"quit" function. the console doesn't have interrupt functionality.