This is a sketch of the basic "API" for interfacing with the dynusers scripts.
There are several different tasks which these scripts must do:
1. Maintain a database of users and groups that have been added by the
scripts. These databases contain a newline separated list of package
identifiers (name and version, usually), which mainly serves to tell the
scripts when a user is no longer used by any package on the system.
Database actions should all go through the db.sh script.
This can be invoked in 2 different modes:
db.sh add dbtype pkgname newname [root]
Adds an entry to the database. dbtype is one of user or group, pkgname
is a unique package identifier (category, name, and version), newname
is the name of the user or group to be added. The optional parameter,
root, defines the system root to install into. If not provided, it is
assumed to be /.
db.sh del pkgname [root]
Removes all instances of pkgname from the database. This is what is
run when a package is removed, or upgraded (the old version needs to
be removed from the database). The optional parameter, root, is the
same as above.
2. Add any users or groups requested by a new package to the system. At the
same time, the database should be updated. This action is performed by the
add.sh script. It should be run once, before the package is unpacked,
compiled, or installed. It is invoked as follows:
add.sh "new users list" "new groups list" pkgname userspace [root]
"new users list" - a single parameter, a space-separated list of new
users to be added for this package.
"new groups list" - same as above, only for groups.
pkgname - a unique identifier for the package about to be installed
(category, name, and version).
userspace - a unique identifier of the userspace we are running in. This
is something of the form USERLAND-ELIBC. For example, most GNU/Linux
systems would specify GNU-glibc, while FreeBSD-based systems would use
BSD-FreeBSD.
root - an optional parameter, defines the system root to install into.
If not provided, assumes /.
3. Revert any changes made if an install fails. This is done by calling
install_fail.sh with the same arguments as add.sh. It will know what needs
to be done to clean up from itself (i.e. roll back the database, remove
any unnecessary users or groups, etc).
4. Display information about the managed users and groups, including which
ones may be safely removed, and offer the operator a way to remove them
elegantly (meaning cleaning up the database as well as removing them from
the system). This is handled by the users.eselect script.
|
