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/fscons,
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,
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
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 is
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 way
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 alternative
(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
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