useradd.bbclass question

useradd.bbclass question

[Andreas Müller]

Hi,

on one of my build machines useradd.bbclass seem to use the UID/GID of
build host. On other machines useradd works correct.

I have the follwing in gdm:

<snip>
do_install_append() {
    ...
    chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
    chmod 0750 ${D}${localstatedir}/lib/gdm
}

...

USERADD_PACKAGES = "${PN}"
USERADD_PARAM_${PN} = "--system --no-create-home --home
${localstatedir}/lib/gdm --user-group gdm"
<snip/>

In sysroot /etc/group I see
gdm:x:990:

In sysroot /etc/group I see
gdm:!:993:990::/var/lib/gdm:

The folder in packet/image has IDs 42:42 which is taken from build host.

Any ideas what causes this - or is there something wrong with chown at
do_install?

Andreas

Re: useradd.bbclass question

[Mark Hatle]

On 5/2/13 2:49 AM, Andreas Müller wrote:
> Hi,
>
> on one of my build machines useradd.bbclass seem to use the UID/GID of
> build host. On other machines useradd works correct.
>
> I have the follwing in gdm:
>
> <snip>
> do_install_append() {
>      ...
>      chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>      chmod 0750 ${D}${localstatedir}/lib/gdm
> }
>
> ...
>
> USERADD_PACKAGES = "${PN}"
> USERADD_PARAM_${PN} = "--system --no-create-home --home
> ${localstatedir}/lib/gdm --user-group gdm"
> <snip/>
>
> In sysroot /etc/group I see
> gdm:x:990:
>
> In sysroot /etc/group I see
> gdm:!:993:990::/var/lib/gdm:
>
> The folder in packet/image has IDs 42:42 which is taken from build host.

This says that something ran an operation outside of the pseudo environment.  So 
it fell back to looking up the uid from the host system.  (The alternative is 
the item was installed -before- the /etc/passwd,/etc/group was written to the 
disk.  If that happens, pseudo can also fall back to the system environment.)

> Any ideas what causes this - or is there something wrong with chown at
> do_install?
>
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: useradd.bbclass question

[Paul Eggleton]

