[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] EID database and entries getting to baselayout
From:       splite-gentoo () sigint ! cs ! purdue ! edu
Date:       2004-01-29 21:40:40
Message-ID: 20040129214040.GF7186 () sigint ! cs ! purdue ! edu
[Download RAW message or body]

On Thu, Jan 29, 2004 at 11:11:04AM -0800, Max Kalika wrote:
> Quoting splite-gentoo@sigint.cs.purdue.edu:
> 
> Might be my own twisted view, but I can't see the benefit in sharing system
> accounts across different boxes.  Mysql database, NIS maps, LDAP,
> what-have-you, can contain just the _user_ accounts.  The remaining system
> stuff belongs in /etc/{passwd,group} because different boxes can run
> different services.

Unix doesn't differentiate between system and user accounts (save uid 0).
Any line between them is arbitrary and differs by OS and local policy.
I remember when only uids under 100 were considered system.  Now many
systems assume under 1000.  (You said under 2000 for your site.)  Heck,
there's no reason why all the system accounts couldn't be between 5412
and 6883.

Given that system uids are arbitrary, how do you make sure you don't
assign the system uid you (or Portage) just stuck in /etc/passwd to a
regular user?  You... wait for it... put it in the global database.

> But I suppose legacy is legacy and hard to break away from.

True, but it's not just about legacy stuff.  There's no reason another
current OS couldn't pick a different dividing line between system and
user uids.  All the ones we use do.

> > It's not really a huge undertaking to provide a switch that lets folks do
> > their account management themselves if they need to.  I'm not asking that
> > ebuilds should automagically know how to update my NIS maps or talk to
> > your MySQL server.
> 
> Something like ...
> 
> FEATURES="accounts" (set by default in make.global). When on,
> enewuser/enewgroup will happily create the user/group based on eid.*.  When
> off, enewuser/enewgroup will stop the build process when the user/group
> doesn't exist informing the admin to create it ahead of time?

Right, though I would call it "noaccounts" and leave the current behavior
as the default.

> Lets take it further!  Instead of using enewuser/enewgroup, what about
> adding two new variables in ebuilds? USERS="user1 user2" and GROUPS="group1
> group2".  These have to be defined in eid.* databases.  When the merge
> process starts, the accounts are either created or the build dies (based on
> FEATURES="accounts").  This has a side benefit of being tracked per package
> in the portage database and these accounts can be removed when the final
> version of the package is unmerged (based on the "accounts" feature, of
> course).  Thoughts from the portage folk?

This is more than I was asking, but it's not a bad idea.

--
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]