modular design for adduser

[Roland Bauerschmidt <rb@debian.org>]

Hello all,

I'm ogling with the thought of reimplementing adduser with a completly
modular design. At the moment everything is in the perl scripts adduser
and deluser. Some - although limited - flexibility is given through
/usr/local/sbin/{adduser|deluser}.local for the local system
administrator. As example that this flexibility is limited only think of
the following example: you want to add a new user and when setting the
password it should also be set for samba. Or you want to switch the
authentication system to something other than shadow. At the moment
adduser is not flexible enough to cope with these situations properly.

In the following I explain my ideas how a modular design for adduser
could look like. Feel free to send suggestions, problems, etc to me.

 o There are a couple of perl or shell script which do the actual work.

   /etc/adduser/scripts.d/
                adduser.d/
                addgroup.d/
                addtogroup.d/
                deluser.d/
                delgroup.d/
                delfromgroup.d/

   scripts.d: This directory is simelar to /etc/init.d/. It contains the
   scripts which do the actual work. All scripts can be passed the
   following argument: clean. 

   adduser.d, addgroup.d, addtogroup.d, deluser.d, delgroup.d,
   delfromgroup.d: These directories are simelar to /etc/rc?.d/. They
   contain symlinks to the script in ../scripts.d/. They are executed
   during the corresponding tasks and have a couple of environment
   variables passed set by `adduser', e.g $action which may be
   adduser, addgroup, addtogroup, deluser, delgroup, delfromgroup.

   Depending on the variable `action' and if the `clean' argument was
   passed the script does the corresponding work. If `clean' is set the
   script has to do excatly the opposite work, e.g. removing the user
   again. This is necessary to undo changes again if something has failed.

 o The programs `adduser', `addgroup', `deluser', `delgroup' are the
   users' frontend to the scripts in /etc/adduser/foo.d/. Adduser gets
   all necessary parameters from the user, either my command-line
   argument or by interaction (the parameters and user interaction won't
   change to how it is currently done). Than the frontend executed all
   scripts in /etc/adduser/foo.d/ in a specific order.

   Let's look at the example of adding a user:

   # adduser
     - adduser asks for username
      - /etc/adduser/adduser.d/A.* is executed. Work is done here which
       should happen before the account is created. I don't know yet if
       this is necessary, but it is better provide the possibility from
       beginning on than realising later that this would be useful.
      - /etc/adduser/adduser.d/B.* is executed. The account is created at
       this step.
     - adduser asks for password, gecos, etc.
      - /etc/adduser/adduser.d/C.* is executed. Password, GECOS and
        user-defined or package specific scripts are executed here.
     - done!

   This is much more flexible than the current system. If you want to
   change to another authenitification system just drop some new files
   in /etc/adduser/scripts.d with the corresponding symlinks.

   All scripts get the same environment arguments passed. So it'd be
   possible for samba to drop a file in scripts.d with symlink to
   adduser.d/C60samba which would add the user the corresponding
   password to the samba password file.

   If any script returns a value different to 0 adduser all scripts that
   were already executed are executed in the backward order with
   argument clean.

I hope that this was not to confuse and I'd be glad for reactions,
comments, suggestions, things that I forgot, etc.

Roland

-- 
 * Roland Bauerschmidt <rb@debian.org> * http://www.copyleft.de/~roland/ *
 *         Debian GNU / Linux -- the choice of a gnu generation          *