On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> On 5/2/13 2:49 AM, Andreas Müller wrote:
> > on one of my build machines useradd.bbclass seem to use the UID/GID of
> > build host. On other machines useradd works correct.
> > 
> > I have the follwing in gdm:
> > 
> > <snip>
> > do_install_append() {
> > 
> >      ...
> >      chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
> >      chmod 0750 ${D}${localstatedir}/lib/gdm
> > 
> > }
> > 
> > ...
> > 
> > USERADD_PACKAGES = "${PN}"
> > USERADD_PARAM_${PN} = "--system --no-create-home --home
> > ${localstatedir}/lib/gdm --user-group gdm"
> > <snip/>
> > 
> > In sysroot /etc/group I see
> > gdm:x:990:
> > 
> > In sysroot /etc/group I see
> > gdm:!:993:990::/var/lib/gdm:
> > 
> > The folder in packet/image has IDs 42:42 which is taken from build host.
> 
> This says that something ran an operation outside of the pseudo environment.
>  So it fell back to looking up the uid from the host system.  (The
> alternative is the item was installed -before- the /etc/passwd,/etc/group
> was written to the disk.

Right, do_install will be well before this stuff happens and it is not a 
fakeroot task anyway. This needs to be moved to a postinstall script (which 
should be able to run during image creation).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 4:34 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>> > on one of my build machines useradd.bbclass seem to use the UID/GID of
>> > build host. On other machines useradd works correct.
>> >
>> > I have the follwing in gdm:
>> >
>> > <snip>
>> > do_install_append() {
>> >
>> >      ...
>> >      chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>> >      chmod 0750 ${D}${localstatedir}/lib/gdm
>> >
>> > }
>> >
>> > ...
>> >
>> > USERADD_PACKAGES = "${PN}"
>> > USERADD_PARAM_${PN} = "--system --no-create-home --home
>> > ${localstatedir}/lib/gdm --user-group gdm"
>> > <snip/>
>> >
>> > In sysroot /etc/group I see
>> > gdm:x:990:
>> >
>> > In sysroot /etc/group I see
>> > gdm:!:993:990::/var/lib/gdm:
>> >
>> > The folder in packet/image has IDs 42:42 which is taken from build host.
>>
>> This says that something ran an operation outside of the pseudo environment.
>>  So it fell back to looking up the uid from the host system.  (The
>> alternative is the item was installed -before- the /etc/passwd,/etc/group
>> was written to the disk.
>
> Right, do_install will be well before this stuff happens and it is not a
> fakeroot task anyway. This needs to be moved to a postinstall script (which
> should be able to run during image creation).
>
> Cheers,
> Paul
>
Did this change - it is mentioned this way in

meta-skeleton/recipes-skeleton/useradd/useradd-example.bb

Andreas

Re: useradd.bbclass question

[Richard Purdie]

On Thu, 2013-05-02 at 15:34 +0100, Paul Eggleton wrote:
> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> > On 5/2/13 2:49 AM, Andreas Müller wrote:
> > > on one of my build machines useradd.bbclass seem to use the UID/GID of
> > > build host. On other machines useradd works correct.
> > > 
> > > I have the follwing in gdm:
> > > 
> > > <snip>
> > > do_install_append() {
> > > 
> > >      ...
> > >      chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
> > >      chmod 0750 ${D}${localstatedir}/lib/gdm
> > > 
> > > }
> > > 
> > > ...
> > > 
> > > USERADD_PACKAGES = "${PN}"
> > > USERADD_PARAM_${PN} = "--system --no-create-home --home
> > > ${localstatedir}/lib/gdm --user-group gdm"
> > > <snip/>
> > > 
> > > In sysroot /etc/group I see
> > > gdm:x:990:
> > > 
> > > In sysroot /etc/group I see
> > > gdm:!:993:990::/var/lib/gdm:
> > > 
> > > The folder in packet/image has IDs 42:42 which is taken from build host.
> > 
> > This says that something ran an operation outside of the pseudo environment.
> >  So it fell back to looking up the uid from the host system.  (The
> > alternative is the item was installed -before- the /etc/passwd,/etc/group
> > was written to the disk.
> 
> Right, do_install will be well before this stuff happens and it is not a 
> fakeroot task anyway. This needs to be moved to a postinstall script (which 
> should be able to run during image creation).

Er, yes, do_install is a fakeroot task and you should be able to make
something like this work from do_install. We went to a lot of effort to
ensure the preinst scripts work correctly (see dbus as an example recipe
that uses this).

Cheers,

Richard

Re: useradd.bbclass question

[Paul Eggleton]

On Thursday 02 May 2013 15:49:39 Richard Purdie wrote:
> On Thu, 2013-05-02 at 15:34 +0100, Paul Eggleton wrote:
> > Right, do_install will be well before this stuff happens and it is not a
> > fakeroot task anyway. This needs to be moved to a postinstall script
> > (which
> > should be able to run during image creation).
> 
> Er, yes, do_install is a fakeroot task and you should be able to make
> something like this work from do_install. We went to a lot of effort to
> ensure the preinst scripts work correctly (see dbus as an example recipe
> that uses this).

Oops. I'll have to admit that I assumed this without checking. Andreas, please 
ignore my advice.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: useradd.bbclass question

[Mark Hatle]

On 5/2/13 9:34 AM, Paul Eggleton wrote:
> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>> build host. On other machines useradd works correct.
>>>
>>> I have the follwing in gdm:
>>>
>>> <snip>
>>> do_install_append() {
>>>
>>>       ...
>>>       chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>       chmod 0750 ${D}${localstatedir}/lib/gdm
>>>
>>> }
>>>
>>> ...
>>>
>>> USERADD_PACKAGES = "${PN}"
>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>> ${localstatedir}/lib/gdm --user-group gdm"
>>> <snip/>

I don't know how ipk and deb handle this.  But with the RPM system it captures 
the uname/gname (not uid/gid) and uses that when installing the file(s).  This 
way the USERADD is processed before the install and the right value is used 
during the install.

We may have a problem here where we need to also process the useradd -before- 
the do_install runs so that it's available for pseudo to use for deb/ipk.  (But 
if deb/ipk capture uid/gid vs uname/gname..  unless we set a static value we 
could still have a problem.)

Does anyone know how ipk/deb handle this?

>>>
>>> In sysroot /etc/group I see
>>> gdm:x:990:
>>>
>>> In sysroot /etc/group I see
>>> gdm:!:993:990::/var/lib/gdm:
>>>
>>> The folder in packet/image has IDs 42:42 which is taken from build host.
>>
>> This says that something ran an operation outside of the pseudo environment.
>>   So it fell back to looking up the uid from the host system.  (The
>> alternative is the item was installed -before- the /etc/passwd,/etc/group
>> was written to the disk.
>
> Right, do_install will be well before this stuff happens and it is not a
> fakeroot task anyway. This needs to be moved to a postinstall script (which
> should be able to run during image creation).

do_install is a 'fakeroot' task.  But ya, the useradd action doesn't necessarily 
happen before it.

We should -not- be using a postinstall action to change user/groups on 
files/directories.  This breaks the integrity checking that RPM has.  You can 
(on the target) issue an rpm -V <package> and it will go and verify the 
installed files (including permissions, user, group) match what the RPM database 
says.  Making the change in a postinstall will cause a validation failure.

--Mark

> Cheers,
> Paul
>

Re: useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>
>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>
>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>
>>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>>> build host. On other machines useradd works correct.
>>>>
>>>> I have the follwing in gdm:
>>>>
>>>> <snip>
>>>> do_install_append() {
>>>>
>>>>       ...
>>>>       chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>       chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>
>>>> }
>>>>
>>>> ...
>>>>
>>>> USERADD_PACKAGES = "${PN}"
>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>> <snip/>
>
>
> I don't know how ipk and deb handle this.  But with the RPM system it
> captures the uname/gname (not uid/gid) and uses that when installing the
> file(s).  This way the USERADD is processed before the install and the right
> value is used during the install.
>
> We may have a problem here where we need to also process the useradd
> -before- the do_install runs so that it's available for pseudo to use for
> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we set a
> static value we could still have a problem.)
1. gdm's log.do_install starts with so I assume the useradd stuff is
performed before do_install.

| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
| DEBUG: Executing shell function useradd_sysroot
| Running useradd commands...
| DEBUG: Shell function useradd_sysroot finished
| DEBUG: Executing shell function do_install

2. I did a cleansstate + rebuild for gdm to ensure that user/groups
are in sysroot - but the same I get host's IDs

Andreas

Re: useradd.bbclass question

[Mark Hatle]

On 5/2/13 9:55 AM, Andreas Müller wrote:
> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>>
>>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>>
>>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>>
>>>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>>>> build host. On other machines useradd works correct.
>>>>>
>>>>> I have the follwing in gdm:
>>>>>
>>>>> <snip>
>>>>> do_install_append() {
>>>>>
>>>>>        ...
>>>>>        chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>>        chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>>
>>>>> }
>>>>>
>>>>> ...
>>>>>
>>>>> USERADD_PACKAGES = "${PN}"
>>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>>> <snip/>
>>
>>
>> I don't know how ipk and deb handle this.  But with the RPM system it
>> captures the uname/gname (not uid/gid) and uses that when installing the
>> file(s).  This way the USERADD is processed before the install and the right
>> value is used during the install.
>>
>> We may have a problem here where we need to also process the useradd
>> -before- the do_install runs so that it's available for pseudo to use for
>> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we set a
>> static value we could still have a problem.)
> 1. gdm's log.do_install starts with so I assume the useradd stuff is
> performed before do_install.
>
> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> | DEBUG: Executing shell function useradd_sysroot
> | Running useradd commands...
> | DEBUG: Shell function useradd_sysroot finished
> | DEBUG: Executing shell function do_install

Ahh yes, there it is.. I forgot as well.

ok, so the obvious problems are resolved.  The only place I can suggest you 
start looking would be in the sysroot's etc/passwd and etc/group files.  If they 
are not correct -- then this indicates a failure in the easy case and could lead 
to incorrect values.

The other thing you can do is add debugging to your script and see what uid and 
such it's looking for.. Dumping out the environment variables that start with 
'PSEUDO_' may help.  I believe the value is PSEUDO_PASSWD for the path.  If it's 
not set it falls back to the chroot (which you won't be in) and then back to the 
system file --- so if PSEUDO_PASSWD isn't set this could be a clue as to the fault.

--Mark

> 2. I did a cleansstate + rebuild for gdm to ensure that user/groups
> are in sysroot - but the same I get host's IDs
>
> Andreas
>

Re: useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>
>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com>
>> wrote:
>>>
>>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>>>
>>>>
>>>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>>>
>>>>>
>>>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>>>
>>>>>>
>>>>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>>>>> build host. On other machines useradd works correct.
>>>>>>
>>>>>> I have the follwing in gdm:
>>>>>>
>>>>>> <snip>
>>>>>> do_install_append() {
>>>>>>
>>>>>>        ...
>>>>>>        chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>>>        chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> USERADD_PACKAGES = "${PN}"
>>>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>>>> <snip/>
>>>
>>>
>>>
>>> I don't know how ipk and deb handle this.  But with the RPM system it
>>> captures the uname/gname (not uid/gid) and uses that when installing the
>>> file(s).  This way the USERADD is processed before the install and the
>>> right
>>> value is used during the install.
>>>
>>> We may have a problem here where we need to also process the useradd
>>> -before- the do_install runs so that it's available for pseudo to use for
>>> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we set
>>> a
>>> static value we could still have a problem.)
>>
>> 1. gdm's log.do_install starts with so I assume the useradd stuff is
>> performed before do_install.
>>
>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>> 'common']
>> | DEBUG: Executing shell function useradd_sysroot
>> | Running useradd commands...
>> | DEBUG: Shell function useradd_sysroot finished
>> | DEBUG: Executing shell function do_install
>
>
> Ahh yes, there it is.. I forgot as well.
>
> ok, so the obvious problems are resolved.  The only place I can suggest you
> start looking would be in the sysroot's etc/passwd and etc/group files.  If
> they are not correct -- then this indicates a failure in the easy case and
> could lead to incorrect values.
These are OK and as mentioned above (cleansstate/rebuild) definitely
prepared before do_install.
>
> The other thing you can do is add debugging to your script and see what uid
> and such it's looking for.. Dumping out the environment variables that start
> with 'PSEUDO_' may help.  I believe the value is PSEUDO_PASSWD for the path.
> If it's not set it falls back to the chroot (which you won't be in) and then
> back to the system file --- so if PSEUDO_PASSWD isn't set this could be a
> clue as to the fault.
>
I will check that - still strange to me is that I have different
behaviour for two hosts - both with gdm user/group.

