Re: [9fans] file ownership on /srv
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, which is just a pipe and thus doesn't work so well with multiple readers), you can log the console output easily, and you can see what commands others are executing. Now that's the ticket! consolefs it is! Thanks all for the responses! -Ben winmail.dat
[9fans] file ownership on /srv
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, by bootes: cpu% ls -l /srv/fscons --rw--- s 0 bootes bootes 0 Aug 6 12:09 /srv/fscons cpu% 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. I read in chgrp(1) that you can't change file group membership when the fileserver is not in the bootstrap state. How then can I get the /srv/fscons to belong to the 'sys' or 'adm' groups? Or is the generally accepted solution to add my account to the bootes group, then chmod g+rw /srv/fscons (from the console)? Would that even allow me to connect to the fscons from a drawterm session? I understand the concept of no superuser and un-circumvent-able security, but someone's got to be able to do administrator-type things w/o taking a trip to the server room... Thanks much in advance!! -Ben winmail.dat
Re: [9fans] file ownership on /srv
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 'bootes' instead of your usual id. --lyndon Every cloud has a silver lining; you should have sold it, and bought titanium.
Re: [9fans] file ownership on /srv
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 subject to the rules in wstat(5), provided the file server supports it. unfortunately, kernel drivers such as #s don't support groups (in general). [EMAIL PROTECTED]'s suggestion should work, though (instead of drawterm, i usually just use telnet as bootes to a file/cpu/auth server for admin work.) although i haven't needed it here, consolefs(4) might be useful too (and it implements groups itself)
Re: [9fans] file ownership on /srv
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 to give a specific group the ability to connect to fscons non-locally w/o using the bootes account? winmail.dat
Re: [9fans] file ownership on /srv
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 that comes to mind is to write a server that runs as the file server host owner and accepts user creation requests. Make it require authentication and give it a list of authorized users and you're good to go. (Well, you get the idea.) --lyndon Per dollar, the cray is cheaper to maintain than the comets. -pjw
Re: [9fans] file ownership on /srv
(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 /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. winmail.dat
Re: [9fans] file ownership on /srv
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 that. The first is to put bootes's key in your factotum, after your own. Then when you want to connect to the cpu server you can cpu -k 'user=bootes', do what you need to do, and exit. The second is to make a console for each user who can run file server commands. You can issue additional srv commands in the file server config to create /srv/fscons.bhuntsman, etc., and then each user can connect to the one with the appropriate permissions. 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, which is just a pipe and thus doesn't work so well with multiple readers), you can log the console output easily, and you can see what commands others are executing. The cpu or extra console solutions are fine if only one person (you) ever connects to the console. Once there is more than one person involved, consolefs is usually better. I use consolefs (with serial lines) for my own Plan 9 machines even when it's just me. One could imagine more complicated solutions, like writing servers that let certain users do certain restricted things, like create a new user but not execute other file server commands. It sounds like that's more complex than you actually need. All of these solutions assume that your normal user id should be allowed to connect to the file server console without additional authentication. You could also create a second user id (e.g., bhuntsman-sys) and require explicitly loading that user's credentials before connecting, if you were worried about accidental use. Russ
