accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Change in 'accumulo init' behavior
Date Sun, 03 Feb 2013 02:44:47 GMT

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

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

On Sat, Feb 2, 2013 at 3:10 PM, John Vines <> 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 <> 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.
>> However, this role is obsoleted by any pluggable authentication mechanism,
>> because those alternate implementations may have drastically different user
>> management capabilities, and the root user is no longer required.
>> A large part of my overall criticism of the new authentication model is
>> this intermingling of pluggable authentication mechanisms with Accumulo's
>> former API for user management. I find it difficult to get behind a
>> pluggable authentication system that still tightly coupled to the built-in
>> user management functionality (except where needed for backwards
>> compatibility with the user/password)... mainly, because I thought the
>> whole point of pluggable authentication (or at least, the best argument for
>> it) was to unlink these, and allow user- and authorization-management
>> external to Accumulo.
>> --
>> Christopher L Tubbs II
>> On Fri, Feb 1, 2013 at 11:50 PM, John Vines <> wrote:
>>> Yes, this has changed in trunk to support the pluggable authentication
>>> schemes.
>>> Sent from my phone, please pardon the typos and brevity.
>>> On Feb 1, 2013 11:36 PM, "David Medinets" <>
>>> wrote:
>>> > The following command used to work:
>>> >
>>> >   su accumulo -c "/usr/local/accumulo/bin/accumulo init
>>> > --clear-instance-name --instance-name instance --password secret"
>>> >
>>> > but now it is asking for a name:
>>> >
>>> >   Enter name for initial root user ( root):
>>> >
>>> > I can easily update my script to use --username but wanted to point
>>> > out this behaviour change.
>>> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message