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. > >>> > -- Christopher
