+
David Medinets 2013-02-02, 04:36
+
John Vines 2013-02-02, 04:50
+
Christopher 2013-02-02, 05:19
+
John Vines 2013-02-02, 20:10
-
Re: Change in 'accumulo init' behaviorChristopher 2013-02-03, 02:44
John-
I'm keenly aware that many people will want to manage users with the old
authentication system. I'm one of those people. I'm also aware of the
benefits of the changes that were made for those customers who want to
manage users outside of Accumulo. I think we can support both, but only
where the features of the two intersect. Where they diverge, we can provide
a simple transition to the internally provided authentication system's
initialization.
Personally, I think it is a *simpler* change, to make init do fewer
prompts, and a more intuitive step (given that multiple authentication
systems are permitted), to initialize the security system in a separate
command. Perhaps something like "bin/accumulo init-security". Internally,
there already existed a command to init/re-init security in Zookeeper... we
just called it explicitly during init, but it could always have easily been
called directly.
Doing this, eliminates the need to prompt and then throw away the responses
if the chosen authentication system doesn't support them. I think that is
*very* confusing to users. (I'm imagining some user with an
LDAPAuthenticator asking, "What do I need to put here?" and "Why is this
asking me for this?").
I can certainly understand keeping around the old prompts, exactly as they
were, and disregarding the responses if they don't apply (I'm not in favor
of this, but I understand it). At least that provides a consistent user
experience, even if it doesn't apply to users leveraging a newer feature.
What I don't understand, though, is the *addition* of new prompts, that
never applied before, don't really need to be applied now (is it really
useful/essential to have 'root' by another name?), and may not apply to
alternate authentication systems a user might configure Accumulo to use (it
certainly won't apply to all of them).
At the very least, we can do stuff here that makes it easier on users:
1) To make it easier on users who use the old system, don't prompt for
"root", to retain prior behavior.
2) To make it easier on users who don't use the old system, don't prompt at
all, and require them to initialize security through that other system
(this is my preference for both old and new authentication systems).
3) Alternatively, we can prompt more verbosely, as in "I see that you
haven't configured an authentication system. Would you like to setup a
password-based user database in Zookeeper?"
We can, easily enough, check the config file if we need to use decide how
to proceed.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Sat, Feb 2, 2013 at 3:10 PM, John Vines <[EMAIL PROTECTED]> wrote:
> Keep in mind that not all users will be using a user management system
> outside of the existing one. Last thing we want to do is to make first time
> users jump through even more hoops to get started. The basic zookeeper
> based system is still quite functional, and I really don't see us moving
> away from it. Both from a quick start sense as well as from a simplicity
> standpoint as I see the more common use case being externalized
> authentication and continued use of the zookeeper authorization and
> permission handling. Now, if the future, perhaps it would be ideal to
> create a separate management interface for it. But there still maintains
> the possibility that other implementations can harness some of the user
> management interfaces as well. I prefer to keep them in and then it's up to
> the implementions to utilize or throw an UnsupportedOperation error code.
>
>
> On Sat, Feb 2, 2013 at 12:19 AM, Christopher <[EMAIL PROTECTED]> wrote:
>
>> David, John-
>>
>> This is a good point. I think it'd be better to retain the previous
>> behavior, for backwards compatibility, or eliminate all these prompts
>> entirely (my preference is the latter). If I may speak about the original
>> design of the user management functionality, the whole point of a "root"
>> user in the first place was to provide a basis for managing other users.
I'm keenly aware that many people will want to manage users with the old
authentication system. I'm one of those people. I'm also aware of the
benefits of the changes that were made for those customers who want to
manage users outside of Accumulo. I think we can support both, but only
where the features of the two intersect. Where they diverge, we can provide
a simple transition to the internally provided authentication system's
initialization.
Personally, I think it is a *simpler* change, to make init do fewer
prompts, and a more intuitive step (given that multiple authentication
systems are permitted), to initialize the security system in a separate
command. Perhaps something like "bin/accumulo init-security". Internally,
there already existed a command to init/re-init security in Zookeeper... we
just called it explicitly during init, but it could always have easily been
called directly.
Doing this, eliminates the need to prompt and then throw away the responses
if the chosen authentication system doesn't support them. I think that is
*very* confusing to users. (I'm imagining some user with an
LDAPAuthenticator asking, "What do I need to put here?" and "Why is this
asking me for this?").
I can certainly understand keeping around the old prompts, exactly as they
were, and disregarding the responses if they don't apply (I'm not in favor
of this, but I understand it). At least that provides a consistent user
experience, even if it doesn't apply to users leveraging a newer feature.
What I don't understand, though, is the *addition* of new prompts, that
never applied before, don't really need to be applied now (is it really
useful/essential to have 'root' by another name?), and may not apply to
alternate authentication systems a user might configure Accumulo to use (it
certainly won't apply to all of them).
At the very least, we can do stuff here that makes it easier on users:
1) To make it easier on users who use the old system, don't prompt for
"root", to retain prior behavior.
2) To make it easier on users who don't use the old system, don't prompt at
all, and require them to initialize security through that other system
(this is my preference for both old and new authentication systems).
3) Alternatively, we can prompt more verbosely, as in "I see that you
haven't configured an authentication system. Would you like to setup a
password-based user database in Zookeeper?"
We can, easily enough, check the config file if we need to use decide how
to proceed.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Sat, Feb 2, 2013 at 3:10 PM, John Vines <[EMAIL PROTECTED]> wrote:
> Keep in mind that not all users will be using a user management system
> outside of the existing one. Last thing we want to do is to make first time
> users jump through even more hoops to get started. The basic zookeeper
> based system is still quite functional, and I really don't see us moving
> away from it. Both from a quick start sense as well as from a simplicity
> standpoint as I see the more common use case being externalized
> authentication and continued use of the zookeeper authorization and
> permission handling. Now, if the future, perhaps it would be ideal to
> create a separate management interface for it. But there still maintains
> the possibility that other implementations can harness some of the user
> management interfaces as well. I prefer to keep them in and then it's up to
> the implementions to utilize or throw an UnsupportedOperation error code.
>
>
> On Sat, Feb 2, 2013 at 12:19 AM, Christopher <[EMAIL PROTECTED]> wrote:
>
>> David, John-
>>
>> This is a good point. I think it'd be better to retain the previous
>> behavior, for backwards compatibility, or eliminate all these prompts
>> entirely (my preference is the latter). If I may speak about the original
>> design of the user management functionality, the whole point of a "root"
>> user in the first place was to provide a basis for managing other users.
+
Keith Turner 2013-02-02, 19:22
+
Christopher 2013-02-03, 01:37
