On Mon, Jun 09, 2014 at 09:50:23AM -0500, Mark Hatle wrote: > On 6/9/14, 8:52 AM, Martin Jansa wrote: > > On Mon, Jun 09, 2014 at 03:39:46PM +0200, Peter Kjellerstedt wrote: > >>> -----Original Message----- > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of > >>> Peter Kjellerstedt > >>> Sent: den 23 maj 2014 12:38 > >>> To: OE Core ([email protected]) > >>> Subject: Re: [OE-core] Using users/groups from another recipe than the > >>> one creating them > >>> > >>>> -----Original Message----- > >>>> From: [email protected] > >>>> [mailto:[email protected]] On Behalf > >>>> Of Peter Kjellerstedt > >>>> Sent: den 19 maj 2014 10:15 > >>>> To: OE Core ([email protected]) > >>>> Subject: [OE-core] Using users/groups from another recipe than the > >>>> one creating them > >>>> > >>>> Which assumption is correct: "a recipe A that depends on another > >>>> recipe B can use users/groups that B creates" or "all recipes must > >>>> create the users/groups they require themselves"? > >>>> > >>>> The problem for us is that we have a lot of recipes that create > >>>> users and groups, and subsequently a number of other related recipes > >>>> that need to use those users and groups. > >>>> > >>>> If the first assumption is correct then the useradd.bbclass needs to > >>>> be corrected so that it adds a dependency from do_install to > >>>> base-passwd:do_populate_sysroot and > >>>> base-passwd:do_populate_sysroot_setscene, because if either of those > >>>> tasks execute they will overwrite /etc/passwd and /etc/group, > >>>> effectively removing any users/groups that were created earlier... > >>>> > >>>> On the other hand, if it is the second assumption that is correct, > >>>> then there should be QA tests in place to make sure all recipes > >>>> create the users/groups they use. > >>>> > >>>> //Peter > >>> > >>> *ping* > >>> > >>> Doesn't anyone know how users and groups are supposed to work? > >>> > >>> //Peter > >> > >> *ping again* > >> > >> Well, this is somewhat discouraging. Three weeks and not a single > >> response. Are we really the only ones that care about users and > >> groups and how they are created? Doesn't anyone know which of my > >> two assumptions above are correct? > >> > >> Personally I would prefer that all recipes create the users and > >> groups they require themselves as this keeps them more self > >> contained. I have no idea how to write a QA test to verify this, > >> but I assume it should be possible... > > > > My experience from Dylan release is that only users/groups created in > > base-passwd work reliably, with useradd.bbclass we were seeing random > > files getting random user/group owners (comparing buildhistory report > > files-in-image.txt from multiple builds which weren't using sstate). > > > > Which package management type?
ipk > The only issue I'm aware of is when the requires aren't in the correct order, > a > package can fall back and try to use the host-system's passwd/group entries > instead of the sysroot version. This can lead to cases that during the > installation process the dynamic users/groups have not been generated due to > missing dependencies. Those random files were also the files which are usually owned by root:root, so it wasn't like incorrectly using users/groups from host system. Maybe something in pseudo db got broken, but after finding the work around with creating all required users from base-passwd I didn't try to debug it more. > For the RPM type, you get a message that says "user foo can not be found, > using > root". I'm not sure what deb/ipk do in these cases. (RPM always handles > users > and groups by name, never by gid/uid number.) > > The whole users and groups system has been working very well in my systems > based > on 'dora'. I haven't experienced issues with dylan, but I also haven't used > it > as extensively. > > --Mark > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
