One-click automated Islandora installation now available

[suh...@gmail.com]

Hi everyone,

Several months ago, I set out to install Islandora, and encountered many of the problems, confusion, and frustration that others have doubtlessly shared.  The Islandora team has done a great job with this software, but the reality is that it's very complex and getting it installed remains a significant barrier to implementation.  In the interest of both solving my own problem and helping the community, I set out to develop a set of Chef cookbooks to install and configure Islandora and its constituent parts.  Today I am very happy to share with the Islandora community the result of several months worth of hard work.

The cookbooks are:

1) Fedora (currently 3.7.0): https://github.com/ryersonlibrary/fedora ; with options for Derby, MySQL, or PostgreSQL

2) Solr (currently 4.2.0): https://github.com/ryersonlibrary/solr

3) Fedora GSearch (currently 2.6): https://github.com/ryersonlibrary/gsearch

4) Adore Djatoka (currently 1.1): https://github.com/ryersonlibrary/djatoka

and of course, most importantly:

5) Islandora: https://github.com/ryersonlibrary/islandora

Each cookbook comes with a Vagrant configuration and Berkshelf integration, to make creating a VM or deploying to a Vagrant provider (eg. DigitalOcean or LXC/Docker) as easy as possible.  It does require a minimal understanding about how Chef works, but everything Just Works™ out-of-the-box with sane default usernames, passwords, etc.  Each cookbook has been tested on Ubuntu 12.02 (our preferred OS), but also CentOS 5.6.  If you are using Chef to deploy to an existing box via SSH, you'll probably want to use knife-solo.

Architecture-wise, the Islandora cookbook is split into two "roles":

a) Backend: a Tomcat 6 instance containing Fedora, Solr, GSearch, and DJatoka

b) Frontend: a LAMP instance containing Drupal 7 configured for Islandora

By default these roles are both assigned to the same VM (the same way the Islandora installation documentation is designed), but these could be split into two separate boxes for whatever security/scalability/redundancy reason, although this hasn't been extensively tested.

Creating a local VM using the Islandora cookbook (ie. the simplest way to get started).  You will need to have Ruby (1.9+), Vagrant, and Virtualbox installed.

1. Install the berkshelf and omnibus plugins for vagrant (you only need to do this once):

vagrant plugin install vagrant-berkshelf
vagrant plugin install vagrant-omnibus

2. Download and configure the Islandora cookbook from github:

git clone https://github.com/ryersonlibrary/islandora
cd islandora

bundle

berks

3. Start a new VM and watch Chef configure and install Islandora for you:

vagrant up

4. There is no step 4.

Building a fresh VM takes about 20-30 minutes on the machines I've been using, dictated mostly by network speed (downloading packages).

Finally, and most importantly, this is just a first (next?) step toward making Islandora easier for everyone to install and use.  Support for large images (Djatoka / Seadragon / etc) in particular needs work, as doubtlessly do other modules.  We are open to comments, criticism, bug reports, feature requests, forks/pulls, anything and everything that helps improve the code.

We are immensely grateful to Graham Stewart and the folks at University of Toronto Libraries for starting this work in 2012 and sharing their code (which this builds upon).  He even gave a talk about using Chef with Islandora at the Access 2012 conference, so watch the video!

MJ Suhonos

Digital Technologies Development Librarian

Ryerson University Library & Archives

mjsu...@ryerson.ca

[Nick Ruest]

MJ-

I know how how much effort, and the tremendous amount of work you put in
on all of this. These contributions are a tremendous boon for the
community, and I hope will be very beneficial for the upcoming 7.x-1.3
release.

Thank you *very* much!

-nruest

On 14-02-26 09:02 AM, suh...@gmail.com wrote:
> Hi everyone,
>
> Several months ago, I set out to install Islandora, and encountered many
> of the problems, confusion, and frustration that others have doubtlessly
> shared. The Islandora team has done a great job with this software, but
> the reality is that it's very complex and getting it installed remains a
> significant barrier to implementation. In the interest of both solving
> my own problem and helping the community, I set out to develop a set of

> Chef <http://en.wikipedia.org/wiki/Chef_(software)> cookbooks to install

> and configure Islandora and its constituent parts. Today I am very
> happy to share with the Islandora community the result of several months
> worth of hard work.
>
> The cookbooks are:
>
> 1) Fedora (currently 3.7.0): https://github.com/ryersonlibrary/fedora ;
> with options for Derby, MySQL, or PostgreSQL
> 2) Solr (currently 4.2.0): https://github.com/ryersonlibrary/solr
> 3) Fedora GSearch (currently 2.6): https://github.com/ryersonlibrary/gsearch
> 4) Adore Djatoka (currently 1.1): https://github.com/ryersonlibrary/djatoka
>
> and of course, most importantly:
>
> 5) Islandora: https://github.com/ryersonlibrary/islandora
>
> Each cookbook comes with a Vagrant

> <http://en.wikipedia.org/wiki/Vagrant_(software)> configuration and
> Berkshelf <http://berkshelf.com> integration, to make creating a VM or

> deploying to a Vagrant provider (eg. DigitalOcean or LXC/Docker) as easy
> as possible. It does require a minimal understanding about how Chef
> works, but everything Just Works™ out-of-the-box with sane default
> usernames, passwords, etc. Each cookbook has been tested on Ubuntu
> 12.02 (our preferred OS), but also CentOS 5.6. If you are using Chef to
> deploy to an existing box via SSH, you'll probably want to use

> knife-solo <http://matschaffer.github.io/knife-solo/>.

>
> Architecture-wise, the Islandora cookbook is split into two "roles":
>
> a) Backend: a Tomcat 6 instance containing Fedora, Solr, GSearch, and
> DJatoka
> b) Frontend: a LAMP instance containing Drupal 7 configured for Islandora
>
> By default these roles are both assigned to the same VM (the same way
> the Islandora installation documentation is designed), but these could
> be split into two separate boxes for whatever
> security/scalability/redundancy reason, although this hasn't been
> extensively tested.
>

> *Creating a local VM using the Islandora cookbook* (ie. the simplest way

> to get started). You will need to have Ruby (1.9+), Vagrant, and
> Virtualbox installed.
>
> 1. Install the berkshelf and omnibus plugins for vagrant (you only need
> to do this once):
>
> |
> vagrant plugin install vagrant-berkshelf
> vagrant plugin install vagrant-omnibus
> |
>
> 2. Download and configure the Islandora cookbook from github:
>
> |
> git clone https://github.com/ryersonlibrary/islandora
> cd islandora
> bundle
> berks
> |
>
> 3. Start a new VM and watch Chef configure and install Islandora for you:
>
> |
> vagrant up
> |
>

> 4. *There is no step 4.*

>
> Building a fresh VM takes about 20-30 minutes on the machines I've been
> using, dictated mostly by network speed (downloading packages).
>
> Finally, and most importantly, this is just a first (next?) step toward
> making Islandora easier for everyone to install and use. Support for
> large images (Djatoka / Seadragon / etc) in particular needs work, as
> doubtlessly do other modules. We are open to comments, criticism, bug
> reports, feature requests, forks/pulls, anything and everything that
> helps improve the code.
>
> We are immensely grateful to Graham Stewart and the folks at University
> of Toronto Libraries for starting this work in 2012 and sharing their

> code <https://github.com/LibraryChef> (which this builds upon). He even

> gave a talk about using Chef with Islandora

> <http://www.youtube.com/watch?v=eTNBmy4ZznA> at the Access 2012

> conference, so watch the video!
>
> MJ Suhonos
>
> Digital Technologies Development Librarian
> Ryerson University Library & Archives
> mjsu...@ryerson.ca
>

> --
> You received this message because you are subscribed to the Google
> Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Melissa Anez]

A huge thank from the Islandora Foundation for doing this. I'm not sure I've ever seen a better case for sending out a thank-you Islandora t-shirt, so please send me a mailing address if you'll accept. You have our thanks (and awe!) regardless.

- Melissa

[Mark Jordan]

Dude this is amazing and fills a huge gap.

Mark

---

--

[Benjamin Wiens]

