[PATCH 0/1] image.bbclass: add a method for image level user/group configuration

[PATCH 0/1] image.bbclass: add a method for image level user/group configuration

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

The following changes since commit 80b263430453896189b704d0997943642eec6fef:

  classes/insane: remove la2 check which no longer exists from ERROR_QA (2013-06-28 16:33:08 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/user_group_settings
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/user_group_settings

Chen Qi (1):
  image.bbclass: add a method to add/delete/modify user/group settings

 meta/classes/image.bbclass |   48 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

-- 
1.7.9.5

[PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

We may want to add a user or group which does not logically belong to
any specific package. For example, we may want to add a user with the
name 'tester' to our image. Besides, we may want to delete or modify
user/group in our image.

This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
to these tasks. The configuration format is detailed in the local.conf.
sample.extended file.

This patch also adds a function, set_user_group, which happens at
the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
in the USER_GROUP_SETTINGS variable.

[YOCTO #4074]

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/classes/image.bbclass |   48 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 380ed8e..8ce97be 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -179,6 +179,8 @@ ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES", "debug-tweaks"
 ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES", "debug-tweaks", "postinst_enable_logging; ", "",d)}'
 # Set default postinst log file
 POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
+# Image level user / group settings
+ROOTFS_POSTPROCESS_COMMAND_append = " set_user_group;"
 
 # some default locales
 IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
@@ -528,6 +530,52 @@ postinst_enable_logging () {
 	echo "LOGFILE=${POSTINST_LOGFILE}" >> ${IMAGE_ROOTFS}${sysconfdir}/default/postinst
 }
 
+# Image level user / group settings
+set_user_group () {
+	user_group_settings="${USER_GROUP_SETTINGS}"
+	export PSEUDO="${FAKEROOTENV} ${STAGING_DIR_NATIVE}${bindir}/pseudo"
+	# login.def may no be present in rootfs, if so, we use that one in sysroot as a default
+	if [ ! -e ${IMAGE_ROOTFS}${sysconfdir}/login.defs ]; then
+		cp ${STAGING_DIR_TARGET}/${sysconfdir}/login.defs ${IMAGE_ROOTFS}${sysconfdir}/login.defs
+		target_login_def="no"
+	fi
+	setting=`echo $user_group_settings | cut -d ';' -f1`
+	remaining=`echo $user_group_settings | cut -d ';' -f2-`
+	while test "x$setting" != "x"; do
+		user_group=`echo $setting | cut -d ',' -f1`
+		action=`echo $setting | cut -d ',' -f2`
+		opts=`echo $setting | cut -d ',' -f3`
+		# determine the command according to user_group and action
+		if [ "$user_group" = "USER" ]; then
+			cmd_prefix="user"
+		elif [ "$user_group" = "GROUP" ]; then
+			cmd_prefix="group"
+		else
+			echo "Error: invalid setting of $user_group in the USER_GROUP_SETTINGS"
+			exit 1
+		fi
+		if [ "$action" = "ADD" ]; then
+			cmd_suffix="add"
+		elif [ "$action" = "DEL" ]; then
+			cmd_suffix="del"
+		elif [ "$action" = "MOD" ]; then
+			cmd_suffix="mod"
+		else
+			echo "Error: invalid setting of $user_group in the USER_GROUP_SETTINGS"
+			exit 1
+		fi
+		cmd=$cmd_prefix$cmd_suffix
+		echo "using commond <$cmd> for setting <$setting> ..."
+		eval $PSEUDO $cmd -R ${IMAGE_ROOTFS} $opts
+		# iterate to the next setting
+		setting=`echo $remaining | cut -d ';' -f1`
+		remaining=`echo $remaining | cut -d ';' -f2-`
+	done
+	if [ "$target_login_def" = "no" ]; then
+		rm -f ${IMAGE_ROOTFS}${sysconfdir}/login.defs
+	fi
+}
+
 # Turn any symbolic /sbin/init link into a file
 remove_init_link () {
 	if [ -h ${IMAGE_ROOTFS}/sbin/init ]; then
-- 
1.7.9.5

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Martin Jansa]

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

On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
> From: Chen Qi <Qi.Chen@windriver.com>
> 
> We may want to add a user or group which does not logically belong to
> any specific package. For example, we may want to add a user with the
> name 'tester' to our image. Besides, we may want to delete or modify
> user/group in our image.
> 
> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
> to these tasks. The configuration format is detailed in the local.conf.
> sample.extended file.
> 
> This patch also adds a function, set_user_group, which happens at
> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
> in the USER_GROUP_SETTINGS variable.

Why not use extra package just with user?

See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"

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

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[ChenQi]

On 07/05/2013 04:39 PM, Martin Jansa wrote:
> On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
>> From: Chen Qi <Qi.Chen@windriver.com>
>>
>> We may want to add a user or group which does not logically belong to
>> any specific package. For example, we may want to add a user with the
>> name 'tester' to our image. Besides, we may want to delete or modify
>> user/group in our image.
>>
>> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
>> to these tasks. The configuration format is detailed in the local.conf.
>> sample.extended file.
>>
>> This patch also adds a function, set_user_group, which happens at
>> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
>> in the USER_GROUP_SETTINGS variable.
> Why not use extra package just with user?
>
> See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"
I considered this approach (see 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4074 for more 
details), but I finally gave it up because of the following two reasons.
1) The users may not want  to mess with bb files, as is the situation 
with our company's customers.
2) Configuring user/group through .conf file is more convenient.

I noticed Laurentiu's patch about xuser and shutdown, and I've read 
though it carefully.
The xuser is kind of special, as it's to some extend "common".

Best Regards,
Chen Qi

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Mark Hatle]

