[gentoo-dev] user/group manipultaion feedback request.

[gentoo-dev] user/group manipultaion feedback request.

[Tres Melton]

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

[gentoo-dev] Re: user/group manipultaion feedback request.

[Duncan]

Tres Melton posted <1128322169.6208.355.camel@thor.tres.org>, excerpted
below,  on Mon, 03 Oct 2005 00:49:29 -0600:

> 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.

Imagine seeing /you/ here!  =8^)

Portability is good, but as I've been reading Diego "Flameeyes" various
posts as he struggles to get Gentoo/FBSD up and running, and with
Gentoo/Darwin and etc. in mind, I'm sure one of the requests is going to
be making it full borne shell standard compatible, therefore, no
"bash-isms".

Likewise, keep in mind POSIX compatibility when making any
sed/grep/file/etc calls.  Don't assume the GNU versions.  If you need the
info, I believe most of the manpages specify where the GNU versions
deviate from POSIX.  I'm sure Flameeyes will be glad to help, as it'll
mean less porting issues he and others  need to worry about later.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: user/group manipultaion feedback request.

[Tres Melton]

On Mon, 2005-10-03 at 12:04 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Monday 03 October 2005 11:14, Duncan wrote:

Hello Duncan.

> Actually, bash is fine, as long as you declare #!/bin/bash the script. Every 
> Gentoo/ALT system should have bash installed as part of base system, as bash 
> is what the ebuilds are written in. 

Good as this is what I was working from.  I've coded the parts that
extract and parse the information from the /etc/{passwd,group} files
already as well as reading and writing the config files and not found it
necessary to make any head, tail, sed, grep, awk, wing and a prayer
calls.  :)    As I said, I want to write this in bash itself as much as
possible for portability.

> > Likewise, keep in mind POSIX compatibility when making any
> > sed/grep/file/etc calls.  Don't assume the GNU versions.  If you need the
> > info, I believe most of the manpages specify where the GNU versions
> > deviate from POSIX. 
> Also here the point is not to avoid GNU calls on every tool, is just to make 
> sure that the tool called is actually GNU :)
> The insidious GNUisms are the ones relative, for example, to cp or mv, which 
> are base system commands. But GNUisms in sed calls are usually safe as long 
> as you make sure that you're calling GNU sed. Ebuilds sanitize this aliasing 
> it to gsed, while eselect uses aliases that checks the right tool to use.
> 
> You can give a look to 
> http://www.gentoo.org/proj/en/gentoo-alt/maintnotes.xml#doc_chap2 to have a 
> list of common problems with GNUisms.

Thanks for the link.  Once I start searching for processes to kill and
files to delete I'm sure that will become a good reference.  I'm
thinking that these will be the only needed external programs:

find
ps
tar
gzip ? (or something else to compress things with)

I might write a test function to the install system to verify the
existence of the correct tools and switch to the correct syntax if I
need to.  Although Gentoo is my primary goal I want things to work on a
minimal system of any flavor of *nix that has bash.  That goal may have
to be abandoned though.  We'll see.

Regards,
-- 
Tres Melton
IRC & Gentoo: RiverRat


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: user/group manipultaion feedback request.

[Diego 'Flameeyes' Pettenò]

On Monday 03 October 2005 13:39, Tres Melton wrote:
> I've coded the parts that 
> extract and parse the information from the /etc/{passwd,group} files
I think with this you're already out of portability. /etc/passwd structure in 
Linux and FreeBSD is different, and on Darwin the users part is completely 
another story. Take a look to enewuser/enewgroup functions on eutils eclass.

> find
This is mostly compatible a part a couple of commands (like -printf) and the 
fact that it *needs* that you give him a path to work on.

> ps
This is different from OS to OS, the Linux version is not portable. Have a 
look to pgrep, but that's not completely portable, too.

> tar
As long as you use the basic commands, it should be safe. You cannot ignore 
the format of the archive, tho, as just bsdtar and later GNU tars support 
that.

> gzip ? (or something else to compress things with)
That's just the same.

> Although Gentoo is my primary goal I want things to work on a
> minimal system of any flavor of *nix that has bash.
You'll probably have not to use directly the /etc/{passwd,group} files, as 
they are not universal. Every os uses its own ways to access those data, and 
things do not get better when adding pam as a variable in all this.

Take a look to egetent, egethome functions in eutils and portability eclass if 
you want to take a look to what is done now. That is still incomplete, 
though, so you will probably have other things to arrange...

You're wellcome to join gentoo-alt mailing list to discuss of portability in 
case :)

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

-- 
gentoo-dev@gentoo.org mailing list