Good job MJ, this is a huge step into the right direction for Islandora. Installing Islandora from scratch can be quite challenging, this is good news for the community.

[Melissa Anez]

I couldn't wait to test this out, so I did. I've hit a block that I hope is just due to my ignorance and easily fixed.

Steps 1 and 2 went great (although I needed to install bundler, too). When I get to step 3, I get this:

The provider 'virtualbox' could not be found, but was requested to
back the machine 'default'. Please use a provider that exists.

 I'm in Mac OS. I definitely have virtualbox installed. Any suggestions?

- Melissa

[Melissa Anez]

Thanks to Ed Fugikawa for helping me sort through this. My version of Vagrant was too old. Upgraded to 1.4.3 and it's installing swimmingly now.

- Melissa

[Graham Faulkner]

Hi MJ,

This looks really promising -- thanks!  An someone new to Ruby, Chef and Vagrant, I have a few questions:

1. Is your Ubuntu 12.04 running in a VM (such as VirtualBox), or on a physical server?  Are you using the Desktop or Server version of Ubuntu?
2. Is there anything I need to install re: Chef on the Ubuntu machine before running the scripts, or should your scripts bring in everything I need?  I viewed Graham Stewart's presentation from Access 2013 and he was using 'chef-client' at some point, but I don't see any mention of using it in your notes.
3. What version of Ruby should the Ubuntu machine be running?

Any pointers in the right direction are greatly appreciated.  I have been trying to experiment with running your scripts using a Ubuntu 12.04 server VM within VirtualBox on my Mac OS X laptop, but haven't been successful yet. 

Cheers,

Graham

[suh...@gmail.com]

Hi Graham,

Great questions.  There is a learning curve with Chef, and part of the challenge has been changing practices in the Chef community since Graham gave his presentation at Access.  I'll answer your specific questions first, followed by a bit of an explanation that hopefully helps give a better picture of what's going on.

1. The answer is "both": a VirtualBox VM for testing, and a physical server for out production Islandora instance.  For both cases we are using the 64-bit Server version of Ubuntu 12.04.3.
2. No, this is what Omnibus is for (in the case of Vagrant), and the Opscode Installer (in the case of knife-solo).  In both cases, the scripts should just handle installing Chef on the Ubuntu server for you.

3. Omnibus/Opscode will handle installing Ruby on the Ubuntu machine, so you don't have to worry about versioning.

I realize that's probably not too helpful, so here's some more detail about how the pieces fit together.  First, some Chef terminology: we'll call our desktop (ie. the machine we are installing from) the "client", and the machine we are installing Islandora to the "node".  In Chef parlance, the "chef client" Graham refers to is actually called "chef-solo"; however, to address a number of shortcomings, Mat Schaffer extended its functionality into a client called "knife-solo", so that's what we use for building physical boxes.

Case 1: Installing a local VM using Virtualbox and Vagrant ("vagrant up")

- Vagrant reads a configuration for the VM (CPU, RAM, mapped ports, OS image, etc) from the Vagrantfile on the client and instructs VirtualBox to create a new VM

- once the VM is running, the vagrant-omnibus plugin logs in from the client via SSH and creates an environment for Chef to do its thing, including installing an appropriate Ruby version, etc. (preparing the node) via Omnibus

- once the node is prepared, the vagrant-berkshelf plugin reads required cookbooks from the Berksfile on the client, and tells Chef to install these cookbooks on the node

Case 2: Installing a physical server using knife-solo

- "knife-solo prepare user@hostname" logs in from the client via SSH and creates an environment for Chef to do its thing, including installing an appropriate Ruby version, etc. (preparing the node) vis the Opscode installer

- "knife-solo cook user@hostname" reads required cookbooks from the Berksfile on the client, and tells Chef to install these cookbooks on the node

So the process is similar for both cases, but Vagrant is a bit more complicated because it's defining and creating a new VM.  It's worth noting that knife-solo expects key-based (ie. password-less) SSH access to the node, and an account that has sudo, otherwise you'll manually have to re-enter the password several dozen times during the installation process.  I should also note that for Ubuntu deploys, I use a "baseline" cookbook that installs some useful prerequisites and updates the machine to all the latest packages before it starts installing anything Islandora-related -- this is included by default in the Vagrantfile.

If you're having specific issues installing a Virtualbox VM using Vagrant (Case 1 above) using the steps in my original post, I'm happy to help you through the process.  I'll make a point of being in the #islandora IRC channel today.

Hope this helps, and thanks to everyone for their kind words -- I'm really glad you like this work!

MJ

[Graham Faulkner]

Hi MJ,

Thanks for the clarifications -- I had misunderstood the nature of chef and was using it incorrectly. 

Now that I followed your suggestions I have been able to stand up a VM on my OS X machine (had to use sudo a few places to make sure the gems installed correctly).  However, what login/password do I use for logging into the server VM?  I'm trying to figure out how to connect to the server from my desktop/browser, and need to know the IP for it.

Again, thanks for your very helpful feedback. 

Cheers,

Graham

[Melissa Anez]

Graham,

The VM can be accessed at localhost:8181 and the username/password for user1 are as found here: https://github.com/gondoi/drupal-cookbook/blob/master/attributes/default.rb

- Melissa

[Graham Faulkner]

Hi Melissa,

Thanks for the speedy reply and for pointing out the information about the Drupal user1.  I was wondering about the username/password for the Ubuntu server VM itself (i.e. the precise64 vagrant/virtualbox instance).  i.e. how do I login to it so that I can see under the hood of the drupal/islandora setup?

Cheers,

Graham 

[suh...@gmail.com]

Hi Graham,

The default username/password for VMs created by Vagrant is vagrant/vagrant.

Hope this helps,

MJ

[Ed Fugikawa]

Graham,

  vagrant ssh will give you shell access on the VM

Ed

---

From: isla...@googlegroups.com <isla...@googlegroups.com> on behalf of Graham Faulkner <graha...@gmail.com>
Sent: Friday, February 28, 2014 10:58 AM
To: isla...@googlegroups.com
Subject: [islandora] Re: One-click automated Islandora installation now available

 

--

[Graham Faulkner]

Thank you Ed and MJ for your responses.  I was able to login using vagrant/vagrant. 

Cheers,

Graham

[Peter .]

I must be the special one here.

I tried installing with Vagrant on a windows host. I get the error that it failed to fetch updates from the ubuntu archives repository. Looking at the output, it failed either downloading mailutils or guile-1.8-lib_1.8.8+1-6ubuntu2_amd64.deb. Complains about a bad header. How do I fix this?

Thanks.

[Peter .]

Nevermind, I figured it out.

[Peter .]

It seems that I keep getting bad headers when trying to download from the ubuntu repositories with the install scripts. Am I the only person experiencing this problem?

[Peter .]

Hi,

Can youp post more detailed information about how to install this on a physical server. I have looked at the knife-solo project page and the instructions aren't very clear to me. My understanding is that on one machine you install ruby 1.9.1 and ruby gems and knife-solo. Once that is installed, download the islandora cookbook from the git repository and then cd into the islandora cookbook directory. Next execute the comand:

knife-solo prepare user@machine_to_install_on.

After that execute knife-solo cook user@machine_to_install_on.

Is this correct or am I wildly off base here?

Thanks,
Peter

[suh...@gmail.com]

Hi Peter,

The process you describe sounds about correct.  After you download/cone the islander cookbook from github and cd into that directory, you'll also have to do:

bundle
berks

Bundle checks the gemfile to ensure that the appropriate gems (knife-solo, berkshelf) are installed, and berks ensures that all of the required cookbooks are installed.  Once you've done that, you should be able to use the two knife-solo commands to install your machine.

Hope this helps,

MJ

[Peter .]

Thanks, much appreciated! What was also tripping me up is that the knife command should be knife solo and not knife-solo (no hyphen). However I do get several warnings. One is that /home/peter/islandora/site-cookbooks does not exit. I am in the islandora directory when I execute knife solo cook user@hostname. In that directory, there is no site-cookbooks directory just cookbooks which would explain the error. I am wondering in order to get this to work if I need to install chef-solo on the node and copy the islandora directory there as well.