Andreas

Re: useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>>
>>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>>>
>>>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>>>>
>>>>>
>>>>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>>>>
>>>>>>
>>>>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>>>>
>>>>>>>
>>>>>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>>>>>> build host. On other machines useradd works correct.
>>>>>>>
>>>>>>> I have the follwing in gdm:
>>>>>>>
>>>>>>> <snip>
>>>>>>> do_install_append() {
>>>>>>>
>>>>>>>        ...
>>>>>>>        chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>>>>        chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> USERADD_PACKAGES = "${PN}"
>>>>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>>>>> <snip/>
>>>>
>>>>
>>>>
>>>> I don't know how ipk and deb handle this.  But with the RPM system it
>>>> captures the uname/gname (not uid/gid) and uses that when installing the
>>>> file(s).  This way the USERADD is processed before the install and the
>>>> right
>>>> value is used during the install.
>>>>
>>>> We may have a problem here where we need to also process the useradd
>>>> -before- the do_install runs so that it's available for pseudo to use for
>>>> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we set
>>>> a
>>>> static value we could still have a problem.)
>>>
>>> 1. gdm's log.do_install starts with so I assume the useradd stuff is
>>> performed before do_install.
>>>
>>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>>> 'common']
>>> | DEBUG: Executing shell function useradd_sysroot
>>> | Running useradd commands...
>>> | DEBUG: Shell function useradd_sysroot finished
>>> | DEBUG: Executing shell function do_install
>>
>>
>> Ahh yes, there it is.. I forgot as well.
>>
>> ok, so the obvious problems are resolved.  The only place I can suggest you
>> start looking would be in the sysroot's etc/passwd and etc/group files.  If
>> they are not correct -- then this indicates a failure in the easy case and
>> could lead to incorrect values.
> These are OK and as mentioned above (cleansstate/rebuild) definitely
> prepared before do_install.
>>
>> The other thing you can do is add debugging to your script and see what uid
>> and such it's looking for.. Dumping out the environment variables that start
>> with 'PSEUDO_' may help.  I believe the value is PSEUDO_PASSWD for the path.
>> If it's not set it falls back to the chroot (which you won't be in) and then
>> back to the system file --- so if PSEUDO_PASSWD isn't set this could be a
>> clue as to the fault.
[andreas@oe-core]$ bitbake -e gdm | grep ^PSEUDO_PASSWD
PSEUDO_PASSWD="/home/andreas/tmp/oe-core-eglibc/sysroots/overo"
>>
> I will check that - still strange to me is that I have different
> behaviour for two hosts - both with gdm user/group.
>
> Andreas

