New version of Deployment Guide for Ubuntu 16.

[csqrs]

I would like to contribute this to your project. I decided to offer a new file, rather than e.g. interleave Ubuntu 16 instructions in the existing one. That would have been too messy. Please let me know if you are interested in this, and/or what I can do to bring it to an acceptable form. I've worked through the instructions from start to finish building a server from scratch, and it works. However, I'm sure there are further tests you make to verify functionality. And thank you very much for the original document! It's invaluable!

[DiegoPino]

@csqrs @lutaylor I see a lot of this comes from @giancarlobi DIGIBIESS http://dev.digibess.it/doku.php?id=reloaded guide and someof this is really copy and paste. I feel if this goes in, proper credit to Giancarlo must be given and not only as a side mention inside.

His guide is extremely well written, updated and tested, i know that it has server as primary installation source for many people where our WIKI has failed bad. Also, he has put a lot of effort and time there, i don't feel Ok on having a rip-off that looks exactly the same, even when i see there is an effort of contributing some extra steps/details here if it does not come from him or with his "blessing". Thoughts? Maybe i'm missing something

[csqrs]

@DiegoPino Yes, I completely agree that a lot here has come form DigiBESS, and I thought I had made that clear. I'm happy to make it more clear. My goal with this pull request was to update this wiki to Ubuntu 16. Much here is a direct update, based on my own work. I worked through the old instructions on an Ubuntu 16 machine and adapted as I went. The material from DigiBESS is presented mostly as optional, notably inclusion of Blazegraph and Cantaloupe and a more recent Solr. Would you prefer that these not be included?

[lutaylor]

@csqrs

Thanks for making the effort! This looks great. I made a few comments and linked some additional reference documentation that you can check out. I have not had the opportunity to revisit https://github.com/islandora-interest-groups/Islandora-DevOps-Interest-Group/blob/master/Deployment%20Guides/Provisioning-Islandora-on-Ubuntu.md in quite some time and it could use some TLC.

@DiegoPino Before now I was unaware of the existence of http://dev.digibess.it/doku.php?id=reloaded:be_repmulg and it does contain a lot of good information. Any information copied or borrowed should be recognized with the ok of @giancarlobi

[DiegoPino]

@csqrs thanks, I will wait for @giancarlobi to answer on how to attribute his work. Removing it would be bad I feel since you followed his guide to get your deployment done and refined? (if I understood that correctly).

@lutaylor has been there since forever, was the first working guide I could follow from start to end and I can say for sure a lot of deployments in the wild have used it and what got me into Islandora actually! (old good times)

Do we need an CLA for this also? Thanks to all of you!

[giancarlobi]

@csqrs @lutaylor My step-by-step guides are free and open-access for all people, so feel free to use all contained material for this project. The only thing I "need" is highlight from where that comes due to CC License, I'll add more steps about views and more features, so you don't need to ask me each time if you follow CC License: no profit and mention source, could be in the readme or something like this. I'm happy to share these open-guides and I'd like them will be open also in the future.

[bryjbrown]

@DiegoPino So should we merge this, or are we waiting on something?

[csqrs]

Folks. Thanks for the feedback and discussion. I'll update to include the recommended modifications and additional documentation, and also make more clear the debt to DigiBESS. Thank you, @giancarlobi , for an excellent guide!

And, also of course, thank you @lutaylor ! The original guide is indispensable.

[csqrs]

I've incorporated more documentation and some updates, as suggested by @lutaylor . And I've tried to be clearer about my debt to DigiBESS and @giancarlobi .

[giancarlobi]

Perfect @csqrs , many thanks !!

[DiegoPino]

@csqrs thanks! All my concerns are addressed.

[csqrs]

@lutaylor I'm bumping into a couple of bugs in the deployment. Should have fixes later today.

[lutaylor]

@csqrs Are you done with the fixes?

[giancarlobi]

That was for testing. The idea is don't install Adore anymore. In addition, Cantaloupe on separated VM can be useful for serving more Fed/Isla platforms with 1 Cantaloupe. Giancarlo

Il Lun 14 Mag 2018, 18:19 csqrs notifications@github.com ha scritto:

@csqrs commented on this pull request.

In Deployment Guides/Provisioning-Islandora-on-Ubuntu-16.md https://github.com/islandora-interest-groups/Islandora-DevOps-Interest-Group/pull/48#discussion_r188014020 :

