[Adduser-devel] Status update on the adduser rewrite [long]

[Brian M. Carlson]

Here's a status update on the adduser rewrite.

Groups are implemented, for the most part.  In test mode, the groups
work flawlessly.  I'd like to rewrite the code for groups not to be in
the adduser.cc; instead, it should be in an object.

System users are working, somewhat.  Two cases cause an internal error;
I need to implement some more functions in the backends in order to fix
this.

Normal users are not working.  They will use some of the same code that
system users do, but normal users just are not implemented yet.

Adding users to groups works.  Again, this code should be in an object.

I'm going to implement a fork/exec backend that uses useradd and family.
This way, I don't have to write another three different backends right
away.  This backend will obviously not work in test mode, since it
requires actual editing of the user and group databases, whereever they
are.  Test mode still works with the passwd/group database backend, and
it still writes into the current directory.

Some code will be added for PAM, to use that for adding user passwords.
There will also be an authentication backend that uses fork and exec to
call passwd.

There are some minor behavior changes.  This can be fixed by an upcoming
emulation layer that should work exactly like the latest version 3
implementation of adduser.

The build system basically reads from Makefile.config the options to be
built in.  For example, if you wanted to build with -frepo, you'd
specify (either in that file or on the command line) WANT_REPO=1.  That
would produce a somewhat smaller executable, at the expense of link
time.  If you wanted optimization, use WANT_OPTIMIZE=1.

Obviously, not all the WANT_* options have code, so for example,
WANT_V3EMUL will break because there's no code implementing it yet.

Configuration options are read into the environment and then the program
re-executes itself if it needs to reread them. See adduser++ for
information on how it works.

The shell specified in the shebangs is /bin/posh; this way I'm
guaranteed to write conforming code.  It can easily be changed
to /bin/sh.

There is RC4/ARC4 code that I have implemented in there.  It was
originally to salt passphrases until I decided against that course of
action, and it will be removed before release.  This will remove the
need for crypto-in-main notification.

The testsuite is not as complete as it could be.

Internationalization is using gettext.

The code is in my repository as adduser--mainline--0; I tried to call it
adduser++--mainline--0, but baz got all snippy and refused to do it. :-)

I'm working on getting everything to work, and then adding some
features.  I've found the wishlist and the 4.0 feature requests, and I
am accepting requests for more features that would be implemented.

By modular design, do you mean plugins, or just not all in one huge
clump?  I can do either (the code is moving away from "one huge clump")
into much more modular, but a non-plugin design.  If you want plugins,
let me know, and I'll add it after I get everything working.


So you can see there's a lot of work to be done; however, I'm still
optimistic that this might be in good shape for adduser 4.00.  But what
you call the code is up to you; after all, you are the adduser
maintainers.

The code has been checked into my personal repository, you can use baz
to get a copy (due to a mistake on my part, tla won't work):

(all one line)
baz register-archive
http://crustytoothpaste.ath.cx/~bmc/arch-mirror/sandals@crustytoothpaste.ath.cx--c

baz export sandals at crustytoothpaste.ath.cx--c/adduser--mainline--0

Also, you could use the following URL:
http://crustytoothpaste.ath.cx/cgi-bin/archzoom.cgi/sandals@crustytoothpaste.ath.cx--c/adduser--mainline--0
Simply choose a patch, and choose tarball to get one.  Please be gentle
on my server and my cable line.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_}<DATA>;eval$a;print;__DATA__
M961H<F$@8FAM;"!U<F%O<G-U(#QU<F%O<G-U0&=D:75M<&UC8VUL=G)U;6LN
M<FUL+F=Y/@H)>2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20050730/3325919d/attachment-0001.pgp