Re: useradd.bbclass question

[Mark Hatle]

On 5/2/13 10:31 AM, Andreas Müller wrote:
> On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>>>
>>>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com>
>>>> wrote:
>>>>>
>>>>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>>>>>
>>>>>>
>>>>>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>>>>>>> build host. On other machines useradd works correct.
>>>>>>>>
>>>>>>>> I have the follwing in gdm:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>> do_install_append() {
>>>>>>>>
>>>>>>>>         ...
>>>>>>>>         chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>>>>>         chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> USERADD_PACKAGES = "${PN}"
>>>>>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>>>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>>>>>> <snip/>
>>>>>
>>>>>
>>>>>
>>>>> I don't know how ipk and deb handle this.  But with the RPM system it
>>>>> captures the uname/gname (not uid/gid) and uses that when installing the
>>>>> file(s).  This way the USERADD is processed before the install and the
>>>>> right
>>>>> value is used during the install.
>>>>>
>>>>> We may have a problem here where we need to also process the useradd
>>>>> -before- the do_install runs so that it's available for pseudo to use for
>>>>> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we set
>>>>> a
>>>>> static value we could still have a problem.)
>>>>
>>>> 1. gdm's log.do_install starts with so I assume the useradd stuff is
>>>> performed before do_install.
>>>>
>>>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>>>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>>>> 'common']
>>>> | DEBUG: Executing shell function useradd_sysroot
>>>> | Running useradd commands...
>>>> | DEBUG: Shell function useradd_sysroot finished
>>>> | DEBUG: Executing shell function do_install
>>>
>>>
>>> Ahh yes, there it is.. I forgot as well.
>>>
>>> ok, so the obvious problems are resolved.  The only place I can suggest you
>>> start looking would be in the sysroot's etc/passwd and etc/group files.  If
>>> they are not correct -- then this indicates a failure in the easy case and
>>> could lead to incorrect values.
>> These are OK and as mentioned above (cleansstate/rebuild) definitely
>> prepared before do_install.
>>>
>>> The other thing you can do is add debugging to your script and see what uid
>>> and such it's looking for.. Dumping out the environment variables that start
>>> with 'PSEUDO_' may help.  I believe the value is PSEUDO_PASSWD for the path.
>>> If it's not set it falls back to the chroot (which you won't be in) and then
>>> back to the system file --- so if PSEUDO_PASSWD isn't set this could be a
>>> clue as to the fault.
> [andreas@oe-core]$ bitbake -e gdm | grep ^PSEUDO_PASSWD
> PSEUDO_PASSWD="/home/andreas/tmp/oe-core-eglibc/sysroots/overo"

Check that path contains 'etc/passwd' and 'etc/group'.  If not, that would be 
the issue.. if it does contain them -- then something else is happening.

--Mark

>>>
>> I will check that - still strange to me is that I have different
>> behaviour for two hosts - both with gdm user/group.
>>
>> Andreas

Re: useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 5:53 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 5/2/13 10:31 AM, Andreas Müller wrote:
>>
>> On Thu, May 2, 2013 at 5:18 PM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>>
>>> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>>>
>>>> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>>>>
>>>>>
>>>>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> on one of my build machines useradd.bbclass seem to use the UID/GID
>>>>>>>>> of
>>>>>>>>> build host. On other machines useradd works correct.
>>>>>>>>>
>>>>>>>>> I have the follwing in gdm:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>> do_install_append() {
>>>>>>>>>
>>>>>>>>>         ...
>>>>>>>>>         chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>>>>>>         chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> USERADD_PACKAGES = "${PN}"
>>>>>>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>>>>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>>>>>>> <snip/>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don't know how ipk and deb handle this.  But with the RPM system it
>>>>>> captures the uname/gname (not uid/gid) and uses that when installing
>>>>>> the
>>>>>> file(s).  This way the USERADD is processed before the install and the
>>>>>> right
>>>>>> value is used during the install.
>>>>>>
>>>>>> We may have a problem here where we need to also process the useradd
>>>>>> -before- the do_install runs so that it's available for pseudo to use
>>>>>> for
>>>>>> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we
>>>>>> set
>>>>>> a
>>>>>> static value we could still have a problem.)
>>>>>
>>>>>
>>>>> 1. gdm's log.do_install starts with so I assume the useradd stuff is
>>>>> performed before do_install.
>>>>>
>>>>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>>>>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>>>>> 'common']
>>>>> | DEBUG: Executing shell function useradd_sysroot
>>>>> | Running useradd commands...
>>>>> | DEBUG: Shell function useradd_sysroot finished
>>>>> | DEBUG: Executing shell function do_install
>>>>
>>>>
>>>>
>>>> Ahh yes, there it is.. I forgot as well.
>>>>
>>>> ok, so the obvious problems are resolved.  The only place I can suggest
>>>> you
>>>> start looking would be in the sysroot's etc/passwd and etc/group files.
>>>> If
>>>> they are not correct -- then this indicates a failure in the easy case
>>>> and
>>>> could lead to incorrect values.
>>>
>>> These are OK and as mentioned above (cleansstate/rebuild) definitely
>>> prepared before do_install.
>>>>
>>>>
>>>> The other thing you can do is add debugging to your script and see what
>>>> uid
>>>> and such it's looking for.. Dumping out the environment variables that
>>>> start
>>>> with 'PSEUDO_' may help.  I believe the value is PSEUDO_PASSWD for the
>>>> path.
>>>> If it's not set it falls back to the chroot (which you won't be in) and
>>>> then
>>>> back to the system file --- so if PSEUDO_PASSWD isn't set this could be
>>>> a
>>>> clue as to the fault.
>>
>> [andreas@oe-core]$ bitbake -e gdm | grep ^PSEUDO_PASSWD
>> PSEUDO_PASSWD="/home/andreas/tmp/oe-core-eglibc/sysroots/overo"
>
>
> Check that path contains 'etc/passwd' and 'etc/group'.  If not, that would
> be the issue.. if it does contain them -- then something else is happening.
Yes the path is correct and contains both files with correct IDs