[suh...@gmail.com]

Peter, my apologies.  I got tripped up on the same thing myself last week and forgot to make a note of it in the thread.  All references are to knife-solo, but yes, you're absolutely right, the command is actually "knife solo".  Don't worry about the notice about the existence of a site-cookbooks directory; this is not necessary thanks to Berkshelf (which is now integrated into knife-solo).  If you get a clean Chef run with knife solo, then your node should be properly provisioned.

MJ

[Peter .]

Good to know. Having gone through the process, the message I get the end is tthat Chef Client finished 0/0 resources updated. That doesn't seem right to me. Granted the machine already had apache, mysql and fedora installed but it should have installed drupal, its modules and what not, so I would have expected some resources to be updated.When I visit the webpage, I only see the test page that apache was installed correctly. Something has gone amiss. I am installing this on CentOS 6.5. Any ideas of what I should be looking at (I can't seem to find any log files for chef).

Thanks,
Peter

[suh...@gmail.com]

Hi Peter,

Chef is designed to be idempotent, so if something is already installed, it will recognize such and simply skip over it -- Graham talks about this in his presentation.  That said, these cookbooks are designed to be run on a bare server without anything already installed, so I can't predict how Chef will interpret existing applications and decide to skip them or not.  By default Chef sends a lot go logging information to the console on which it was run, so that's the best place to look.

MJ

[Peter .]

Hi,

After using this to bring up a vagrant vm, which it seems to complete and I can view the site, I noticed that fedora is not actually running in the vm. You can verify this by going to ip_address:8080/fedora (solr is running though).

Something failed in the installer. It looks to be the same issue I am currently having hand balming a server.

Peter

[Mark McFate]

Good morning all.  Sorry for joining this conversation so late, but I wanted to just say thank you to all who have been exploring this DevOps approach to Islandora configuration.  And special thanks to MJ for pushing this forward to Vagrant and Chef, and for sharing that work.

I picked up Vagrant last summer after the OR 2013 conference but my immediate reaction to it was, perhaps,  short-sighted... I really didn't think I had time to learn another system (or two) just to help with baseline system configuration.  Well, after too many failed attempts (not outright failures, but too many headaches and bumps in the road for my comfort zone) I've recently come back to Vagrant and Puppet for salvation.  So far, so good...I am impressed with what these tools can do for me (us). 

I'm an engineer and have never been one to implement anything I don't fully understand.  My nature is to try and take things apart, if  only to satisfy my curiousity and to know that (if?) I can rebuild them correctly. So the notion of just cloning a repo, tweaking a couple of parameters, and doing a "vagrant up" - while attractive at many levels - isn't enough for me. 

Unfortunately, I'm also reluctant to pick up Chef because I have NO Ruby skills.  While I'd love to learn Ruby (and Chef), it's just not something I believe I can find time for right now.  But I've been wrong in that regard before... I thought the same about Vagrant last summer.   

So this past week I've been looking at MJ's work (and others) while playing with Vagrant and Puppet.  Yesterday I even launched a copy of the new Islandora-7x-13-test VM (works nicely!) and installed a copy of Blueprint (https://github.com/devstructure/blueprint) there with an intent to reverse-engineer that VM and produce a set of Puppet manifests with which it could be rebuilt.  It worked, but not all that well.  Blueprint failed to pick up on LOTS of required bits, too many to make that approach worthwhile I believe.  8^(

So today I am once again wondering...Should I continue trying to create a Puppet-provisioned Islandora VM?  Is that worth having?  Has anyone already done this, or tried and given up?  Or, is there enough Chef momentum in this effort to warrant my learning some Ruby and Chef skills to be worthwhile?     

Thanks for any concerns, questions, experience, advice, encouragement...you care to offer.  Take care.

- Mark

[Pottinger, Hardy J.]

Hi, Mark, I'm sure someone else will point this out, but both Chef and
Puppet are Ruby-based. The big difference between them is that Chef is
"procedural" where Puppet is "model-driven," in other words, with Chef you
end up writing "recipes" for how to end up with a working server, whereas
with Puppet you end up describing what that server *should look like*.
Chef has a distinct appeal to developers, as we tend to think
procedurally. Puppet appeals to sysadmins, as it reflects how they prefer
to think, (is it working?). Chef recipes are pretty much just Ruby, where
Puppet uses its own "domain specific language".

However, I have worked with Vagrant and Puppet [1], and there's a bunch of
re-usable patterns in that work that could serve as a starting point for
other puppet-based work environments. There's also an omnibus package for
puppet [2] if the idea of walking away from omnibus is a little scary.

Which is, I think, my way of saying, "Yeah, Mark, I'd be interested." :-)

Now, I'm mostly a DSpace guy, so, what's in it for me? Well, I really
would like to have a first class Puppet module for installing DSpace, and
to get away from being dependent on an Ubuntu base image. I'd love to find
and use a Puppet module for installing Tomcat that can replace our own
module, particularly one that allows us to use either a CentOS or Ubuntu
base image. One of the most compelling reasons to use Vagrant is to have a
dev environment that mirrors our production environment, and, our
production environment is based on RHEL/CentOS.

So, anyway, apologies for kinda/sorta hijacking the thread a bit, but I am
serious, I'd like to help with making a Vagrant + Puppet version of MJ's
work.

[1] https://github.com/dspace/vagrant-DSpace
[2] https://github.com/andytinycat/puppet-omnibus
--
HARDY POTTINGER <potti...@umsystem.edu>
University of Missouri Library Systems
http://lso.umsystem.edu/~pottingerhj/
https://MOspace.umsystem.edu/
"Do you love it? Do you hate it? There it is, the way you made it."
--Frank Zappa

>--
>You received this message because you are subscribed to the Google Groups
>"islandora" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to
>islandora+...@googlegroups.com.

>For more options, visit https://groups.google.com/d/optout.

[Mark McFate]

Thanks for the quick reply Hardy.  

I've gotten familiar enough with the tools in the last week to understand the differences, and you are absolutely correct.  I think my preference for Puppet is two-fold:  

1) Yes, both Puppet and Chef are built in Ruby, but Puppet introduces a language that seems more like the PHP that Islandora developers (myself included) may be comfortable with.  The model-driven approach does take a little getting used to but it makes perfect sense to me.

