accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Blog post on Fedora
Date Tue, 20 Dec 2016 13:52:52 GMT
Ideally, Accumulo init should be able to make use of a pre-created empty
directory, rather than require the directory to be non-existent. That's
something we can, and should, fix upstream. In fact, I actually think
Accumulo should require the directory to already exist, and be empty, and
should never create it. This more closely aligns with the behavior of
'mount', which I think is a good analogy for our instance.volumes, but
would be a significant change in behavior.

Another alternative is for Hadoop to support a sticky bit, so users can
create new directories at the root without being able to delete or alter
other users' files. Or, it could support FACLs (does it, today? I didn't

An alternative which is possible today is to pre-create a top-level
directory, with appropriate ownership/permissions, and have Accumulo do its
init thing inside that. I thought about doing that, but figured that would
be too complex, and I wanted the example to be simple. I'd be happy to
update the blog post to describe this if you think it's more sensible than
the temporary 777 solution. You'd probably want to do that on a
pre-existing HDFS instance, or any instance where other users have access
to it. However, given that this example starts from scratch, I'm not sure
it matters much.

On Mon, Dec 19, 2016 at 11:15 PM Josh Elser <> wrote:

> Nice write up here, folks.
> One point of criticism, as a security minded database, can we replace the
> guidance to `chmod 777` all of HDFS just to give Accumulo permission to
> init? :)
> We could recommend that /user/accumulo/data or /apps/accumulo be used
> instead of /accumulo. Either of these would be much better ideas and
> prevent the need to alter the root of HDFS, IMO.

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