> Hmm.. are either of the hosts 32-bit/64-bit multilib installs?  If so, you need to ensure that pseudo is enabled to build both
> a 32-bit and 64-bit wrapper, otherwise you can end up running native software that won't be wrapper properly.  (It's fairly
> rare, but can occur.)

I think both are multilib - have /lib and /lib64 and found same libs
in both. How do I ensure that both wrappers are build?

Andreas

Re: useradd.bbclass question

[Andreas Müller]

On Thu, May 2, 2013 at 6:40 PM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Thu, May 2, 2013 at 5:53 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> [andreas@oe-core]$ bitbake -e gdm | grep ^PSEUDO_PASSWD
>>> PSEUDO_PASSWD="/home/andreas/tmp/oe-core-eglibc/sysroots/overo"
>>
>>
>> Check that path contains 'etc/passwd' and 'etc/group'.  If not, that would
>> be the issue.. if it does contain them -- then something else is happening.
> Yes the path is correct and contains both files with correct IDs
>
>> Hmm.. are either of the hosts 32-bit/64-bit multilib installs?  If so, you need to ensure that pseudo is enabled to build both
>> a 32-bit and 64-bit wrapper, otherwise you can end up running native software that won't be wrapper properly.  (It's fairly
>> rare, but can occur.)
>
> I think both are multilib - have /lib and /lib64 and found same libs
> in both. How do I ensure that both wrappers are build?
>
One thing I just noticed - maybe it has nothing to do with the problem
- concerning build from scratch:

* On the host creating images with correct IDs there are three groups
(=new parsing) of tasks performed:
    1. pseudo
    2. ??
    3. image
* On the host with incorrect IDs I see only parsing for pseudo and image

In case it has nothing to do with the problem - just for me to
understand: What is the second task group for?

Andreas

Re: useradd.bbclass question

[Mark Hatle]

On 5/2/13 10:18 AM, Andreas Müller wrote:
> On Thu, May 2, 2013 at 5:09 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 5/2/13 9:55 AM, Andreas Müller wrote:
>>>
>>> On Thu, May 2, 2013 at 4:50 PM, Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>>>
>>>> On 5/2/13 9:34 AM, Paul Eggleton wrote:
>>>>>
>>>>>
>>>>> On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
>>>>>>
>>>>>>
>>>>>> On 5/2/13 2:49 AM, Andreas Müller wrote:
>>>>>>>
>>>>>>>
>>>>>>> on one of my build machines useradd.bbclass seem to use the UID/GID of
>>>>>>> build host. On other machines useradd works correct.
>>>>>>>
>>>>>>> I have the follwing in gdm:
>>>>>>>
>>>>>>> <snip>
>>>>>>> do_install_append() {
>>>>>>>
>>>>>>>         ...
>>>>>>>         chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
>>>>>>>         chmod 0750 ${D}${localstatedir}/lib/gdm
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> USERADD_PACKAGES = "${PN}"
>>>>>>> USERADD_PARAM_${PN} = "--system --no-create-home --home
>>>>>>> ${localstatedir}/lib/gdm --user-group gdm"
>>>>>>> <snip/>
>>>>
>>>>
>>>>
>>>> I don't know how ipk and deb handle this.  But with the RPM system it
>>>> captures the uname/gname (not uid/gid) and uses that when installing the
>>>> file(s).  This way the USERADD is processed before the install and the
>>>> right
>>>> value is used during the install.
>>>>
>>>> We may have a problem here where we need to also process the useradd
>>>> -before- the do_install runs so that it's available for pseudo to use for
>>>> deb/ipk.  (But if deb/ipk capture uid/gid vs uname/gname..  unless we set
>>>> a
>>>> static value we could still have a problem.)
>>>
>>> 1. gdm's log.do_install starts with so I assume the useradd stuff is
>>> performed before do_install.
>>>
>>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>>> 'common']
>>> | DEBUG: Executing shell function useradd_sysroot
>>> | Running useradd commands...
>>> | DEBUG: Shell function useradd_sysroot finished
>>> | DEBUG: Executing shell function do_install
>>
>>
>> Ahh yes, there it is.. I forgot as well.
>>
>> ok, so the obvious problems are resolved.  The only place I can suggest you
>> start looking would be in the sysroot's etc/passwd and etc/group files.  If
>> they are not correct -- then this indicates a failure in the easy case and
>> could lead to incorrect values.
> These are OK and as mentioned above (cleansstate/rebuild) definitely
> prepared before do_install.
>>
>> The other thing you can do is add debugging to your script and see what uid
>> and such it's looking for.. Dumping out the environment variables that start
>> with 'PSEUDO_' may help.  I believe the value is PSEUDO_PASSWD for the path.
>> If it's not set it falls back to the chroot (which you won't be in) and then
>> back to the system file --- so if PSEUDO_PASSWD isn't set this could be a
>> clue as to the fault.
>>
> I will check that - still strange to me is that I have different
> behaviour for two hosts - both with gdm user/group.

