Re: Create user during installation
On Sat, 2 Apr 2005, Sven Mueller wrote:
Bruce Sass wrote on 02/04/2005 01:02:
Ya, ok, it is still a significant amount of work, but it would be Debian's
work and not that of the upstream authors.
Now, what does make more sense?
a) Investing a huge amount of time and thought into cleanly managing
system users (i.e. UIDs not associated with humans but with
programs/packages), possibly across many systems (i.e. different
hosts or even operating systems). Let alone the amount of time
to use this management software across all packages.
b) Have each software create the needed users during installation
if they don't already exist and have these users left behind on
purge (wasting a few bytes per package at most).
I would go with a) because it is more likely to result in consistency
between systems and across time; although b), with its bit more work
for the admin, would be more satisfying and instructive.
What I was thinking about when I wrote that last message would
actually be the glue or translation layer between the package
management system and what you (afaict) have in mind for a).
I'll address the requirements you've outlined from the perspective of
what I have in mind (which I'm going to call the Package-User Layer
(pul), just to explicate the differences.
IMHO, it is clear to me that (b) is the answer. But if anyone would implement
(a), I would happily use it in my packages. But keep these requirements in
1) The system has to keep track of all packages on all hosts which
need the UID in question.
The pul would only need to keep track of whether any package still
needs a particular user, anything else would be fluffy or bluring a
2) The system has to allow the admin to mark a UID as dont_delete
This could be done at the pul level by manually incrementing the
counter. It is kinda hackish but would serve the purpose in the
absence of any real system users management software (SUMS, a).
2b) The system should allow the admin to add arbitrary
host/package/needed-uid tupels to the database.
Not a concern because the pul would only need to keep track of how
many packages have requested that a particular user exist; actually
manipulating the DB would be handled by whatever tools do that sorta
thing. The pul will need to know which tools to tell and how.
3) The system _must_not_ delete a UID if at least a single package
on a single involved host still needs it.
Of course. Even without an a), the pul could be made to honour
requirements imposed by external systems using the same basic
mechanism which implements requirement 2).
4) Keep in mind that Debian hosts are often used in heterogenous
environments, which might also involve other UNIX derivates and/or
Windows hosts. Many user-databases (especially LDAP) can be used
cross-platform like this.
Ya, the design would pretty much need to assume that each system it is
used on could be unique... which is why I choose to think about the
simpler and more well defined task of overseeing what the packages on
the local system require, and leave the decisions about what to do
with their aggregated requests up to the packages which manage the
5) A UID once created on a Debian host might also be needed by a
program on a FreeBSD or even a Windows host after that.
So: (a) would only work if (2) is implemented and/or it is available and
usable on all hosts in a network with a shared user database. By "and/or" I
mean: If (2) (especially (2b)) is implemented, it might provide a way to work
around missing implementation of the system on a given host or around a
package which needs specific uids but doesn't (yet) use that system.
...2) essentially says the scheme needs to have an override, imo.
Can you see a), a SUMS scheme, being implemented in a distributed
manner via (say) run-parts'd files provided by/for the admin tools
(adduser[-ng], LDAP, etc.)?
other (future) questions:
To what extent could package dependencies be used to manage the
"files" mentioned above, would a lot of debconf based stuff be
needed, would there need to be a SUMS of some sort?