Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Using users/groups from another recipe than the one creating them
Date: Mon, 9 Jun 2014 16:56:52 +0200	[thread overview]
Message-ID: <20140609145652.GB2433@jama> (raw)
In-Reply-To: <5395C9AF.20907@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 4412 bytes --]

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: openembedded-core-bounces@lists.openembedded.org
> >>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> >>> Peter Kjellerstedt
> >>> Sent: den 23 maj 2014 12:38
> >>> To: OE Core (openembedded-core@lists.openembedded.org)
> >>> Subject: Re: [OE-core] Using users/groups from another recipe than the
> >>> one creating them
> >>>
> >>>> -----Original Message-----
> >>>> From: openembedded-core-bounces@lists.openembedded.org
> >>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> >>>> Of Peter Kjellerstedt
> >>>> Sent: den 19 maj 2014 10:15
> >>>> To: OE Core (openembedded-core@lists.openembedded.org)
> >>>> 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
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2014-06-09 14:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23 10:38 Using users/groups from another recipe than the one creating them Peter Kjellerstedt
2014-06-09 13:39 ` Peter Kjellerstedt
2014-06-09 13:52   ` Martin Jansa
2014-06-09 14:50     ` Mark Hatle
2014-06-09 14:56       ` Martin Jansa [this message]
2014-06-09 14:47   ` Mark Hatle
2014-06-09 16:47     ` Peter Kjellerstedt
2014-06-09 17:02       ` Mark Hatle
2014-06-10 10:04         ` Peter Kjellerstedt
  -- strict thread matches above, loose matches on Subject: below --
2014-05-19  8:14 Peter Kjellerstedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140609145652.GB2433@jama \
    --to=martin.jansa@gmail.com \
    --cc=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox