On Aug 6, 2009, at 4:47 AM, erik quanstrom wrote:
Works like a charm. Knowing the the correct manual page(s) to be
looking
at certainly helps! <grin>
I can't help though but be curious as to why there's no command, or
an additional switch to changeuser, to remove users from the keyfile.
I guess due to Plan 9's simplicity motto?
[...]
I read through fossilcons(8) though, and I'm still not sure how to
delete
a filesystem user. I almost got the impression that it's not
possible -
due to the mention that "Once an id is used in file system structures
archived to Venti, it is impossible to change those disk
structures, and
thus impossible to rename the id"; but reading on, I guess to remove
a user, I just need to manually edit the user table? Will it hose
things if
I edit /adm/users directly, from a shell, rather than executing
'users [ -r file ]' on /srv/fscons?
the reason there are few provisions for deleting a user, is because
that
doesn't make much sense if you have a worm filesystem. at best you
can remove the user from the active filesystem, but not the dump.
this is the same reason that renaming users is difficult. (ken's fs
doesn't have this problem since there's a level of indirection between
the name and strictly-internal user id.)
i just disable the user's authentication and make the user's mailbox
unwritable; i've never had a reason to rename a user.
It also seems that most of organizations I know have that same kind
of permanency in place even at HR level. If you leave the company
and then get rehired you feel like you've never left -- you badge id
and sorts of HR assigned credentials are simply enabled, not created
anew. Don't know whether this is a function of IT influencing HR
decisions or whether there's an HR reason for doing it that way.
Thanks,
Roman.
