All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings
Date: Mon, 8 Jul 2013 21:31:31 +0200	[thread overview]
Message-ID: <20130708193131.GP3288@jama> (raw)
In-Reply-To: <51DAFE8C.8000506@windriver.com>

[-- 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 --]

  reply	other threads:[~2013-07-08 19:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-05  6:07 [PATCH 0/1] image.bbclass: add a method for image level user/group configuration Qi.Chen
2013-07-05  6:07 ` [PATCH 1/1] image.bbclass: add a method to add/delete/modify user/group settings Qi.Chen
2013-07-05  8:39   ` Martin Jansa
2013-07-05  9:16     ` ChenQi
2013-07-08 17:15     ` Mark Hatle
2013-07-08 17:27       ` Martin Jansa
2013-07-08 18:01         ` Mark Hatle
2013-07-08 19:31           ` Martin Jansa [this message]
2013-07-08 20:10             ` Mark Hatle
2013-07-08 23:20   ` Saul Wold
2013-07-10  6:42     ` ChenQi

Reply instructions:

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

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

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

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

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

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

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