>The third is to use consolefs, as Charles suggested,
>to moderate access to /srv/fscons. This has many
>benefits over the previous two ideas: the set of console
>users is defined in one easy place (the consolefs config),
>consolefs will multiplex output to multiple connections
>(unlike /srv/fscon
> The true enjoyment of this OS is in discovering the blatantly simple
> solutions to what turn out to be blatantly simple problems ;-)
>
> I had completely forgotten about consolefs. Serial consoles still rule
> in a certain realm, but who says they cannot be updated ;-)
Just in case it isn't
The third is to use consolefs, as Charles suggested,
The true enjoyment of this OS is in discovering the blatantly simple
solutions to what turn out to be blatantly simple problems ;-)
I had completely forgotten about consolefs. Serial consoles still rule
in a certain realm, but who says the
> I did just find that if on the console I do chmod ugo+rw /srv/fscons, I can
> open it under my username via drawterm, though just chmod ug+rw /srv/fscons
> isn't good enough. Also, adding my username to bootes didn't seem to have an
> effect.
unlike unix, groups only exist on the fileserver.
> Since I'm not logged in as bootes, and am not a member of the
> bootes group, I can't use con to connect to /srv/fscons, and
> therefore, can't add a user.
That's correct.
You want to change the policy, so that you are allowed
to act as bootes occasionally. I see three reasonable ways
to do th
>The first alternative that comes to mind is to write a server that runs as
>the file server host owner and accepts user creation requests.
Actually, that's exactly the sort of thing I was working toward. I was just
hoping it could be done entirely via scripting, without having to put together
>(instead of drawterm, i usually just use telnet as bootes to a file/cpu/auth
>server for admin work.)
Isn't that one of those proverbially bad admin practices? :) I know I'm
guilty of it too, but I'm trying to cure myself of the habit.
I did just find that if on the console I do chmod ugo+rw
Yes that works, but isn't that similar to logging in as root to a unix
box over the wire? If I were delegating "add user" abilities to another
user, that'd mean I'd have to give them the password for bootes...
Yes. Anyone who has access to /srv/fscons owns the file server.
The first alternativ
>When you drawterm, authenticate as 'bootes' instead of your usual id.
Yes that works, but isn't that similar to logging in as root to a unix box over
the wire?
If I were delegating "add user" abilities to another user, that'd mean I'd have
to give them the password for bootes...
Is there no wa
> I read in chgrp(1) that you can't change file group membership when the
> fileserver is not in the bootstrap state.
the following isn't directly relevant to your current problem, but:
the manual page is commenting on chgrp's being used to change
file ownership, not its group. changing groups i
I have a CPU/Auth server set up. I'd like to be able to add users
remotely (via drawterm), rather than at the system's console. However,
normally, I can't attach to /srv/fscons, and as I found, can't start
another fscons and open the filesystem under it.
When you drawterm, authenticate as 'b
I have a CPU/Auth server set up. I'd like to be able to add users remotely
(via drawterm), rather than at the system's console. However, normally, I
can't attach to /srv/fscons, and as I found, can't start another fscons and
open the filesystem under it.
/srv/fscons gets created at startup, b
12 matches
Mail list logo
