image.bbclass: add a method for image level user/group configuration
cover image.bbclass: add a method for image level user/group configuration
From: Chen Qi <[email protected]>
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(+)
Signature · 1 line
1.7.9.5
PATCH 1/1 image.bbclass: add a method to add/delete/modify user/group settings
From: Chen Qi <[email protected]>
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]
--- meta/classes/image.bbclass | 48 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)
meta/classes/image.bbclass +48 -0
@@ -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
Signature · 1 line
1.7.9.5
Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings
Quoted 7 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.
Quoted 7 lines
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 theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.
Why not use extra package just with user?
See "[PATCH v3 0/5] Allow xuser to shutdown (cover letter only)"
Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings
Quoted 12 lines · Martin Jansa
Quoted 11 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.
Quoted 6 lines
Quoted 3 lines
This patch also adds a function,
set_user_group, which happens at the end of theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.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
In reply to Martin JansaQuoted 12 lines · Martin Jansa
Quoted 11 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.
Quoted 7 lines
Quoted 3 lines
This patch also adds a function,
set_user_group, which happens at the end of theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.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.
Quoted 7 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings
Quoted 25 lines · Mark Hatle
Quoted 12 lines · Martin Jansa
Quoted 11 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.Quoted 7 lines
Quoted 3 lines
This patch also adds a function,
set_user_group, which happens at the end of theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.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.
Quoted 8 lines
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.
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings
Quoted 38 lines · Martin Jansa
Quoted 25 lines · Mark Hatle
Quoted 12 lines · Martin Jansa
Quoted 11 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.Quoted 7 lines
Quoted 3 lines
This patch also adds a function,
set_user_group, which happens at the end of theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.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.
Quoted 8 lines
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)
Quoted 7 lines
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
Quoted 47 lines · Mark Hatle
Quoted 38 lines · Martin Jansa
Quoted 25 lines · Mark Hatle
Quoted 12 lines · Martin Jansa
Quoted 11 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.Quoted 7 lines
Quoted 3 lines
This patch also adds a function,
set_user_group, which happens at the end of theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.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.
Quoted 8 lines
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)Quoted 7 lines
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.
Quoted 8 lines
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"
Quoted 3 lines
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)?
Quoted 7 lines
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
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings
Quoted 57 lines · Martin Jansa
Quoted 47 lines · Mark Hatle
Quoted 38 lines · Martin Jansa
Quoted 25 lines · Mark Hatle
Quoted 12 lines · Martin Jansa
Quoted 11 lines · On Fri, Jul 05, 2013 at 02:07:28PM +0800, [email protected] wrote:
From: Chen Qi <[email protected]>
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.Quoted 7 lines
Quoted 3 lines
This patch also adds a function,
set_user_group, which happens at the end of theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.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.
Quoted 8 lines
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)Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 8 lines
IMAGE_INSTALL+= "base-user-bob base-user-tracy base-user-alice"Quoted 3 lines
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".
Quoted 2 lines
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
Quoted 8 lines
Quoted 7 lines
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
In reply to [email protected]Quoted 38 lines · On 07/04/2013 11:07 PM, [email protected] wrote:
From: Chen Qi <[email protected]>
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 theROOTFS_POSTPROCESS_COMMAND. It handles the settings in theUSER_GROUP_SETTINGSvariable.[YOCTO #4074]
Signed-off-by Chen Qi <[email protected]>--- meta/classes/image.bbclass | 48 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)meta/classes/image.bbclass +2
-0@@ -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 }
meta/classes/image.bbclass postinst_enable_logging () { · line 541
Quoted 10 lines
meta/classes/image.bbclass +9
-0+# 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:
Quoted 3 lines
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: taskdo_rootfs: Failed
Sau!
Quoted 41 lines
meta/classes/image.bbclass +37
-0+ 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
Quoted 12 lines · Saul Wold
Quoted 1 line · On 07/04/2013 11:07 PM, [email protected] 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:
Quoted 3 lines
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: taskdo_rootfs: FailedSau!
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 [email protected]. [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