+ +wget $SOLR_URL + +tar -xf $SOLR_NAME.tgz + +If you wish to install Solr under the same Tomcat as Fedora, do the following: + +cp -r $SOLR_NAME/example/solr $FEDORA_HOME/solr + +cp $SOLR_NAME/example/webapps/solr.war $CATALINA_HOME/webapps/ && unzip -o $SOLR_NAME/example/webapps/solr.war -d $CATALINA_HOME/webapps/solr + +mkdir $FEDORA_HOME/solr/$SOLR_DEFAULT_CORE_PATH/data + +chown -R $FEDORA_USER:$FEDORA_USER $FEDORA_HOME +``` +If you wish to install Solr under its own container, do the following (from http://dev.digibess.it/doku.php?id=reloaded:be_solr). We use Jetty, rather than Tomcat, because that's what the Solr developers have chosen to use ("Only Jetty recieves testing... No tests are done with other containers before release..." (http://lucene.472066.n3.nabble.com/difference-between-apache-tomcat-vs-Jetty-td4096680.html)).

Also, DigiBESS puts Adore-Djatoka under the Blazegraph Tomcat, while I followed the older version of this document and put it under the Fedora Tomcat. I mention putting it under Blazegraph as an option. But I guess there's a move away from that to Cantaloupe anyway...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/islandora-interest-groups/Islandora-DevOps-Interest-Group/pull/48#discussion_r188014020, or mute the thread https://github.com/notifications/unsubscribe-auth/AECT8tFQtUtMh-C6XtXLQJ7mC2IwnRwkks5tya6SgaJpZM4TzCOP .

[giancarlobi]

@lutaylor @DiegoPino @csqrs I successfully upgraded Cantaloupe 3.4 to 4.0. You can find here my steps. Just in case you think add this to the Guide.

[csqrs]

@giancarlobi I've updated to 4.0 as you suggested.

[csqrs]

I'm going to be on vacation for the next 3 weeks, so won't be able to respond to suggestions etc.

[csqrs]

Ah. Right. Missed that. So that's why you enabled the endpoint API. ;) Will fix shortly.

[giancarlobi]

Yes, it's the only reason, I don't like open doors  but in this case we need it.

On 29/06/2018 14:48, Craig Squires wrote:

Ah. Right. Missed that. So that's why you enabled the endpoint API. ;) Will fix shortly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/islandora-interest-groups/Islandora-DevOps-Interest-Group/pull/48#issuecomment-401344107, or mute the thread https://github.com/notifications/unsubscribe-auth/AECT8ty_45RjWZYrIX4hx7xvqm-_zWASks5uBiIegaJpZM4TzCOP.

[csqrs]

Thanks @giancarlobi . Works for me.

[csqrs]

@giancarlobi @DiegoPino @lutaylor Following the conversation here:

https://groups.google.com/forum/?pli=1#!topic/islandora-dev/18rWjTRdCS0

I've updated the "install Blazegraph" section to include running it "standalone". It turns out it's pretty easy, and works for me. Maybe we should replace the first option with the second. That would remove some concerns about running so many Tomcats.

[giancarlobi]

@csqrs thanks, I really think that running it standalone is the best solution for the whole stack. I have no experience with BZ standalone but I'd like to test/migrate to this solution, maybe later in August.

[DiegoPino]

@giancarlobi @csqrs we run Blazegraph as standalone (Jetty based) Service in Ubuntu for some of our partners and it works pretty well. Only issue is that you need to be aware of the real memory needs of this and reduce on the other side what you give to tomcat to make everything work faster/stable, or you could end over assigning resources to JVM stuff or worst, to little. If you need me to share some of my settings feel free to ask 👍 i really see good work happening here =)

[giancarlobi]

@csqrs sorry, maybe I'm wrong, do you have to also copy https://github.com/discoverygarden/blazegraph_conf to stand alone installation?

[csqrs]

@giancarlobi As far as I can tell, the DG blazegraph config is not needed. The deb installs what's needed in /etc/blazegraph/ as well as an 'init' script in /etc/init.d/. If you install the deb on top of an existing installation based on the DG material, the init file will get clobbered. ;)

Also, @DiegoPino there's a handy "testing" java options line in /etc/default/blazegraph installed by the deb that lets you give just a small amount of memory for testing.

[giancarlobi]

@csqrs great, many thanks !!!

[lutaylor]

@csqrs @giancarlobi @DiegoPino Hello folks,

The RWstore.proproperties file might need to be tweaked a bit. I am not sure what is provided with the deb or how it performs. The example in the https://github.com/discoverygarden/blazegraph_conf is based on the quads RWstore.properties sample for NanoSparqlServer https://wiki.blazegraph.com/wiki/index.php/NanoSparqlServer. The sample to date has scaled well with large installations with millions of objects. I have been meaning to try out the deb as a possible alternative for the Tomcat setup. Has anyone used it yet on a larger install? e.g. over a million objects?

[csqrs]

@lutaylor Comparing the two configs, there are some differences, though the deb provided one is also 'quads'. I certainly haven't tested it on a large installation. @DiegoPino can probably speak to that, since he's seen some real installations.

The most notable differences have to do with the 'btree' 'branchingFactor' values (smaller in the deb provided conf) and an 'rdf' related 'textIndex' is 'false' in the deb provided conf while 'true' in the DG conf, it seems to me. But I'm no expert.

Also, the log level is set to WARN by default by the deb, but ERROR by the DG provided log4j config.

I'll add some comments about these differences, as well as the java memory requirements.