Bugzilla Bug 53269

i'd offer something up but i suck at python

Someone needs to write the DTDs or whatever...
Create the parser and dev-portage cna handle the rest.

*** Bug 58741 has been marked as a duplicate of this bug. ***

*** Bug 78741 has been marked as a duplicate of this bug. ***

*** Bug 42320 has been marked as a duplicate of this bug. ***

*** Bug 107514 has been marked as a duplicate of this bug. ***

*** Bug 134081 has been marked as a duplicate of this bug. ***

*** Bug 135915 has been marked as a duplicate of this bug. ***

*** Bug 113298 has been marked as a duplicate of this bug. ***

*** Bug 113298 has been marked as a duplicate of this bug. ***

*** Bug 142637 has been marked as a duplicate of this bug. ***

*** Bug 149157 has been marked as a duplicate of this bug. ***

*** Bug 149996 has been marked as a duplicate of this bug. ***

*** Bug 169345 has been marked as a duplicate of this bug. ***

*** Bug 170197 has been marked as a duplicate of this bug. ***

*** Bug 171378 has been marked as a duplicate of this bug. ***

*** Bug 184981 has been marked as a duplicate of this bug. ***

*** Bug 180797 has been marked as a duplicate of this bug. ***

[11:32pm] <mkelly32>
also, if anyone wants to take on my glep-27 stuff (really, just needs to be
plugged into portage)
[11:32pm] <mkelly32>
the source is around
[11:33pm] <grobian>
glep27 is?
[11:34pm] <mkelly32>
ENEWUSERS and ENEWGROUPS variables, keeping info for users and groups added by
enewuser/enewgroup in one place
[11:34pm] <mkelly32>
it was my summer of code project a year ago, never got it pushed into portage
[11:34pm] <grobian>
ohw yeah
[11:34pm] <grobian>
I recall that
[11:34pm] <mkelly32>
but i have pretty flowcharts and such showing how to do it
[11:36pm] <mkelly32>
basically, it would be really easy to do if portage had phase hooks, or
something similar, but a patch i wrote for that was rejected at the time
[11:37pm] <mkelly32>
for someone willing to add code for it directly into portage, the flowcharts
and such at
http://www.pioto.org/~pioto/creandus/API.html#public-api-usage-flowchart will
be useful
[11:38pm] <mkelly32>
and code is at svn://svn.pioto.org/creandus
[11:38pm] <mkelly32>
with some samples of stuff from the tree side in the overlay/ dir
[11:40pm] <jakub>
is that something for Bug 53269 ?
[11:40pm] <jeeves>
jakub: https://bugs.gentoo.org/53269 maj, P2, All,
vapier@gentoo.org->dev-portage@gentoo.org, NEW, pending, GLEP 27 needs to be
implemented (Portage Management of UIDs/GIDs)
[11:41pm] <mkelly32>
most likely
[11:41pm] <mkelly32>
i don't think i have an active bugzilla account anymore
[11:41pm] <mkelly32>
so would you mind adding what i said in a comment or something?

*** Bug 207596 has been marked as a duplicate of this bug. ***

*** Bug 219225 has been marked as a duplicate of this bug. ***

What about a quick fix? Give the user a bash-friendly script to install the
necessary things that a certain package needs after the installation.

cp /etc/passwd $ROOT/etc/passwd

Maybe there is another and probably easier way of managing groups and
users in gentoo instead of creandus. I don't know the approach of
creandus and this is just an idea which came into my mind.

What about modifying enewuser and enewgroup in eutils.eclass to manage a
few files which store information about groups and users.

/etc/portage/groups/{system,pm,local}
/etc/portage/users/{system,pm,local}

Where system is for the default set of groups/users coming with the
releases. pm for the ones needed by installed ebuilds and managed by
the package manager and local for software installed without the control
of the package manager controlled by the user.

Of course the names and locations are just an example. Maybe system
should go into the profiles and pm somewhere to /etc.

When software is installed by an ebuild, the pm file is updated with
the package which needs a group/user. If it is the first ebuild which
needs a particular group/user etc/{passwd, shadow, group} are updated
accordingly.

Every time an ebuild is unmerged which needs a group/user the pm file is
checked if there is still a need for the group/user. When there is no
entry for the group/user left, the group/user is removed from
/etc/{passwd, shadow, group}.

Of course the other files are taken into account for every operation.

The file could simply look like this:

Sample for users/pm:

Ebuild:         User:
cat1-pkg1-ver1  user1; user4
cat1-pkg1-ver2  user1
cat1-pkg2-ver1  user2
cat2-pkg1-ver1  user3

or

User:           Ebuild:
user1           cat1-pkg1-ver1, cat1-pkg1-ver2
user2           cat1-pkg2-ver1
user3           cat2-pkg1-ver1
user4           cat1-pkg1-ver1

