From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Yuriy Pudgorodskiy <yur@virtuozzo.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
"Denis V. Lunev" <den@openvz.org>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
QEMU <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2 0/2] qga: guest-set-user-password - added ability to create new user
Date: Tue, 09 Feb 2016 17:22:12 -0600 [thread overview]
Message-ID: <20160209232212.24450.48753@loki> (raw)
In-Reply-To: <569F6FC9.2050401@virtuozzo.com>
Quoting Yuriy Pudgorodskiy (2016-01-20 05:30:17)
> On 1/14/2016 5:46 PM, Daniel P. Berrange wrote:
> > On Thu, Jan 14, 2016 at 05:22:39PM +0300, Denis V. Lunev wrote:
> >> On 01/14/2016 05:18 PM, Marc-André Lureau wrote:
> >>> Hi
> >>>
> >>> On Wed, Jan 6, 2016 at 1:01 PM, Denis V. Lunev <den@openvz.org> wrote:
> >>>> These patches add optional 'create' flag to guest-set-user-password command.
> >>>> When it is specified, a new user will be created if it does not
> >>>> exist yet.
> >>>>
> >>> What's the motivation to re-use set-password instead of a new command?
> >> because we will have to change the password later on after addition
> >> of such user. Also this looks better for a case "create if not exists" and
> >> force new password.
> > I don't think that's very compelling honestly. In addition when creating
> > user accounts there's a whole bunch more parameters you potentially want
> > to set besides just the username - see how many options exist with the
> > 'useradd' command. Also with some users you might not want to set any
> > password. So if we want to create users via QGA, I think that having a
> > separate command makes more sense.
> >
> > Regards,
> > Daniel
> There is a problem with a whole bunch of create user parameters - they
> are platform
> specific. Windows and Unix 'create user' API are rather different -
> developing support for
> all parameters will probably lead to two commands - 'create_user_posix'
> and 'create_user_windows'.
>
> If so, callers that want full control over user creation may call
> platform specific commands
> over generic guest-exec - e.g. 'useradd' with many options and 'net
> user', 'net localgroup',
> respectively.
>
> We, in contradiction to such callers, want to add simpler
> platform-independent functionality
> much like the os installers provides during initial setup - e.g. just
> username and password
> with other parameters be a reasonable default.
I think that's a good interface to have, but even if the
platform-independant aspect of it is fairly basic functionality like
user/password with default groups/directory/etc, I don't see any reason
not to give it it's own command.
But I'm not convinced that we can't come up with an interface that's
both cross-platform and useful for basic user creation tasks. It
would be nice if the initial implementation was created with this
goal in mind...
If we relegate things like group assignments and other tuneables
to a set of separate, future interfaces like guest-user-modify-groups,
guest-user-set-password-expiration, etc. etc, what's the bare-minimum
for a cross-platform, useable guest-user-create?
user name, full name?, home directory, logon script/shell...
(all common/relevant to both win32 and posix btw)
Any others we can think of that are absolutely necessary for basic
user creation, that couldn't be modified through other interfaces in
the future?
I think that's the sort of interface we should introduce initially.
Blatantly platform-specific stuff can be relegated to platform-specific
commands with smaller scope, not necessarily full-blown rich interfaces
like user-create-posix, user-create-win32, etc.
>
> If that sounds logical to you - we may talk about reasons for defaults
> and extends to a minimal
> parameter set (user plus password).
>
> But creating a full separate 'user add' command when it is platform
> specific and user has ability
> to call 'useradd' via exec - sounds like an overkill to me.
>
>
>
>
>
>
prev parent reply other threads:[~2016-02-09 23:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 12:01 [Qemu-devel] [PATCH v2 0/2] qga: guest-set-user-password - added ability to create new user Denis V. Lunev
2016-01-06 12:01 ` [Qemu-devel] [PATCH 1/2] create ga_run_program() helper for guest-set-user-password Denis V. Lunev
2016-01-06 13:50 ` Denis V. Lunev
2016-01-11 12:08 ` Yuriy Pudgorodskiy
2016-01-12 6:33 ` Denis V. Lunev
2016-01-06 12:01 ` [Qemu-devel] [PATCH 2/2] guest-set-user-password - added ability to create new user Denis V. Lunev
2016-01-14 7:25 ` [Qemu-devel] [PATCH v2 0/2] qga: " Denis V. Lunev
2016-01-14 14:18 ` Marc-André Lureau
2016-01-14 14:22 ` Denis V. Lunev
2016-01-14 14:46 ` Daniel P. Berrange
2016-01-20 11:30 ` Yuriy Pudgorodskiy
2016-02-09 23:22 ` Michael Roth [this message]
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=20160209232212.24450.48753@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=berrange@redhat.com \
--cc=den@openvz.org \
--cc=marcandre.lureau@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=yur@virtuozzo.com \
/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.