[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 mind:
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 line.

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 DBs. ;-)

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.

ya...

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?


- Bruce



Reply to: