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