On 7/5/13 3:39 AM, Martin Jansa wrote:
> On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
>> From: Chen Qi <Qi.Chen@windriver.com>
>>
>> We may want to add a user or group which does not logically belong to
>> any specific package. For example, we may want to add a user with the
>> name 'tester' to our image. Besides, we may want to delete or modify
>> user/group in our image.
>>
>> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
>> to these tasks. The configuration format is detailed in the local.conf.
>> sample.extended file.
>>
>> This patch also adds a function, set_user_group, which happens at
>> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
>> in the USER_GROUP_SETTINGS variable.
>
> Why not use extra package just with user?
>
> See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"

The issue is that the users don't want extra (empty) packages to just add 
standard users/groups.  What they want is a post image-generation 
"configuration" mechanism.

Adding users/groups is one of the basic items that they want/need.  This really 
has to be considered to be an administrative activity vs a distribution 
activity.  (I.e. difference between creating a package and performing some kind 
of post-image action.)

The other issue with a package based approach is it then mandates changes occur 
by having to rebuild/reinstall packages.  This is onerous in my experience, for 
something basic like this.  It's really outside of the package manager's control.

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

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Martin Jansa]

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

On Mon, Jul 08, 2013 at 12:15:40PM -0500, Mark Hatle wrote:
> On 7/5/13 3:39 AM, Martin Jansa wrote:
> > On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
> >> From: Chen Qi <Qi.Chen@windriver.com>
> >>
> >> We may want to add a user or group which does not logically belong to
> >> any specific package. For example, we may want to add a user with the
> >> name 'tester' to our image. Besides, we may want to delete or modify
> >> user/group in our image.
> >>
> >> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
> >> to these tasks. The configuration format is detailed in the local.conf.
> >> sample.extended file.
> >>
> >> This patch also adds a function, set_user_group, which happens at
> >> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
> >> in the USER_GROUP_SETTINGS variable.
> >
> > Why not use extra package just with user?
> >
> > See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"
> 
> The issue is that the users don't want extra (empty) packages to just add 
> standard users/groups.  What they want is a post image-generation 
> "configuration" mechanism.
> 
> Adding users/groups is one of the basic items that they want/need.  This really 
> has to be considered to be an administrative activity vs a distribution 
> activity.  (I.e. difference between creating a package and performing some kind 
> of post-image action.)
> 
> The other issue with a package based approach is it then mandates changes occur 
> by having to rebuild/reinstall packages.  This is onerous in my experience, for 
> something basic like this.  It's really outside of the package manager's control.

