I think it'd be great to have a native NetBSD adduser.  But I can see
that providing sufficient flexibility is going to be a problem, no
matter what you do.  It would be really neat (IMHO) to have something
akin to an /etc/adduser.conf file, which would specify default values
for the local system.  It would also be cool to have something like an
/etc/adduser.local script that would be run by adduser.  That would
allow the admin to customize as much as desired.

>>>>> "SB" == Simon Burge <simonb@telstra.com.au> writes:

SB>  + useradd has a "-m" option which creates the user's home
SB> directory if it does not already exist.  A reason why you would
SB> ever not want to do this escapes me at the moment...

nobody:*:32767:9999:Unprivileged user:/nonexistent:/dev/null

SB>  + An option to set a quota in the user's home directory?  I've
SB> never used quotas...

That would also be great, but could possibly be provided by an
adduser.local script, or similar.

Another useful concept is user groups.  Perhaps this should be based
on nothing more complex than the user's default GID; perhaps not.
Anyway, users in a particular group might want a particular set of
skel files, or a particular set of quotas, or whatever.  Not sure how
to implement this, but I know it would have been useful at my last
job, where we had many professors, graduate students, and undergrads,
all of whom needed different options in their accounts.

SB>  + Something to set a plain-text password on the command line?
SB> Addnerd uses "-p encrypted" - Simon Gerraty's adduser program does
SB> this with "-P plaintext" (as well as using "-p encrypted" too)...

People will protest that this is a security problem.  I think you
should make a note of that fact in the man page, and leave it there,
so people can use it if they want.

SB> As for related commands, let's chose "usermod", "userdel",
SB> "groupadd", "groupmod" and "groupdel" for names.  There doesn't
SB> seem to be any sort of convention (that I can see!) except for the
SB> CDE/SVID3 way of doing things - well maybe both "rmuser" and
SB> "userdel"...  Let's for now say that a userdel command, and the
SB> group* commands will be a SMOP, and that a usermod command could
SB> either share a lot of code with a useradd command or be based on
SB> the same.

I don't know about the *mod commands, but userdel would certainly be
handy.  But this one, in particular, is going to need the capability
for customization scripts.

My $.02.

Chris

-- 
-----------------------------------------------------cjones@math.montana.edu
Chris Jones                                          cjones@honors.montana.edu
           Mad scientist at large                    cjones@nervana.montana.edu
"Is this going to be a stand-up programming session, sir, or another bug hunt?"