accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Blog post on Fedora
Date Tue, 20 Dec 2016 19:09:18 GMT
Argghhh Github!

Alright, I won't spend any more time on it. Thanks for the info.

Christopher wrote:
> I believe the format should be "apache/accumulo", but we don't want to set
> it, because we don't want it trying to pull down metadata from github for
> local builds. The fact that it tries is a bug in the gem. It should skip
> the metadata if the repository isn't set.
> They seem to have implemented a partial fix, but we still get the error
> with auto-rebuilds. For now, I'm just not relying on auto-rebuilds. `bundle
> exec jekyll serve --safe`, with 'Ctrl-C, Up Arrow, Enter, repeat' works
> well enough for me. :)
> On Tue, Dec 20, 2016 at 1:49 PM Josh Elser<>  wrote:
>> 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 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.
>> 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<>
>> 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
>>>>> 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.

View raw message