Patchwork [2/7] shadow: add a -native recipe with customized utilities

login
register
mail settings
Submitter Phil Blundell
Date Sept. 2, 2011, 9:50 a.m.
Message ID <1314957057.19905.224.camel@phil-desktop>
Download mbox | patch
Permalink /patch/10899/
State New, archived
Headers show

Comments

Phil Blundell - Sept. 2, 2011, 9:50 a.m.
On Thu, 2011-09-01 at 22:59 +0100, Richard Purdie wrote:
> The latter sounds like what we'll need to do. I haven't looked at shadow
> to see what kind of finessing is required though...

Fixing the immediate problem with shadow turned out to be rather
straightforward, see attached.  However, with this done, I now encounter
two new issues.

1. the logic around $D in useradd.bbclass seems to be backwards to me
(and, empirically, isn't working because the supposedly-created users
are not showing up in my rootfs).  Specifically, it does:

        useradd_preinst () {
        OPT=""
        SYSROOT=""
        
        if test "x$D" != "x"; then
        	# Installing into a sysroot
        	SYSROOT="${STAGING_DIR_TARGET}"
        	OPT="--root ${STAGING_DIR_TARGET}"
        
        [...]
        
        useradd_sysroot () {
        	export PSEUDO="${STAGING_DIR_NATIVE}/usr/bin/pseudo"
        	export PSEUDO_LOCALSTATEDIR="${STAGING_DIR_TARGET}/var/pseudo"
        
        	# Explicitly set $D since it isn't set to anything
        	# before do_install
        	D=${D}
        	useradd_preinst
        }

It looks to me as though the code in useradd_preinst() should be using
SYSROOT="$D" (and likewise for OPT), and useradd_sysroot() should be
setting D=${STAGING_DIR_TARGET}.  But maybe there is some clever thing
going on here that I'm not properly understanding.

2. during rootfs construction, the script ordering is wrong.  All the
preinsts run before all the postinsts, which has always been a bit wrong
but hasn't caused too much of a problem in the past.  However,
crucially, this means that the useradd_preinst() runs before
base-passwd's postinst and hence /etc/passwd doesn't exist at the point
where useradd tries to modify it.

I can't think of any reasonable fix for (2) other than to teach
rootfs_ipk how to track package dependencies and run the scripts in the
right order.  I guess that wouldn't be impossible by any means but
trying to do it in a shell script is not a prospect that fills me with a
lot of enthusiasm.  Any better suggestions?

p.
Richard Purdie - Sept. 2, 2011, 2:03 p.m.
On Fri, 2011-09-02 at 10:50 +0100, Phil Blundell wrote:
> On Thu, 2011-09-01 at 22:59 +0100, Richard Purdie wrote:
> > The latter sounds like what we'll need to do. I haven't looked at shadow
> > to see what kind of finessing is required though...
> 
> Fixing the immediate problem with shadow turned out to be rather
> straightforward, see attached.  However, with this done, I now encounter
> two new issues.
> 
> 1. the logic around $D in useradd.bbclass seems to be backwards to me
> (and, empirically, isn't working because the supposedly-created users
> are not showing up in my rootfs).  Specifically, it does:
> 
>         useradd_preinst () {
>         OPT=""
>         SYSROOT=""
>         
>         if test "x$D" != "x"; then
>         	# Installing into a sysroot
>         	SYSROOT="${STAGING_DIR_TARGET}"
>         	OPT="--root ${STAGING_DIR_TARGET}"
>         
>         [...]
>         
>         useradd_sysroot () {
>         	export PSEUDO="${STAGING_DIR_NATIVE}/usr/bin/pseudo"
>         	export PSEUDO_LOCALSTATEDIR="${STAGING_DIR_TARGET}/var/pseudo"
>         
>         	# Explicitly set $D since it isn't set to anything
>         	# before do_install
>         	D=${D}
>         	useradd_preinst
>         }
> 
> It looks to me as though the code in useradd_preinst() should be using
> SYSROOT="$D" (and likewise for OPT), and useradd_sysroot() should be
> setting D=${STAGING_DIR_TARGET}.  But maybe there is some clever thing
> going on here that I'm not properly understanding.

It looks like the useradd_sysroot code will work since D is set to
'something' and then is set correctly in the preinst. What won't work
correctly is the rootfs user creation as you point out.

So I'd agree with your change.

> 2. during rootfs construction, the script ordering is wrong.  All the
> preinsts run before all the postinsts, which has always been a bit wrong
> but hasn't caused too much of a problem in the past.  However,
> crucially, this means that the useradd_preinst() runs before
> base-passwd's postinst and hence /etc/passwd doesn't exist at the point
> where useradd tries to modify it.
> 
> I can't think of any reasonable fix for (2) other than to teach
> rootfs_ipk how to track package dependencies and run the scripts in the
> right order.  I guess that wouldn't be impossible by any means but
> trying to do it in a shell script is not a prospect that fills me with a
> lot of enthusiasm.  Any better suggestions?

Write it in python? ;-)

Seriously, does opkg have the logic in it to run this stuff? If so
perhaps we need to teach opkg about offline postinstalls since it should
already know about dependencies?

Cheers,

Richard
Phil Blundell - Sept. 2, 2011, 6:43 p.m.
On Fri, 2011-09-02 at 15:03 +0100, Richard Purdie wrote:
> Seriously, does opkg have the logic in it to run this stuff? If so
> perhaps we need to teach opkg about offline postinstalls since it should
> already know about dependencies?

Yeah, that might be a sensible plan.  I'm not entirely sure that opkg
even gets the maintainer script ordering right itself during normal
circumstances, but at least it does have a dependency graph so one could
imagine how it might be made to work correctly.  I'll have a poke at
opkg when I get a moment and see if I can figure out how much work would
be involved in that.

How do the RPM-using folks deal with this; does rpm handle everything
automatically?

p.
Mark Hatle - Sept. 2, 2011, 7:17 p.m.
On 9/2/11 1:43 PM, Phil Blundell wrote:
> On Fri, 2011-09-02 at 15:03 +0100, Richard Purdie wrote:
>> Seriously, does opkg have the logic in it to run this stuff? If so
>> perhaps we need to teach opkg about offline postinstalls since it should
>> already know about dependencies?
> 
> Yeah, that might be a sensible plan.  I'm not entirely sure that opkg
> even gets the maintainer script ordering right itself during normal
> circumstances, but at least it does have a dependency graph so one could
> imagine how it might be made to work correctly.  I'll have a poke at
> opkg when I get a moment and see if I can figure out how much work would
> be involved in that.
> 
> How do the RPM-using folks deal with this; does rpm handle everything
> automatically?

RPM uses the dependency mappings that have the pre and post tags on them..
(Note, these are tags that we do not presently use in OE, as OE has no
equivalent to them.)  Without the pre/post dependency tags it assumes the
dependencies are met and can run through the scripts in an arbitrary order.

(For package_rpm.bbclass, we install w/o scripts and then post-process
everything to ensure the dependencies are there.. ordering is not guaranteed.)

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

diff --git a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
index 728b8e5..c5a6848 100644
--- a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
+++ b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
@@ -9,7 +9,7 @@  LIC_FILES_CHKSUM = "file://COPYING;md5=08c553a87d4e51bbed50b20e0adcaede \
 
 DEPENDS = "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 RDEPENDS_${PN} = "${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_PLUGINS}', '', d)}"
-PR = "r3"
+PR = "r4"
 
 SRC_URI = "http://pkg-shadow.alioth.debian.org/releases/${BPN}-${PV}.tar.bz2 \
            file://login_defs_pam.sed \
@@ -122,12 +122,13 @@  pkg_postinst_${PN} () {
 	update-alternatives --install ${base_sbindir}/vipw vipw vipw.${PN} 200
 	update-alternatives --install ${base_sbindir}/vigr vigr vigr.${PN} 200
 
-	if [ "x$D" != "x" ]; then
-		exit 1
-	fi  
-
-	pwconv
-	grpconv
+	if [ -n "$D" ]; then
+		pwconv -R $D
+		grpconv -R $D
+	else
+		pwconv
+		grpconv
+	fi
 }
 
 pkg_prerm_${PN} () {