We can have all users in one package
base-users (like we have base-files)

It can allow someone to just define DEFAULT_USERS = "a b c" in
local.conf and let base-users recipe to create all 3 automatically.

Post image-generation mechanism doesn't allow to add new required users
in "upgrade" or installing packages from binary feed with all required
users accounts.

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

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

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Mark Hatle]

On 7/8/13 12:27 PM, Martin Jansa wrote:
> On Mon, Jul 08, 2013 at 12:15:40PM -0500, Mark Hatle wrote:
>> On 7/5/13 3:39 AM, Martin Jansa wrote:
>>> On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
>>>> From: Chen Qi <Qi.Chen@windriver.com>
>>>>
>>>> We may want to add a user or group which does not logically belong to
>>>> any specific package. For example, we may want to add a user with the
>>>> name 'tester' to our image. Besides, we may want to delete or modify
>>>> user/group in our image.
>>>>
>>>> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
>>>> to these tasks. The configuration format is detailed in the local.conf.
>>>> sample.extended file.
>>>>
>>>> This patch also adds a function, set_user_group, which happens at
>>>> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
>>>> in the USER_GROUP_SETTINGS variable.
>>>
>>> Why not use extra package just with user?
>>>
>>> See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"
>>
>> The issue is that the users don't want extra (empty) packages to just add
>> standard users/groups.  What they want is a post image-generation
>> "configuration" mechanism.
>>
>> Adding users/groups is one of the basic items that they want/need.  This really
>> has to be considered to be an administrative activity vs a distribution
>> activity.  (I.e. difference between creating a package and performing some kind
>> of post-image action.)
>>
>> The other issue with a package based approach is it then mandates changes occur
>> by having to rebuild/reinstall packages.  This is onerous in my experience, for
>> something basic like this.  It's really outside of the package manager's control.
>
> We can have all users in one package
> base-users (like we have base-files)
>
> It can allow someone to just define DEFAULT_USERS = "a b c" in
> local.conf and let base-users recipe to create all 3 automatically.
>
> Post image-generation mechanism doesn't allow to add new required users
> in "upgrade" or installing packages from binary feed with all required
> users accounts.
>

That is exactly it..  these are not users that will -ever- be upgraded or worked 
on via packages.

This is equivalent to saying "I'd like users bob, tracy and alice on this image 
I'm generating."

It's NOT saying, all systems generated with this package feed will include bob, 
tracy and alice.

If the user wants to add john, after the initial image is generated, they would 
do so using the adduser functionality of the system (or modifying the 
passwd/group files.)

The fundamental problem is that the package feeds and district from the image 
itself.  The image is nothing more then an installer that happens to be running 
on the build machine itself.  Things that are part of the distribution belong in 
the feed, things that are instance/image specific belong as part of the 
installation process.

--Mark

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Martin Jansa]

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

