accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Blog post on Fedora
Date Tue, 20 Dec 2016 18:48:30 GMT
https://github.com/apache/accumulo-website/pull/4

I've also ran into an issue that Christopher seems to have run into as well:

On a rebuild of the site locally, I get this error which breaks the rebuild:

              Error: No repo name found. Specify using PAGES_REPO_NWO 
environment variables, 'repository' in your configuration, or set up an 
'origin' git remote pointing to your github.com repository.
              Error: Run jekyll build --trace for more information.

I can't seem to figure out exactly what the value for that repository 
key should be, but at the least the error for a bad value doesn't seem 
to prevent it from failing to rebuild the site.

https://github.com/jekyll/jekyll/issues/4705

Has someone already figured this one out?

Josh Elser wrote:
> Christopher wrote:
>> 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.
>
> Agreed. This would be an alternative in code which would be super useful.
>
>> 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).
>
> Not sure about this. I don't know how closely HDFS follows this.
>
>> 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.
>
> Another alternative is to just put a disclaimer that it's only
> recommended for "developer" or "testing" environments. It's kind of a
> catch-22 because it's such a nice write-up; I could see people trying to
> automate/productize the process which has an inherent issue with it.
>
> Let me just open up a PR for what I'd suggest instead of just talking
> about doing.
>
>>
>> On Mon, Dec 19, 2016 at 11:15 PM Josh Elser<josh.elser@gmail.com> 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.
>>>

Mime
View raw message