2) I recently read a study (see http://www.erikaheidi.com/) suggesting that Puppet is the more popular tool, except among Ruby developers, and especially so in the PHP community.  Misery loves company, so here I am!

I am encouraged that there's a shared interest here and will continue to push this forward as I can.  In particular, Tomcat is also a pain in my side and I expect to spend some time today looking for (or building) Puppet resources to ease that pain.  I'll be sure to share anything I might find or create, for Tomcat or other components, which might be helpful at https://github.com/SummittDweller.  There's absolutely nothing worth sharing there yet...but I'm working on it!

Take care.

-Mark

You received this message because you are subscribed to a topic in the Google Groups "islandora" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/islandora/mEz2KAgVUs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to islandora+...@googlegroups.com.

[Nick Ruest]

I don't have much to add here, other than that I'm really happy to see
this conversation. A variety of community based automated installations
is of great benefit to the community!

...and w/r/t to Tomcat, I was reminded of this[1] helpful repo this
morning. I always forget about it. But, it could of be use.

cheers!

-nruest

[1] https://github.com/islandora/islandora_tomcat

> <mailto:potti...@umsystem.edu>>

> University of Missouri Library Systems
> http://lso.umsystem.edu/~pottingerhj/
> https://MOspace.umsystem.edu/
> "Do you love it? Do you hate it? There it is, the way you made it."
> --Frank Zappa
>
>
>
>
>
> On 3/27/14 10:30 AM, "Mark McFate" <summitt...@gmail.com

> <mailto:islandora%2Bunsu...@googlegroups.com>.

> >For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "islandora" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/islandora/mEz2KAgVUs4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> islandora+...@googlegroups.com

> <mailto:islandora%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --

> You received this message because you are subscribed to the Google
> Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora+...@googlegroups.com

> <mailto:islandora+...@googlegroups.com>.

[Pottinger, Hardy J.]

> In particular, Tomcat is also a pain in my side and I expect to spend
>some time today
> looking for (or building) Puppet resources to ease that pain.

Here's a lead for you, check out the Example42 modules [1]

Example42 has a whole suite of related modules, so you'd probably want to
"drink the cool-aid" if you pick any one of them up, and use them all.

The thing I like particularly about Vagrant-DSpace is the way we bootstrap
Puppet modules using the Librarian Puppet script. [2]

It's really cool to be able to just add a puppet module to the Puppetfile
[3] and then use the modules in the main module. However, this coolness
does come with a price, as our provisioning process is very
network-dependent... if we can't get to PuppetForge or GitHub, or there's
an error with the code we pull... then the whole environment ceases to
function. The PostgreSQL module from PuppetLabs is bad about that. My
workaround for that is to take regular snapshots with the
vagrant-vbox-snapshot plugin [4] so at least I have a known-good
environment associated with whatever work I'm doing (I usually name these
snapshots after the issue I'm working).

[1] https://github.com/example42/puppet-tomcat
[2]
https://github.com/DSpace/vagrant-dspace/blob/master/puppet-bootstrap-ubunt
u.sh
[3] https://github.com/DSpace/vagrant-dspace/blob/master/Puppetfile
[4] https://github.com/dergachev/vagrant-vbox-snapshot

--
HARDY POTTINGER <potti...@umsystem.edu>
University of Missouri Library Systems
http://lso.umsystem.edu/~pottingerhj/
https://MOspace.umsystem.edu/

"Some people, when confronted with a problem, think 'I know, I'll use
XML.' Now they have two problems." --Jamie Zawinski

>><mailto:islandora%2Bunsu...@googlegroups.com>.
>>For more options, visit
>https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

>
>--
>You received this message because you are subscribed to a topic in the
>Google Groups "islandora" group.
>To unsubscribe from this topic, visit
>https://groups.google.com/d/topic/islandora/mEz2KAgVUs4/unsubscribe

><https://groups.google.com/d/topic/islandora/mEz2KAgVUs4/unsubscribe>.

>To unsubscribe from this group and all its topics, send an email to
>islandora+...@googlegroups.com

><mailto:islandora%2Bunsu...@googlegroups.com>.
>For more options, visit
>https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Peter .]

Given all the headaches I have had with setting up Islandora, I would love to learn chef and create an installer like this.  Unfortunately I don't have the time to do that so I have created a bash install script that pretty much does everything necessary to get islandora up and running. I still have one issue with fedoragsearch that I am trying to fix so it isn't quite complete yet. But once it is done I should be able to have a islandora instance up and running in minutes.

[in...@princerupertlibrary.ca]

Hi folks,

I've been failing to rebuild our library's newspaper archive for about six months, so this sounds like a lifeline.

However, we've got the Drupal 6 version of Islandora running on a webserver that is one computer, and trying to have all the back end, (Fedora, Tomcat 6, Apache, and all the rest) in a specific database server.

Is this going to be useful at all for me? Even a partial build would be helpful, admittedly.

[suh...@gmail.com]

Hi,

Let me also echo Nick's sentiment that I'm happy to see this conversation progression.  I certainly don't have any opinions on Chef vs. Puppet, I simply used Chef because Graham @ UofT had already started Islandora Chef work, and I was somewhat familiar with it for my other projects.  There's certainly room to do it more than one way.

As for this particular question, the short answer is yes: breaking out the Chef recipes into a "frontend" and "backend" role was done specifically to address use cases like you're describing, where Drupal/Islandora is on one server, and the Tomcat stack is on another.  I can't comment on the Drupal 6/7 issue, though I'm sure the Islandora team and others could offer commentary here.

For what it's worth, I'll offer my apologies for the build issues people are experiencing in the 1.3 RC VM, and let you know that I'll be looking at addressing them ASAP (hopefully today) for the next RC.  The main issue here are the bits that haven't been templates in Chef, so they have to be done by hand.  Hopefully we can have the entire thing automated by the time 1.3 is released, so an *actual* one-click install is possible.  :-)

Wonderful to see so much interest in this approach.

MJ

[Aaron Collie]

Let me add my interest and commitment to "trying it out."

Can I also add a couple questions?

