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 investigate). 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 <[email protected]> wrote: > Nice write up here, folks. > https://accumulo.apache.org/blog/2016/12/19/running-on-fedora-25.html > > 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. > -- Christopher