On Mon, Jul 08, 2013 at 01:01:48PM -0500, Mark Hatle wrote:
> On 7/8/13 12:27 PM, Martin Jansa wrote:
> > On Mon, Jul 08, 2013 at 12:15:40PM -0500, Mark Hatle wrote:
> >> On 7/5/13 3:39 AM, Martin Jansa wrote:
> >>> On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
> >>>> From: Chen Qi <Qi.Chen@windriver.com>
> >>>>
> >>>> We may want to add a user or group which does not logically belong to
> >>>> any specific package. For example, we may want to add a user with the
> >>>> name 'tester' to our image. Besides, we may want to delete or modify
> >>>> user/group in our image.
> >>>>
> >>>> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
> >>>> to these tasks. The configuration format is detailed in the local.conf.
> >>>> sample.extended file.
> >>>>
> >>>> This patch also adds a function, set_user_group, which happens at
> >>>> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
> >>>> in the USER_GROUP_SETTINGS variable.
> >>>
> >>> Why not use extra package just with user?
> >>>
> >>> See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"
> >>
> >> The issue is that the users don't want extra (empty) packages to just add
> >> standard users/groups.  What they want is a post image-generation
> >> "configuration" mechanism.
> >>
> >> Adding users/groups is one of the basic items that they want/need.  This really
> >> has to be considered to be an administrative activity vs a distribution
> >> activity.  (I.e. difference between creating a package and performing some kind
> >> of post-image action.)
> >>
> >> The other issue with a package based approach is it then mandates changes occur
> >> by having to rebuild/reinstall packages.  This is onerous in my experience, for
> >> something basic like this.  It's really outside of the package manager's control.
> >
> > We can have all users in one package
> > base-users (like we have base-files)
> >
> > It can allow someone to just define DEFAULT_USERS = "a b c" in
> > local.conf and let base-users recipe to create all 3 automatically.
> >
> > Post image-generation mechanism doesn't allow to add new required users
> > in "upgrade" or installing packages from binary feed with all required
> > users accounts.
> >
> 
> That is exactly it..  these are not users that will -ever- be upgraded or worked 
> on via packages.
> 
> This is equivalent to saying "I'd like users bob, tracy and alice on this image 
> I'm generating."
> 
> It's NOT saying, all systems generated with this package feed will include bob, 
> tracy and alice.

IMAGE_INSTALL += "base-user-bob base-user-tracy base-user-alice"

> If the user wants to add john, after the initial image is generated, they would 
> do so using the adduser functionality of the system (or modifying the 
> passwd/group files.)

And what if john-the-ripper package in the feed needs john as system
user and the same system user is also used by thc-hydra package?

Should both include addusers/addgroup postinsts (like connman,
xserver-nodm-init do without latest patchset)?

> The fundamental problem is that the package feeds and district from the image 
> itself.  The image is nothing more then an installer that happens to be running 
> on the build machine itself.  Things that are part of the distribution belong in 
> the feed, things that are instance/image specific belong as part of the 
> installation process.
> 
> --Mark

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

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

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Mark Hatle]

On 7/8/13 2:31 PM, Martin Jansa wrote:
> On Mon, Jul 08, 2013 at 01:01:48PM -0500, Mark Hatle wrote:
>> On 7/8/13 12:27 PM, Martin Jansa wrote:
>>> On Mon, Jul 08, 2013 at 12:15:40PM -0500, Mark Hatle wrote:
>>>> On 7/5/13 3:39 AM, Martin Jansa wrote:
>>>>> On Fri, Jul 05, 2013 at 02:07:28PM +0800, Qi.Chen@windriver.com wrote:
>>>>>> From: Chen Qi <Qi.Chen@windriver.com>
>>>>>>
>>>>>> We may want to add a user or group which does not logically belong to
>>>>>> any specific package. For example, we may want to add a user with the
>>>>>> name 'tester' to our image. Besides, we may want to delete or modify
>>>>>> user/group in our image.
>>>>>>
>>>>>> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
>>>>>> to these tasks. The configuration format is detailed in the local.conf.
>>>>>> sample.extended file.
>>>>>>
>>>>>> This patch also adds a function, set_user_group, which happens at
>>>>>> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
>>>>>> in the USER_GROUP_SETTINGS variable.
>>>>>
>>>>> Why not use extra package just with user?
>>>>>
>>>>> See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"
>>>>
>>>> The issue is that the users don't want extra (empty) packages to just add
>>>> standard users/groups.  What they want is a post image-generation
>>>> "configuration" mechanism.
>>>>
>>>> Adding users/groups is one of the basic items that they want/need.  This really
>>>> has to be considered to be an administrative activity vs a distribution
>>>> activity.  (I.e. difference between creating a package and performing some kind
>>>> of post-image action.)
>>>>
>>>> The other issue with a package based approach is it then mandates changes occur
>>>> by having to rebuild/reinstall packages.  This is onerous in my experience, for
>>>> something basic like this.  It's really outside of the package manager's control.
>>>
>>> We can have all users in one package
>>> base-users (like we have base-files)
>>>
>>> It can allow someone to just define DEFAULT_USERS = "a b c" in
>>> local.conf and let base-users recipe to create all 3 automatically.
>>>
>>> Post image-generation mechanism doesn't allow to add new required users
>>> in "upgrade" or installing packages from binary feed with all required
>>> users accounts.
>>>
>>
>> That is exactly it..  these are not users that will -ever- be upgraded or worked
>> on via packages.
>>
>> This is equivalent to saying "I'd like users bob, tracy and alice on this image
>> I'm generating."
>>
>> It's NOT saying, all systems generated with this package feed will include bob,
>> tracy and alice.
>
> IMAGE_INSTALL += "base-user-bob base-user-tracy base-user-alice"
>
>> If the user wants to add john, after the initial image is generated, they would
>> do so using the adduser functionality of the system (or modifying the
>> passwd/group files.)
>
> And what if john-the-ripper package in the feed needs john as system
> user and the same system user is also used by thc-hydra package?