1. Most/many of us have existing stacks that have been clobbered together (or meticulously planned, but we are of the former type). How does this help us?
1. Would we want to take your scripts and try to customize them for our setup (e.g. we use the tomcat in Fedora, but mysql on a different server).
2. Or should we just run the build scripts, and then make our customizations after?
2. What happens to things like apache configs, database names/users/password (I'm particularly thinking about drupal multi-site installs)? These would presumably be different for every new install?
3. Can this be used in a configuration management sense to keep Dev & Production in exact sync in terms of dependencies and versions?

We are setting up a VM to test on, thanks for your hard work cognitively and at the keyboard.

-Aaron

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---

You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.

Visit this group at http://groups.google.com/group/islandora.

[MJ Suhonos]

Hi Aaron,

(replying from my email client, so I'm not sure if this will work correctly)

1. Most/many of us have existing stacks that have been clobbered together (or meticulously planned, but we are of the former type). How does this help us?

The main value I see in using the Chef/devops approach is in predictability and replicability; ie. it handles remembering all the twiddly little bits that usually comprise a clobbered-together installation.  Someone of the meticulously planned & deployed type probably wouldn't benefit much from it.

I also see value in it as "working documentation"; ie. instead of (more likely, in addition to) trying to maintain the existing wiki-based installation documentation, it's fairly easy to look into the Chef recipes and see all the steps explicitly involved in setting up an Islandora instance, in order.  It HAS to be both comprehensive and correct in order to work, so it essentially guarantees to be a canonical installation guide.

1. Would we want to take your scripts and try to customize them for our setup (e.g. we use the tomcat in Fedora, but mysql on a different server).

Most of the "customization" is done through manipulating Chef node attributes (usernames, passwords, port numbers, etc); an example of these for the current testing VM are here:

https://github.com/ryersonlibrary/islandora/blob/master/Vagrantfile#L39-L46

The tricky bit about attributes is they are merged from multiple sources, and have a bit of a weird precedence to them; see: http://docs.opscode.com/chef_overview_attributes.html

The other limitation is that some aspects of the recipes may not yet be customizable through attributes; eg. PHP's memory_limit, etc.  So abstracting/adding more requires modifying the recipes.  I see this as an opportunity for the community to contribute back work that's relevant for their installation.  This is what Github and open source is all about.

2. Or should we just run the build scripts, and then make our customizations after?

There will *always* be a need for general sysadmin; the devops work really only helps in provisioning, and everyone's production installation will be different.  The goal is to automate and simplify the elements that are common to *every* (or almost every) Islandora install, and let you focus on the stuff that's specific to your implementation.

2. What happens to things like apache configs, database names/users/password (I'm particularly thinking about drupal multi-site installs)? These would presumably be different for every new install?

Not at all.  If these attributes are specified in the Chef deployment, then they are the exact same on every machine provisioned, every time.  Being able to replicate installs 100% is a key goal.  Due to Chef's legacy, there are several different ways to manage "storing a configuration for a node", the simplest being a JSON file (see "Cook command" here: http://matschaffer.github.io/knife-solo/).

In the video from Access 2012, Graham Stewart talks a bit about the notion of a VM being disposable; ie. instead of creating a server and then doing laborious piece-wise upgrades, you can simply create a *whole new VM* based on the same settings (but updated code/recipes) as your previous one, and replace it wholesale.  This is a totally new concept for sysadmin, admittedly, but it focuses on your data being the constant, not the server it lives on.

3. Can this be used in a configuration management sense to keep Dev & Production in exact sync in terms of dependencies and versions?

As above, absolutely yes.  The whole initial purpose of Vagrant in particular was to ensure that developers were building (and more importantly, bugfixing) against the *exact* same environment as the production machines to eliminate those unexpected gotchas.

For example, I can tell you exactly what version of every library is running on my production Islandora VM based on what's in a brand new dev VM, because they were both created by the exact same Chef recipes.  Some of the attributes (usernames, passwords) are different, but the rest is identical.  That's pretty powerful stuff, and it lets my team focus on the actual Islandora code instead of the stack it's built upon.

We are setting up a VM to test on, thanks for your hard work cognitively and at the keyboard.

Always happy to hear about your experiences / feedback.  Good luck!

MJ

-Aaron

On Mon, Apr 7, 2014 at 9:58 AM, <suh...@gmail.com> wrote:

Hi,

Let me also echo Nick's sentiment that I'm happy to see this conversation progression.  I certainly don't have any opinions on Chef vs. Puppet, I simply used Chef because Graham @ UofT had already started Islandora Chef work, and I was somewhat familiar with it for my other projects.  There's certainly room to do it more than one way.

As for this particular question, the short answer is yes: breaking out the Chef recipes into a "frontend" and "backend" role was done specifically to address use cases like you're describing, where Drupal/Islandora is on one server, and the Tomcat stack is on another.  I can't comment on the Drupal 6/7 issue, though I'm sure the Islandora team and others could offer commentary here.

For what it's worth, I'll offer my apologies for the build issues people are experiencing in the 1.3 RC VM, and let you know that I'll be looking at addressing them ASAP (hopefully today) for the next RC.  The main issue here are the bits that haven't been templates in Chef, so they have to be done by hand.  Hopefully we can have the entire thing automated by the time 1.3 is released, so an *actual* one-click install is possible.  :-)

Wonderful to see so much interest in this approach.

MJ

On Monday, March 31, 2014 7:25:09 PM UTC-4, in...@princerupertlibrary.ca wrote:

Hi folks,

I've been failing to rebuild our library's newspaper archive for about six months, so this sounds like a lifeline.

However, we've got the Drupal 6 version of Islandora running on a webserver that is one computer, and trying to have all the back end, (Fedora, Tomcat 6, Apache, and all the rest) in a specific database server.

Is this going to be useful at all for me? Even a partial build would be helpful, admittedly.

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
Visit this group at http://groups.google.com/group/islandora.
For more options, visit https://groups.google.com/d/optout.

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---

You received this message because you are subscribed to a topic in the Google Groups "islandora" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/islandora/mEz2KAgVUs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to islandora+...@googlegroups.com.

[Peter .]

I agree with everything MJ said about the benefits of having a one click install (especially the documentation part of it). In my installation script, you set the user name and passwords that you want to use, you can also list which Islandora modules you want to install to suit your particular needs. As for setting up a front end and backend server (which I need to do as well), you can break the script into two parts and then modify it to suit your circumstances. I am planning on releasing this script with our application once our application is ready to go.

[Mark McFate]

Good afternoon all.  I thought I would write here with a quick update and a question... 

I now have a Vagrantfile and a set of Puppet manifests that creates an Islandora server pair (a back-end running Fedora/Tomcat, etc. and a front-end running Drupal/Islandora) but they are not yet as reliable as I want them to be.  I have to say that working with Tomcat and Puppet has been a nightmarish experience... and I'm not over the hump just yet.

Now my adore-djatoka instance on the back-end is not starting...and I've looked at all the setup and can't yet determine why.  There are NO errors in my catalina.out file, only some seemingly harmless messages in fedora.out.    In fact, there's no mention of adore-djatoka anywhere in any log file that I have seen and the logdir that I've directed adore-djatoka to contins no such logs.

Anyone run into this and recall how to debug it?    

[Mark McFate]

Ok, I got adore-djatoka to at least start...silly mistake.  I'm not yet returning images but at least I now have some logs to work with.  I'll post again once I get this working.

-Mark

[Dennis Ogg]

I am on a Mac with Mavericks and ruby 2.0.0p451.

In trying to do the one-click install, I get to the point of executing "berks" and I get the following error.  Any suggestions that folks could offer to fix this issue would be greatly appreciated.

Thanks,
Dennis

$ berks
/Library/Ruby/Gems/2.0.0/gems/ffi-1.9.3/lib/ffi/library.rb:133:in `block in ffi_lib': Could not open library '/Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_gecode.bundle': dlopen(/Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_gecode.bundle, 5): Library not loaded: /private/var/folders/gl/6ygwqw6d027_59vtr73cdz300000gn/T/bundler20140804-52364-1d85666/dep-selector-libgecode-1.0.0/gems/dep-selector-libgecode-1.0.0/lib/dep-selector-libgecode/vendored-gecode/lib/libgecodesearch.32.dylib (LoadError)
  Referenced from: /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_gecode.bundle
  Reason: image not found
    from /Library/Ruby/Gems/2.0.0/gems/ffi-1.9.3/lib/ffi/library.rb:100:in `map'
    from /Library/Ruby/Gems/2.0.0/gems/ffi-1.9.3/lib/ffi/library.rb:100:in `ffi_lib'
    from /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_selector/dep_gecode.rb:39:in `<module:Dep_gecode>'
    from /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_selector/dep_gecode.rb:21:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_selector/gecode_wrapper.rb:21:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_selector/dependency_graph.rb:21:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_selector/selector.rb:21:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/dep_selector-1.0.3/lib/dep_selector.rb:22:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/solve-1.2.0/lib/solve/solver.rb:1:in `<top (required)>'
    from /Library/Ruby/Gems/2.0.0/gems/solve-1.2.0/lib/solve.rb:10:in `require_relative'
    from /Library/Ruby/Gems/2.0.0/gems/solve-1.2.0/lib/solve.rb:10:in `<module:Solve>'
    from /Library/Ruby/Gems/2.0.0/gems/solve-1.2.0/lib/solve.rb:3:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/berkshelf-3.1.1/lib/berkshelf.rb:8:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:73:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:73:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/berkshelf-3.1.1/lib/berkshelf/cli.rb:1:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:73:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:73:in `require'
    from /Library/Ruby/Gems/2.0.0/gems/berkshelf-3.1.1/bin/berks:3:in `<top (required)>'
    from /usr/bin/berks:23:in `load'
    from /usr/bin/berks:23:in `<main>

[Peter .]

Hi Mark,

Would it be possible to get a copy of your puppet and vagrant scripts? I am attempting to do the same thing (with vagrant and puppet) and I would like not to reinvent the wheel if I don't have to.

Cheers,
Peter

[suh...@gmail.com]

Hi Dennis,

I recently came across something similar to this when trying to update things in the recipe.  I think this might be related to vagrant-berkshelf updating to 3.0 and changing a bunch of dependencies around Berkshelf/Chef-DK (see the very top of http://berkshelf.com).  I've updated the documentation to reflect the need for the older version of vagrant-berkshelf:

https://github.com/ryersonlibrary/islandora/commit/dcdbd6bd5ab8b5293e6932a09c1cd5db219eb0b7

In the meantime, I would suggest the following:

1. Check your installed version of vagrant-berkshelf plugin:

vagrant plugin version

2. If it's higher than 2.0.1, uninstall it

vagrant plugin uninstall vagrant-berkshelf

3. Reinstall version 2.0.1 of the plugin (as per the updated documentation)

vagrant plugin install vagrant-berkshelf --plugin-version '= 2.0.1'

If you continue to have problems after this, I might also suggest refreshing and/or clearing out your berkshelf and/or Ruby gems, eg.

bundle update
berks update

Please let us know how you far with this process; Chef and Berkshelf have an annoying habit of making backwards-breaking changes that manifest in weird Ruby errors, and it's quite frustrating to narrow down.  I'm hopeful that as we clean up the Islandora Chef recipes to move them under the purview of the Foundation, we can identify and minimize these issues as much as possible.

Cheers,

MJ

[Dennis Ogg]

MJ,

Sorry about not getting back to you sooner.  I set up an ubuntu server and have been working on it instead.  Everything seem to be working fine.  I haven't had a chance to get back to my Mac yet, but will eventually and will let you know how it goes.

Thanks,
Dennis

[Micheal Grimard]

I'm just completely unable to get this working. I'm currently on OSX Yosemite, trying to set up a Vagrant server for testing purposes. When at the step of Vagrant Up, the error I get is -

The following berks command failed to execute:

    /opt/chefdk/embedded/bin/berks --version --format json

The stdout and stderr are shown below:

    stdout:

    stderr: /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'berkshelf' (>= 0) among 58 total gem(s) (Gem::LoadError)

Checked in 'GEM_PATH=/Users/mgrimard/.vagrant.d/gems:/Applications/Vagrant/bin/../embedded/gems', execute `gem env` for more information

from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/dependency.rb:322:in `to_spec'

from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_gem.rb:58:in `gem'

from /opt/chefdk/embedded/bin/berks:22:in `<main>'

Some information I've collected while trying to troubleshoot the issue -

$ which ruby

/opt/chefdk/embedded/bin/ruby

$ which berks

/opt/chefdk/embedded/bin/berks

$ $PATH

-bash: /opt/chefdk/embedded/bin:/opt/chefdk/bin:/Users/mgrimard/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:

Anyone else run into this?

[Micheal Grimard]

So I managed to get this running after some work. I was able to resolve my previous issue by running a previous version of the vagrant-berkshelf plugin and applying the fix in the readme. However, now that it is running I'm having an issue where Vagrant doesn't know that it is running. As such, my vagrant manager can't see it up and I can't SSH into it using vagrant ssh or halt it and any time I use vagrant up it goes through the entire fresh install process, but I can access the site using localhost:8181 so I know it's running.

Any ideas?

[Nick Ruest]

Have you tried `vagrant ssh` or `ssh -p 2222 vagrant@localhost`?

If that isn't working, toss a --vv in the second command, and check that
output. Also, check your known hosts and make sure you don't have a key
conflict.

-nruest

> --
> For more information about using this group, please read our Listserv
> Guidelines: http://islandora.ca/content/welcome-islandora-listserv
> ---
> You received this message because you are subscribed to the Google
> Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora+...@googlegroups.com

> <mailto:islandora+...@googlegroups.com>.

[Jennifer]

I decided to try this out on Ubuntu 14.04. I got Ruby 1.9.3 and vagrant, etc. I also had to get bundler. But when I bundle, I get this error message:

could not find mixlib-shellout-1.6.0 in any of the sources

I thought that it could my Ruby. So I went with Ruby 2.0 but that still had the same error message. Has anyone come across this?

Jennifer

[Jennifer]

Update...

I was able to solve the mixlib-shellout missing file. But now, when I put in the command "vagrant up". It fails to load the vagrant-bershelf plugin. I checked that it is the latest plugin following the instructions above and it still doesn't work.

Any ideas?

Jennifer

[suh...@gmail.com]

Hi Jennifer,

I would try double-checking that you have the appropriate version of the vagrant-berkshelf plugin installed; in particular, you might have to do:

vagrant plugin uninstall vagrant-berkshelf

vagrant plugin install vagrant-berkshelf --plugin-version '= 2.0.1'

Please note that Nick & I have done some work on the installer to simplify it and improve the documentation, including better handling of appropriate plugin / gem versions:

https://github.com/ryersonlibrary/islandora_chef#usage

Unfortunately, both Berkshelf and Chef have introduced more problems and fragility with more recent versions (and by adding/requiring Chef-DK), so the Islandora installer has been more difficult to use than intended.  We will try to keep maintaining it as much as possible, but in the longer time it might be a good idea for someone to port the recipes over to another system like Puppet or Anisble.

MJ

[Jennifer]

Hi MJ,

Thanks for the answer. I've tried the 1.2.0 and 2.0. Let me give the 2.0.1 a shot and see if that works. I know what you mean about the chef-dk, which was causing some problems as well. I'll update you on what happens. Wish me luck for the new year!

Jennifer

[Jennifer]

I just tried the version 2.0.1 and that also is throwing the error of unknown configuration section berkshelf. That's unfortunate. 

Jennifer

[Matthew Davis]

Hi all,

Is this one click install project still being updated such that it's useful?  After some fits and starts I was able to get everything working up to "vagrant up" - and vagrant seems to be working fine, but once it's up and chef starts to work its magic, I get the error which I've pasted below, which suggests that there is a problem with the chef cookbooks.  This is on an ubuntu 14.04.02 system with the most recent versions of Vagrant and the Chef DK installed, using the bundler package that comes with ubuntu and the berkshelf package that comes with the Chef DK, rather than installing them using the gem install method (I also got to the exact same error point building on a Windows 7 system).  Any help would be appreciated, even if it's just advice to move on.  Thanks!

==> default: [2015-07-27T15:10:56+00:00] INFO: Forking chef instance to converge...
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Fork successful. Waiting for new chef pid: 2190
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Forked instance now converging
==> default: Starting Chef Client, version 11.6.2
==> default: [2015-07-27T15:10:56+00:00] INFO: *** Chef 11.6.2 ***
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Building node object for islandora-berkshelf
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Extracting run list from JSON attributes provided on command line
==> default: [2015-07-27T15:10:56+00:00] INFO: Setting the run_list to ["recipe[ubuntu-baseline]", "recipe[islandora]"] from JSON
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Applying attributes from json file
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Platform is ubuntu version 12.04
==> default: [2015-07-27T15:10:56+00:00] INFO: Run List is [recipe[ubuntu-baseline], recipe[islandora]]
==> default: [2015-07-27T15:10:56+00:00] INFO: Run List expands to [ubuntu-baseline, islandora]
==> default: [2015-07-27T15:10:56+00:00] INFO: Starting Chef Run for islandora-berkshelf
==> default: [2015-07-27T15:10:56+00:00] INFO: Running start handlers
==> default: [2015-07-27T15:10:56+00:00] INFO: Start handlers complete.
==> default: [2015-07-27T15:10:56+00:00] DEBUG: No chefignore file found at /tmp/vagrant-chef/481ed07505c718072c7c963bc2cf9e50/cookbooks/chefignore no files will be ignored
==> default: Compiling Cookbooks...
==> default:
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Re-raising exception: Chef::Exceptions::CookbookNotFound - Cookbook apt not found. If you're loading apt from another cookbook, make sure you configure the dependency in your metadata
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/cookbook/cookbook_collection.rb:38:in `block in initialize'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.18.0/lib/ohai/mash.rb:77:in `yield'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.18.0/lib/ohai/mash.rb:77:in `default'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.18.0/lib/ohai/mash.rb:77:in `default'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:265:in `[]'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:265:in `each_cookbook_dep'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:243:in `add_cookbook_with_deps'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:244:in `block in add_cookbook_with_deps'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:266:in `each'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/
run_context/cookbook_compiler.rb:266:in `each_cookbook_dep'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:243:in `add_cookbook_with_deps'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:87:in `block in cookbook_order'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:85:in `each'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:85:in `cookbook_order'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:97:in `compile_libraries'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:70:in `compile'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context.rb:86:in `load'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:249:in `setup_run_context'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:492:in `do_run'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:199:in `block in run'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:193:in `fork'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:193:in `run'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application.rb:183:in `run_chef_client'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application/solo.rb:239:in `block in run_application'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application/solo.rb:231:in `loop'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application/solo.rb:231:in `run_application'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application.rb:66:in `run'
==> default:   /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/bin/chef-solo:25:in `<top (required)>'
==> default:   /usr/bin/chef-solo:23:in `load'
==> default:   /usr/bin/chef-solo:23:in `<main>'
==> default: [2015-07-27T15:10:56+00:00] ERROR: Running exception handlers
==> default: [2015-07-27T15:10:56+00:00] ERROR: Exception handlers complete
==> default: [2015-07-27T15:10:56+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
==> default: [2015-07-27T15:10:56+00:00] DEBUG: Chef::Exceptions::CookbookNotFound: Cookbook apt not found. If you're loading apt from another cookbook, make sure you configure the dependency in your metadata
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/cookbook/cookbook_collection.rb:38:in `block in initialize'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.18.0/lib/ohai/mash.rb:77:in `yield'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.18.0/lib/ohai/mash.rb:77:in `default'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.18.0/lib/ohai/mash.rb:77:in `default'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:265:in `[]'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:265:in `each_cookbook_dep'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:243:in `add_cookbook_with_deps'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:244:in `block in add_cookbook_with_deps'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:266:in `each'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:266:in `each_cookbook_dep'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:243:in `add_cookbook_with_deps'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:87:in `block in cookbook_order'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:85:in `each'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:85:in `cookbook_order'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:97:in `compile_libraries'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context/cookbook_compiler.rb:70:in `compile'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/run_context.rb:86:in `load'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:249:in `setup_run_context'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:492:in `do_run'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:199:in `block in run'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:193:in `fork'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/client.rb:193:in `run'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application.rb:183:in `run_chef_client'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application/solo.rb:239:in `block in run_application'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application/solo.rb:231:in `loop'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application/solo.rb:231:in `run_application'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/lib/chef/application.rb:66:in `run'
==> default: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.2/bin/chef-solo:25:in `<top (required)>'
==> default: /usr/bin/chef-solo:23:in `load'
==> default: /usr/bin/chef-solo:23:in `<main>'
==> default: Chef Client failed. 0 resources updated
==> default: [2015-07-27T15:10:56+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Chef never successfully completed! Any errors should be visible in the
output above. Please fix your recipes so that they properly complete.

On Wednesday, February 26, 2014 at 2:02:04 PM UTC, suh...@gmail.com wrote:

Hi everyone,

Several months ago, I set out to install Islandora, and encountered many of the problems, confusion, and frustration that others have doubtlessly shared.  The Islandora team has done a great job with this software, but the reality is that it's very complex and getting it installed remains a significant barrier to implementation.  In the interest of both solving my own problem and helping the community, I set out to develop a set of Chef cookbooks to install and configure Islandora and its constituent parts.  Today I am very happy to share with the Islandora community the result of several months worth of hard work.

The cookbooks are:

1) Fedora (currently 3.7.0): https://github.com/ryersonlibrary/fedora ; with options for Derby, MySQL, or PostgreSQL

2) Solr (currently 4.2.0): https://github.com/ryersonlibrary/solr

3) Fedora GSearch (currently 2.6): https://github.com/ryersonlibrary/gsearch