Hmm.. are either of the hosts 32-bit/64-bit multilib installs?  If so, you need 
to ensure that pseudo is enabled to build both a 32-bit and 64-bit wrapper, 
otherwise you can end up running native software that won't be wrapper properly. 
  (It's fairly rare, but can occur.)

--Mark

> Andreas
>

Re: useradd.bbclass question

[Richard Purdie]

On Thu, 2013-05-02 at 09:50 -0500, Mark Hatle wrote:
> On 5/2/13 9:34 AM, Paul Eggleton wrote:
> > On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> >> On 5/2/13 2:49 AM, Andreas Müller wrote:
> >>> on one of my build machines useradd.bbclass seem to use the UID/GID of
> >>> build host. On other machines useradd works correct.
> >>>
> >>> I have the follwing in gdm:
> >>>
> >>> <snip>
> >>> do_install_append() {
> >>>
> >>>       ...
> >>>       chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
> >>>       chmod 0750 ${D}${localstatedir}/lib/gdm
> >>>
> >>> }
> >>>
> >>> ...
> >>>
> >>> USERADD_PACKAGES = "${PN}"
> >>> USERADD_PARAM_${PN} = "--system --no-create-home --home
> >>> ${localstatedir}/lib/gdm --user-group gdm"
> >>> <snip/>
> 
> I don't know how ipk and deb handle this.  But with the RPM system it captures 
> the uname/gname (not uid/gid) and uses that when installing the file(s).  This 
> way the USERADD is processed before the install and the right value is used 
> during the install.
> 
> We may have a problem here where we need to also process the useradd -before- 
> the do_install runs so that it's available for pseudo to use for deb/ipk.

No problem, see below.

>   (But 
> if deb/ipk capture uid/gid vs uname/gname..  unless we set a static value we 
> could still have a problem.)
> 
> Does anyone know how ipk/deb handle this?

The same way rpm does. We have a preinst that sets things up before the
files get extracted. The extraction then preserves the users.

> >>>
> >>> In sysroot /etc/group I see
> >>> gdm:x:990:
> >>>
> >>> In sysroot /etc/group I see
> >>> gdm:!:993:990::/var/lib/gdm:
> >>>
> >>> The folder in packet/image has IDs 42:42 which is taken from build host.
> >>
> >> This says that something ran an operation outside of the pseudo environment.
> >>   So it fell back to looking up the uid from the host system.  (The
> >> alternative is the item was installed -before- the /etc/passwd,/etc/group
> >> was written to the disk.
> >
> > Right, do_install will be well before this stuff happens and it is not a
> > fakeroot task anyway. This needs to be moved to a postinstall script (which
> > should be able to run during image creation).
> 
> do_install is a 'fakeroot' task.  But ya, the useradd action doesn't necessarily 
> happen before it.

Yes it does. useradd.bbclass says:

do_install[prefuncs] += "${SYSROOTFUNC}"

and that call sets up the user in advance. pseudo is set to use the
passwd/group files we add the entries to.

So this does all work and is used by dbus.

> We should -not- be using a postinstall action to change user/groups on 
> files/directories.  This breaks the integrity checking that RPM has.  You can 
> (on the target) issue an rpm -V <package> and it will go and verify the 
> installed files (including permissions, user, group) match what the RPM database 
> says.  Making the change in a postinstall will cause a validation failure.

Right.

Cheers,

Richard