These are not system users.. these are -actual- users, people who are going to 
log into this instance and do "something".

> Should both include addusers/addgroup postinsts (like connman,
> xserver-nodm-init do without latest patchset)?

Each package that requires a non-standard system user should add it themselves 
via the existing postinst scripts.

--Mark

>> The fundamental problem is that the package feeds and district from the image
>> itself.  The image is nothing more then an installer that happens to be running
>> on the build machine itself.  Things that are part of the distribution belong in
>> the feed, things that are instance/image specific belong as part of the
>> installation process.
>>
>> --Mark
>

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[Saul Wold]

On 07/04/2013 11:07 PM, Qi.Chen@windriver.com wrote:
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We may want to add a user or group which does not logically belong to
> any specific package. For example, we may want to add a user with the
> name 'tester' to our image. Besides, we may want to delete or modify
> user/group in our image.
>
> This patch adds a variable, USER_GROUP_SETTINGS, which is dedicated
> to these tasks. The configuration format is detailed in the local.conf.
> sample.extended file.
>
> This patch also adds a function, set_user_group, which happens at
> the end of the ROOTFS_POSTPROCESS_COMMAND. It handles the settings
> in the USER_GROUP_SETTINGS variable.
>
> [YOCTO #4074]
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>   meta/classes/image.bbclass |   48 ++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 48 insertions(+)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 380ed8e..8ce97be 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -179,6 +179,8 @@ ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES", "debug-tweaks"
>   ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES", "debug-tweaks", "postinst_enable_logging; ", "",d)}'
>   # Set default postinst log file
>   POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
> +# Image level user / group settings
> +ROOTFS_POSTPROCESS_COMMAND_append = " set_user_group;"
>
>   # some default locales
>   IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
> @@ -528,6 +530,52 @@ postinst_enable_logging () {
>   	echo "LOGFILE=${POSTINST_LOGFILE}" >> ${IMAGE_ROOTFS}${sysconfdir}/default/postinst
>   }
>
> +# Image level user / group settings
> +set_user_group () {
> +	user_group_settings="${USER_GROUP_SETTINGS}"
> +	export PSEUDO="${FAKEROOTENV} ${STAGING_DIR_NATIVE}${bindir}/pseudo"
> +	# login.def may no be present in rootfs, if so, we use that one in sysroot as a default
> +	if [ ! -e ${IMAGE_ROOTFS}${sysconfdir}/login.defs ]; then
> +		cp ${STAGING_DIR_TARGET}/${sysconfdir}/login.defs ${IMAGE_ROOTFS}${sysconfdir}/login.defs
> +		target_login_def="no"
> +	fi
Since this gets run every time for image creation, we can be sure an 
image won't be using someform of login, so finding login.defs might not 
be the best thing to do.

take the poky.tiny example and failures:
> cp: cannot stat '/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/poky-tiny/build/build/tmp/sysroots/qemux86//etc/login.defs': No such file or directory
> ERROR: Function failed: do_rootfs (log file is located at /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/poky-tiny/build/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.24531)
> NOTE: recipe core-image-minimal-1.0-r0: task do_rootfs: Failed

Sau!



> +	setting=`echo $user_group_settings | cut -d ';' -f1`
> +	remaining=`echo $user_group_settings | cut -d ';' -f2-`
> +	while test "x$setting" != "x"; do
> +		user_group=`echo $setting | cut -d ',' -f1`
> +		action=`echo $setting | cut -d ',' -f2`
> +		opts=`echo $setting | cut -d ',' -f3`
> +		# determine the command according to user_group and action
> +		if [ "$user_group" = "USER" ]; then
> +			cmd_prefix="user"
> +		elif [ "$user_group" = "GROUP" ]; then
> +			cmd_prefix="group"
> +		else
> +			echo "Error: invalid setting of $user_group in the USER_GROUP_SETTINGS"
> +			exit 1
> +		fi
> +		if [ "$action" = "ADD" ]; then
> +			cmd_suffix="add"
> +		elif [ "$action" = "DEL" ]; then
> +			cmd_suffix="del"
> +		elif [ "$action" = "MOD" ]; then
> +			cmd_suffix="mod"
> +		else
> +			echo "Error: invalid setting of $user_group in the USER_GROUP_SETTINGS"
> +			exit 1
> +		fi
> +		cmd=$cmd_prefix$cmd_suffix
> +		echo "using commond <$cmd> for setting <$setting> ..."
> +		eval $PSEUDO $cmd -R ${IMAGE_ROOTFS} $opts
> +		# iterate to the next setting
> +		setting=`echo $remaining | cut -d ';' -f1`
> +		remaining=`echo $remaining | cut -d ';' -f2-`
> +	done
> +	if [ "$target_login_def" = "no" ]; then
> +		rm -f ${IMAGE_ROOTFS}${sysconfdir}/login.defs
> +	fi
> +}
> +
>   # Turn any symbolic /sbin/init link into a file
>   remove_init_link () {
>   	if [ -h ${IMAGE_ROOTFS}/sbin/init ]; then
>

Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings

[ChenQi]

On 07/09/2013 07:20 AM, Saul Wold wrote:
> On 07/04/2013 11:07 PM, Qi.Chen@windriver.com wrote:
>>
> Since this gets run every time for image creation, we can be sure an 
> image won't be using someform of login, so finding login.defs might 
> not be the best thing to do.
>
> take the poky.tiny example and failures:
>> cp: cannot stat 
>> '/srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/poky-tiny/build/build/tmp/sysroots/qemux86//etc/login.defs': 
>> No such file or directory
>> ERROR: Function failed: do_rootfs (log file is located at 
>> /srv/home/pokybuild/yocto-autobuilder-new/yocto-slave/poky-tiny/build/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.24531)
>> NOTE: recipe core-image-minimal-1.0-r0: task do_rootfs: Failed
>
> Sau!
>
>

Hi Saul,

Patch V2 has been sent which adopts the same logic in useradd.bbclass, 
that is, add passwd and shadow to the RDEPENDS if we are changing the 
user/group settings.

Two related patches are sent to poky@yoctoproject.org.
[poky] [PATCH 1/2] poky-tiny.conf: add extra libc features
[poky] [PATCH 2/2] local.conf.sample.extended: add USER_GROUP_SETTINGS

Best Regards,
Chen Qi