4) Adore Djatoka (currently 1.1): https://github.com/ryersonlibrary/djatoka

and of course, most importantly:

5) Islandora: https://github.com/ryersonlibrary/islandora

Each cookbook comes with a Vagrant configuration and Berkshelf integration, to make creating a VM or deploying to a Vagrant provider (eg. DigitalOcean or LXC/Docker) as easy as possible.  It does require a minimal understanding about how Chef works, but everything Just Works™ out-of-the-box with sane default usernames, passwords, etc.  Each cookbook has been tested on Ubuntu 12.02 (our preferred OS), but also CentOS 5.6.  If you are using Chef to deploy to an existing box via SSH, you'll probably want to use knife-solo.

Architecture-wise, the Islandora cookbook is split into two "roles":

a) Backend: a Tomcat 6 instance containing Fedora, Solr, GSearch, and DJatoka

b) Frontend: a LAMP instance containing Drupal 7 configured for Islandora

By default these roles are both assigned to the same VM (the same way the Islandora installation documentation is designed), but these could be split into two separate boxes for whatever security/scalability/redundancy reason, although this hasn't been extensively tested.

Creating a local VM using the Islandora cookbook (ie. the simplest way to get started).  You will need to have Ruby (1.9+), Vagrant, and Virtualbox installed.

