Ladies & Gentlemen,
Some of you may know me from lurking on #gentoo-dev or moderating
#gentoo or any of another handful of channels that I'm in. Anyway, I'm
trying to become a developer and to learn the Gentoo way. I have been
assigned an old bug to try and resolve, Bug #5113, "New adduser and
deluser features request". In pursuit of that end I have decided to
start from scratch and write a single wrapper script for the useradd,
userdel, groupadd, and groupdel scripts to ensure that file locking is
properly handled on all archs. That said, everything else except
writing to /etc/{passwd,group,shadow,gshadow} will be handled by this
script.
Chris White read and commented on this email prior to its being sent
and thinks that I should have a working code base first. I disagree and
think that these decisions will effect the design of the script and may
necessitate and re-write; that is what I'm trying to avoid. I have
already written a few hundred lines of code for some of the branch
features like scanning the /etc/{passwd,group,shadow,gshadow} files for
data, searching for files/processes, reading/writing the defaults file,
etc., enough to get a grasp of most of the problems but I want to figure
out the main hierarchy before I go too much further.
I intended to add all of the functionality that exists right now into
the new script. It will read values from /etc/login.defs and have its
own config file for extensions/additions to the current way of doing
things. The script will also add functionality on top of that like the
ability to delete a user's home directory when that user is deleted. I
know that is handled now but the ability to archive that user's home
directory prior to deletion is not. And the ability to hunt down the
user's mailspool and aliases, crontab and sudoers entries, running
processes and files outside of their home is not. If everything works
out as planned this script can be used as a user/administrator's sole
interface into the /etc/{passwd,group,shadow,gshadow} files and can even
be expanded into an eclass for ebuilds that need to create users/groups.
I would like some input in the name of the program, its features,
calling convention, and its config file options. I was thinking of
calling it id-manage with three basic modes of operation. User to
manipulate users. Group to manipulate groups. And default to manipulate
the config file's entries.
id-manage user [add|del|show] <UID> [additional-options]
id-manage group [add|del|show] <GID> [additional-options]
id-manage default [set|get] <config-option> [<value>]
I would like the script to be able to be called with the least amount
of cruft as possible. It is my opinion that having a program a category
and a mode is easier to remember than one of four program names. It is
also my belief that sane defaults should be provided and that they be
able to be overridden by the administrator. I am interested on any
feedback that I can get regarding the calling convention of the program
here. For instance, "id-manage add user" was eliminated because
defaults can't be added. Nothing is set in stone here although I have
made some decisions that are going to require some pretty strong
arguments to get me to change my mind. I'm open to debate and the last
thing that I want to do is write something that I feel is great and not
have it adopted because I overlooked some Gentooism or failed to
consider someone else's point of view. This is your chance to speak up.
Also, I need to know exactly what is and is not allowed in certain
places. For instance: user names, they can be alpha-numeric but they
have to start with a letter don't they (shadow v4.03)? Also, user names
with capitals have been banned since most MTAs are case-insensitive and
that can cause confusion. What else is there to consider?
I'm not new to programming so all of this is within my skill set so
don't be afraid to ask for features. However, this is going to take a
couple of weeks to write entirely in bash so that it is both portable
and can be used on the most minimal of systems. (Also, although I'm not
thinking of other distributions right now I don't want to do anything
that will preclude its use on them). I have seen a request for
something like "superadduser user-name group-name" to add a user to a
group. This won't work with my design but "manage-id user add user-name
to group-name" might. I'm interested in design discussion here but I
don't want to do things just because it is the way that something else
does them.
The last issue is the config file. I have a boatload of ideas here but
I don't want to cloud anyone else's ideas with mine. Can you just give
me ideas that you would like to see here. As an example:
# If enabled then it will find a uid/gid that is new
# if id min/max was 1000/5000 and ids 1000-1050 have been assigned
# but ids 1022-1025 have been deleted, normally the next id assigned
# would be 1022 but this will skip the hole and assign 1051 next.
# This can't be guaranteed to work. A hist file might help.
SKIP_HOLES TRUE
Please let me know what you guys want in this.
Regards,
--
Tres Melton
IRC & Gentoo: RiverRat
--
gentoo-dev@gentoo.org mailing list
