| 1 |
Quoting splite-gentoo@××××××××××××××××.edu: |
| 2 |
|
| 3 |
> "I can't eat eggs because I'm allergic." |
| 4 |
> |
| 5 |
> "All the more reason to eat eggs!" |
| 6 |
|
| 7 |
Not quite what I meant. |
| 8 |
|
| 9 |
> Only in the case where all your machines are Gentoo boxes. The uid you |
| 10 |
> just plucked out of eid.passwd may already be used by another OS for an |
| 11 |
> entirely different purpose. Now your sshd is running with httpd's uid, |
| 12 |
> or worse, as a non-system user because, say, Solaris only considers uids |
| 13 |
> under 250 to be system accounts. |
| 14 |
|
| 15 |
Might be my own twisted view, but I can't see the benefit in sharing system |
| 16 |
accounts across different boxes. Mysql database, NIS maps, LDAP, |
| 17 |
what-have-you, can contain just the _user_ accounts. The remaining system |
| 18 |
stuff belongs in /etc/{passwd,group} because different boxes can run |
| 19 |
different services. But I suppose legacy is legacy and hard to break away |
| 20 |
from. |
| 21 |
|
| 22 |
> It's not really a huge undertaking to provide a switch that lets folks do |
| 23 |
> their account management themselves if they need to. I'm not asking that |
| 24 |
> ebuilds should automagically know how to update my NIS maps or talk to |
| 25 |
> your MySQL server. |
| 26 |
|
| 27 |
Something like ... |
| 28 |
|
| 29 |
FEATURES="accounts" (set by default in make.global). When on, |
| 30 |
enewuser/enewgroup will happily create the user/group based on eid.*. When |
| 31 |
off, enewuser/enewgroup will stop the build process when the user/group |
| 32 |
doesn't exist informing the admin to create it ahead of time? |
| 33 |
|
| 34 |
Lets take it further! Instead of using enewuser/enewgroup, what about |
| 35 |
adding two new variables in ebuilds? USERS="user1 user2" and GROUPS="group1 |
| 36 |
group2". These have to be defined in eid.* databases. When the merge |
| 37 |
process starts, the accounts are either created or the build dies (based on |
| 38 |
FEATURES="accounts"). This has a side benefit of being tracked per package |
| 39 |
in the portage database and these accounts can be removed when the final |
| 40 |
version of the package is unmerged (based on the "accounts" feature, of |
| 41 |
course). Thoughts from the portage folk? |
| 42 |
|
| 43 |
-- |
| 44 |
max kalika |
| 45 |
.. public key: http://www.gentoo.org/~max/max.asc |
| 46 |
.. fingerprint: 2D59 74B5 8785 3C22 74F2 87B0 6DD4 E810 CBC3 AB79 |
Archives