1. Install the berkshelf and omnibus plugins for vagrant (you only need to do this once):

vagrant plugin install vagrant-berkshelf
vagrant plugin install vagrant-omnibus

2. Download and configure the Islandora cookbook from github:

git clone https://github.com/ryersonlibrary/islandora
cd islandora

bundle

berks

3. Start a new VM and watch Chef configure and install Islandora for you:

vagrant up

4. There is no step 4.

Building a fresh VM takes about 20-30 minutes on the machines I've been using, dictated mostly by network speed (downloading packages).

Finally, and most importantly, this is just a first (next?) step toward making Islandora easier for everyone to install and use.  Support for large images (Djatoka / Seadragon / etc) in particular needs work, as doubtlessly do other modules.  We are open to comments, criticism, bug reports, feature requests, forks/pulls, anything and everything that helps improve the code.

We are immensely grateful to Graham Stewart and the folks at University of Toronto Libraries for starting this work in 2012 and sharing their code (which this builds upon).  He even gave a talk about using Chef with Islandora at the Access 2012 conference, so watch the video!

MJ Suhonos

Digital Technologies Development Librarian

Ryerson University Library & Archives

mjsu...@ryerson.ca

[suh...@gmail.com]

Hi Matthew,

Sorry to hear you’re having problems.  I recall getting the ‘Cookbook apt not found’ error occasionally, but I’m afraid I don’t remember what the specific issue was.  Have you tried a ‘vagrant reload —provision’ after a fresh install?  I recall that fixing something.

We haven’t made any changes recently, but I wouldn’t be surprised if a pinned version or something is causing a problem from the upstream cookbooks.

The good news is that the project is still active; we actually have a branch contributed by Davor Cubranic at UBC (https://github.com/cubranic/islandora_chef) to bring the OS up to Ubuntu 14.04, though it doesn’t quite work yet.  We have also been streamlining our vagrant/chef practices for deploying AtoM (https://github.com/ryersonlibrary/atom_cookbook <https://github.com/ryersonlibrary/atom_cookbook> and https://github.com/ryersonlibrary/atom_vagrant<https://github.com/ryersonlibrary/atom_vagrant>), which I intend to use to rebuild the Islandora cookbook.

The bad news is that this isn’t a priority for us right now, so I probably won’t get a chance to work on it until the fall.  If someone wants to chip in and get started in the meantime, I’m happy to provide whatever guidance I can.

Hope this helps a bit,
MJ

[Pottinger, Hardy J.]

Hi, I'm not a regular user of this project, so I can't vouch for it's usability or stability at all... (sorry) but, you might want to take a look at https://github.com/Islandora-Labs/islandora/tree/7.x-2.x/install

I suspect that there are people on this list who *do* use this particular Vagrant environment regularly. I spun it up last month with very little fanfare: it "just worked."

HTH

--Hardy

---

From: isla...@googlegroups.com [isla...@googlegroups.com] on behalf of suh...@gmail.com [suh...@gmail.com]
Sent: Monday, July 27, 2015 12:54 PM
To: islandora
Cc: davi...@gmail.com
Subject: [islandora] Re: One-click automated Islandora installation now available

--

For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.

To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.

Visit this group at http://groups.google.com/group/islandora.

To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/a38b041f-68c7-47d3-bba7-511b5e16a036%40googlegroups.com.

[Nick Ruest]

That's actually vagrant build the Islandora 7.x-2.x project -- Islandora
& Fedora 4 integration.

There is another vagrant project in Islandora Labs, Islandora
Vagrant[1], which builds a development environment virtual machine for
Islandora 7.x-1.x (the existing stack). It should work on any operating
system that supports VirtualBox and Vagrant.

-nruest

[1] https://github.com/islandora-labs/islandora_vagrant

On 15-07-27 04:09 PM, Pottinger, Hardy J. wrote:
> Hi, I'm not a regular user of this project, so I can't vouch for it's
> usability or stability at all... (sorry) but, you might want to take a
> look at https://github.com/Islandora-Labs/islandora/tree/7.x-2.x/install
>
> I suspect that there are people on this list who *do* use this
> particular Vagrant environment regularly. I spun it up last month with
> very little fanfare: it "just worked."
>
> HTH
>
> --Hardy
>

> ------------------------------------------------------------------------
> *From:* isla...@googlegroups.com [isla...@googlegroups.com] on
> behalf of suh...@gmail.com [suh...@gmail.com]
> *Sent:* Monday, July 27, 2015 12:54 PM
> *To:* islandora
> *Cc:* davi...@gmail.com
> *Subject:* [islandora] Re: One-click automated Islandora installation

> set of Chef <http://en.wikipedia.org/wiki/Chef_(software)>

> cookbooks to install and configure Islandora and its constituent
> parts. Today I am very happy to share with the Islandora
> community the result of several months worth of hard work.
>
> The cookbooks are:
>
> 1) Fedora (currently 3.7.0):
> https://github.com/ryersonlibrary/fedora ; with options for
> Derby, MySQL, or PostgreSQL
> 2) Solr (currently 4.2.0): https://github.com/ryersonlibrary/solr
> 3) Fedora GSearch (currently 2.6):
> https://github.com/ryersonlibrary/gsearch
> 4) Adore Djatoka (currently 1.1):
> https://github.com/ryersonlibrary/djatoka
>
> and of course, most importantly:
>
> 5) Islandora: https://github.com/ryersonlibrary/islandora
>
> Each cookbook comes with a Vagrant

