qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/2] qga: guest-set-user-password - added abi


From: Yuriy Pudgorodskiy
Subject: Re: [Qemu-devel] [PATCH v2 0/2] qga: guest-set-user-password - added ability to create new user
Date: Wed, 20 Jan 2016 14:30:17 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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 <address@hidden> 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.

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.









reply via email to

[Prev in Thread] Current Thread [Next in Thread]