cat/pkg-ver has to be stored in the file because of packages installed
more then one time because they are slotted.

To get the initial database every ebuild which invokes enewuser and
enewgroup needs a revision bump? There are also ebuilds which are using
this functions not directly but via eclass like the the ebuilds using
the games.eclass

Any comments on this? Am I missing something important why this is not
easy to implement? I am just trying to help and as can not help by
coding I try to help with ideas. Maybe it is a good approach maybe it is
crap, but I think it is at least worth to mention it.

Regards,

Daniel

Is there a reason for UID and GID to be hardcoded into ebuilds? Because if not,
that would make the implementation of GLEP 27 a lot easier: just get the first
system UID/GID available.
The Linux Standard Base has something to say about it:
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/uidrange.html
So system accounts should be dynamically assigned. On the other hand, this only
applies to Linux. Don't know about BSD or other systems.

(In reply to comment #24)
> Is there a reason for UID and GID to be hardcoded into ebuilds? Because if not,
> that would make the implementation of GLEP 27 a lot easier: just get the first
> system UID/GID available.
> The Linux Standard Base has something to say about it:
> http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/uidrange.html
> So system accounts should be dynamically assigned. On the other hand, this only
> applies to Linux. Don't know about BSD or other systems.
> 

Some of us have more than 1 system and would prefer that the
apache/mail/$OTHER_CRITICAL user be the same UID on every system we have.

-Alec

(In reply to comment #25)
> (In reply to comment #24)
> > Is there a reason for UID and GID to be hardcoded into ebuilds? Because if not,
> > that would make the implementation of GLEP 27 a lot easier: just get the first
> > system UID/GID available.
> > The Linux Standard Base has something to say about it:
> > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/uidrange.html
> > So system accounts should be dynamically assigned. On the other hand, this only
> > applies to Linux. Don't know about BSD or other systems.
> > 
> 
> Some of us have more than 1 system and would prefer that the
> apache/mail/$OTHER_CRITICAL user be the same UID on every system we have.
> 
> -Alec
> 

But that should be managed by servies like nis or ldap, not the package
manager.

please read the glep entirely.  your concern about static vs dynamic vs user
policy is already fully accounted for.

First, I'd like to say that I'm not trying to be a smartass and I'm no Gentoo
Developer. And I don't have any knowledge of which is the process to aprove a
GLEP. I don't even know if this is the right place to write! I've never done
this before.
I'm just another Gentoo user who happens to like this distro a lot and wants to
make it as better as possible. That's why I'm voicing my opinion, which is just
that: an opinion. So plese, don't get mad if I have some doubts on this GLEP.

(In reply to comment #27)
> please read the glep entirely.  your concern about static vs dynamic vs user
> policy is already fully accounted for.
> 

Yes I did, but still have some concerns about it. Forcing that behaviour upon
portage introduces a bunch of problems.
-First, this makes the implementation of portage more difficult without an
actual need. That was the point of my first message.
-Second, it ignores LSB and I think that's serious.
-As far as I cant tell, GLEP 27 is specifying the solution to a problem solved
and implemented long ago by the internal user management tools of each
distro/system (useradd in Linux, I bet BSD has something similar). Implementing
it again adds a burden to developers, (type the code, test and mantain it) and
users. For instance: I want to change the way UID/GID are assigned on my
system. On any linux distro, I just have to edit /etc/login.defs. In
Gentoo+GLEP27, I'd have to edit /etc/login.defs AND portage's config files.
This puts Gentoo on a worse situation than other OS because makes everything
more complicated.

To sum up: keeping track of the users/groups created by portage is a great
idea, but enforcing it's assignment isn't. That should be done by the
corresponding system tools, and enewuser/group already use them (they may need
to be fine tuned, though).

On the other hand, you could enforce the UID/GID assignment for ALL the ebuilds
if it's so important. Just create and maintain a list of all Gentoo services
and their corresponding xID, which means more work and would make some options
unadjustable for the user (in fact, some already are). But I still think that's
a better option than mixing both policies.

Again, this is just my point of view on the policy specified in GLEP 27, which
I hope is not set in stone.

I want to avoid a long conversation on this bug.

If you have a problem with a glep, talk to mike or provide a diff.

If you and mike fundamentally disagree, write a competing GLEP and get it
approved and then implemented.

No one has implemented glep 27, so at its core what it says is not really
useful (since none of it applies in real life)

This bug is about implementing said GLEP, not about the glep itself.  There are
a number of places you can have that conversation (email with mike, the
gentoo-dev list, a separate bug marked as a blocker of this bug, and so forth.)

And yeah I'm being a bit pedantic, sorry for that :/

(and to be clear, I don't care one way or another how this gets done, or even
if it gets done)

-Alec

*** Bug 266246 has been marked as a duplicate of this bug. ***

*** Bug 253754 has been marked as a duplicate of this bug. ***