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<[email protected]> wrote:
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<[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.