> <http://en.wikipedia.org/wiki/Vagrant_(software)> configuration
> and Berkshelf <http://berkshelf.com> integration, to make

> creating a VM or deploying to a Vagrant provider (eg.
> DigitalOcean or LXC/Docker) as easy as possible. It does
> require a minimal understanding about how Chef works, but
> everything Just Works™ out-of-the-box with sane default
> usernames, passwords, etc. Each cookbook has been tested on
> Ubuntu 12.02 (our preferred OS), but also CentOS 5.6. If you
> are using Chef to deploy to an existing box via SSH, you'll
> probably want to use knife-solo

> <http://matschaffer.github.io/knife-solo/>.

>
> Architecture-wise, the Islandora cookbook is split into two "roles":
>
> a) Backend: a Tomcat 6 instance containing Fedora, Solr,
> GSearch, and DJatoka
> b) Frontend: a LAMP instance containing Drupal 7 configured for
> Islandora
>
> By default these roles are both assigned to the same VM (the
> same way the Islandora installation documentation is designed),
> but these could be split into two separate boxes for whatever
> security/scalability/redundancy reason, although this hasn't
> been extensively tested.
>

> *Creating a local VM using the Islandora cookbook* (ie. the

> simplest way to get started). You will need to have Ruby
> (1.9+), Vagrant, and Virtualbox installed.
>
> 1. Install the berkshelf and omnibus plugins for vagrant (you
> only need to do this once):
>
> |
> vagrant plugin install vagrant-berkshelf
> vagrant plugin install vagrant-omnibus
> |
>
> 2. Download and configure the Islandora cookbook from github:
>
> |
> git clone https://github.com/ryersonlibrary/islandora

> <http://github.com/ryersonlibrary/islandora>

> cd islandora
> bundle
> berks
> |
>
> 3. Start a new VM and watch Chef configure and install Islandora
> for you:
>
> |
> vagrant up
> |
>

> 4. *There is no step 4.*

>
> Building a fresh VM takes about 20-30 minutes on the machines
> I've been using, dictated mostly by network speed (downloading
> packages).
>
> Finally, and most importantly, this is just a first (next?) step
> toward making Islandora easier for everyone to install and use.
> Support for large images (Djatoka / Seadragon / etc) in
> particular needs work, as doubtlessly do other modules. We are
> open to comments, criticism, bug reports, feature requests,
> forks/pulls, anything and everything that helps improve the code.
>
> We are immensely grateful to Graham Stewart and the folks at
> University of Toronto Libraries for starting this work in 2012

> and sharing their code <https://github.com/LibraryChef> (which

> this builds upon). He even gave a talk about using Chef with

> Islandora <http://www.youtube.com/watch?v=eTNBmy4ZznA> at the

> Access 2012 conference, so watch the video!
>
> MJ Suhonos
>
> Digital Technologies Development Librarian
> Ryerson University Library & Archives
> mjsu...@ryerson.ca
>
> --
> For more information about using this group, please read our Listserv
> Guidelines: http://islandora.ca/content/welcome-islandora-listserv
> ---
> You received this message because you are subscribed to the Google
> Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora+...@googlegroups.com

> <mailto:islandora+...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/islandora.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/islandora/a38b041f-68c7-47d3-bba7-511b5e16a036%40googlegroups.com

> <https://groups.google.com/d/msgid/islandora/a38b041f-68c7-47d3-bba7-511b5e16a036%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>

> --
> For more information about using this group, please read our Listserv
> Guidelines: http://islandora.ca/content/welcome-islandora-listserv
> ---
> You received this message because you are subscribed to the Google
> Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora+...@googlegroups.com

> <mailto:islandora+...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/islandora.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/islandora/2CD26578BFA8024EBE6C0B84324FAD46A1D1E9F8%40UM-MBX-T03.um.umsystem.edu
> <https://groups.google.com/d/msgid/islandora/2CD26578BFA8024EBE6C0B84324FAD46A1D1E9F8%40UM-MBX-T03.um.umsystem.edu?utm_medium=email&utm_source=footer>.

[Davis, Matthew O.]

Thanks Hardy,

That did indeed "just work"  Please forgive these beginner questions (I'm very much learning as I go right now), but can anyone clarify:

1.  What's the difference between this and the chef-reliant install?

2.  Are either of these usable as the base for publicly accessible production environments with proper modification of default passwords, or should they really only be thought of as useful for testing / in house environments?

[Pottinger, Hardy J.]

Hi, note that I am not affiliated in any way with the Islandora developers, and I'm only tangentially a member of the community. But, I will observe that the README for these Vagrant projects includes a disclaimer [1]

Paraphrase: Do not use in production.

What you do use in production is really up to you and any support staff you may have. It's entirely possibly the people who handle operations for you already have established practices and customs around provisioning and support applications. You're best off working within that environment. If, however, you're really "going it alone," before you try to re-purpose the provisioning scripts in any Vagrant-based project, I'd urge you to take a closer look at the whole provisioning tool "marketplace" and look for a tool that is a good fit for you, your team, and your workplace. Common contenders are: Puppet, Chef, and Ansible. And, before you get too far in that project, there is an Islandora DevOps interest group [2], which you should probably join.

Good luck!

--Hardy

[1] https://github.com/Islandora-Labs/islandora_vagrant/blob/master/README.md
[2] https://github.com/islandora-interest-groups/Islandora-DevOps-Interest-Group

---

From: Davis, Matthew O. [davi...@gmail.com]
Sent: Tuesday, July 28, 2015 9:35 AM
To: Pottinger, Hardy J.; isla...@googlegroups.com
Subject: Re: [islandora] Re: One-click automated Islandora installation now available

[suh...@gmail.com]

Hi Matthew,

Just to add to Hardy’s response:

1.  What's the difference between this and the chef-reliant install?

The mechanism they use is different, as Hardy describes.  Chef is intended to incorporate flexibility so that it’s possible to deploy the same recipes to different server environments (eg. various versions of Ubuntu as well as RedHat/CentOS).  I believe the script-based installation is tailored specifically to Ubuntu.

In practice, Islandora is really only supported on Ubuntu, so that’s what the current Chef cookbook is designed for (and tested on).  A major impetus for our refactoring work will be to include support for CentOS/RHEL so you can install Islandora on more platforms (since we will be moving our production OS from Ubuntu 12 to RHEL 7).

2.  Are either of these usable as the base for publicly accessible production environments with proper modification of default passwords, or should they really only be thought of as useful for testing / in house environments?

Every disclaimer you see will say “don’t use this for production” so that people don’t get a sense of false confidence (and/or get upset when there’s an issue).  I will say that our production Islandora instance (http://digital.library.ryerson.ca) was deployed using the Vagrant-Chef cookbook over a year ago and it has been working as expected since.  So, it certainly *can* be used for production, but you’ll still have to be hands-on in supporting your production instance; eg. ensuring security, performance, etc.

MJ

[Davis, Matthew O.]

Thanks all!

[BrzI Channel]

So if I read this correctly, it needs a VirtualBox setup.

If I want to build a physical server or a VMware VM I still need to do a full manual setup ?

Thanks

[suh...@gmail.com]

Hi,

If you're provisioning to an existing server or VM via SSH, you'll need to use "knife solo" to deploy instead of vagrant.  Have a look at the discussion earlier in this thread:

https://groups.google.com/d/msg/islandora/mEz2KAgVUs4/be0y0Hc4fPMJ

MJ

[suh...@gmail.com]

For those who are interested in a little more explanation about the relationship between vagrant, chef, and islandora, the presentation I gave last year at IslandoraCamp GTA is available here: http://www.slideshare.net/robotninja/installing-islandora-with-vagrant-chef

MJ