1 |
On Thu, Jan 29, 2004 at 11:11:04AM -0800, Max Kalika wrote: |
2 |
> Quoting splite-gentoo@××××××××××××××××.edu: |
3 |
> |
4 |
> Might be my own twisted view, but I can't see the benefit in sharing system |
5 |
> accounts across different boxes. Mysql database, NIS maps, LDAP, |
6 |
> what-have-you, can contain just the _user_ accounts. The remaining system |
7 |
> stuff belongs in /etc/{passwd,group} because different boxes can run |
8 |
> different services. |
9 |
|
10 |
Unix doesn't differentiate between system and user accounts (save uid 0). |
11 |
Any line between them is arbitrary and differs by OS and local policy. |
12 |
I remember when only uids under 100 were considered system. Now many |
13 |
systems assume under 1000. (You said under 2000 for your site.) Heck, |
14 |
there's no reason why all the system accounts couldn't be between 5412 |
15 |
and 6883. |
16 |
|
17 |
Given that system uids are arbitrary, how do you make sure you don't |
18 |
assign the system uid you (or Portage) just stuck in /etc/passwd to a |
19 |
regular user? You... wait for it... put it in the global database. |
20 |
|
21 |
> But I suppose legacy is legacy and hard to break away from. |
22 |
|
23 |
True, but it's not just about legacy stuff. There's no reason another |
24 |
current OS couldn't pick a different dividing line between system and |
25 |
user uids. All the ones we use do. |
26 |
|
27 |
> > It's not really a huge undertaking to provide a switch that lets folks do |
28 |
> > their account management themselves if they need to. I'm not asking that |
29 |
> > ebuilds should automagically know how to update my NIS maps or talk to |
30 |
> > your MySQL server. |
31 |
> |
32 |
> Something like ... |
33 |
> |
34 |
> FEATURES="accounts" (set by default in make.global). When on, |
35 |
> enewuser/enewgroup will happily create the user/group based on eid.*. When |
36 |
> off, enewuser/enewgroup will stop the build process when the user/group |
37 |
> doesn't exist informing the admin to create it ahead of time? |
38 |
|
39 |
Right, though I would call it "noaccounts" and leave the current behavior |
40 |
as the default. |
41 |
|
42 |
> Lets take it further! Instead of using enewuser/enewgroup, what about |
43 |
> adding two new variables in ebuilds? USERS="user1 user2" and GROUPS="group1 |
44 |
> group2". These have to be defined in eid.* databases. When the merge |
45 |
> process starts, the accounts are either created or the build dies (based on |
46 |
> FEATURES="accounts"). This has a side benefit of being tracked per package |
47 |
> in the portage database and these accounts can be removed when the final |
48 |
> version of the package is unmerged (based on the "accounts" feature, of |
49 |
> course). Thoughts from the portage folk? |
50 |
|
51 |
This is more than I was asking, but it's not a bad idea. |
52 |
|
53 |
-- |
54 |
gentoo-dev@g.o mailing list |