Hi everyone. I've just pushed some updates I had on my working branch for the KohaDevBox: Updates: (a) Support for setting ElasticSearch 5.1 (b) Fixes for instance creation errors Details: (a) For supporting ElasticSearch 5.1 I've removed references to '2.x' in the code (either for repository configuration or display messages). So you should now set in your vars/user.yml file either: elasticsearch_version: '5.x' elasticsearch_version: '2.x' elasticsearch_version: '1.7' for the desired ES version. (Note: the quotes are required) ES 5.1 requires higher RAM availability so I made the Vagrantfile set 4GB of RAM when KOHA_ELASTICSEARCH=1 is set in ENV when doing the 'vagrant up' command. You can tweak the Vagrantfile locally to whatever you want (lower value?). This has all been documented on the README.md file This should be enough for being able to test https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17255 If there's something missing, please file a bug in https://github.com/digibib/kohadevbox/issues/new so we take care of it. As usual, pull requests are welcome. (b) There have recently been some changes on the koha-* scripts so they don't (only) have hardcoded paths, but accept a new entry in koha-conf.xml (<dev_install>) which specifies the place to pick the source code from. Pretty cool! But this made koha-gitify fail to set all it is needed to keep working as we did before. As a workaround I've added a fixed <dev_install>{{ vagrant_home_dir }}/kohaclone</dev_install> entry to the koha-conf-site.xml.in file we ship with KohaDevBox. Ideally, we should just add --dev-install and --dev-install-dir options to koha-create and just (probably) deprecate koha-gitify. I'm not sure what is the best solution. koha-gitify does lots of path fixes in places that are not related to koha-* scripts (zebra configuration files, koha-conf.xml itself, etc). I'm raising this so we can discuss the best way to deal with this. Having a koha-gitify-like feature baked inside Koha is not a bad idea at all! I'd like to highlight that I haven't succeeded in figuring why installing Test::DBIx::Class fails randomly. I blamed CPAN mirrors at some point because the default one was returning 'not found' when fetching the sources. But that doesn't seem to be the ONLY cause for failures. Any help on this is welcome. The way to check what's going on is to comment out that step and log into the box and cpanm manually. The most important on this regard: don't feel bad when the box fails to load because of this stuff. Remember you can 'continue' the process by reprovisioning. It is important to keep in mind that you need to do it with the same params you chose for 'vagrant up'. For example, I always do: $ KOHA_ELASTICSEARCH=1 SKIP_WEBINSTALLER=1 CREATE_ADMIN_USER=1 vagrant up so, if it fails to install something (temporary network issues? the weird Test::DBIx::Class random failure?) I always do: $ KOHA_ELASTICSEARCH=1 SKIP_WEBINSTALLER=1 CREATE_ADMIN_USER=1 vagrant provision No need to halt and reload the machine. I'm not sure why people are doing it, but don't. Unless you have specific reasons to do so. It will eat a couple minutes from your time with no evident advantage. Thanks for reading, and for the recent pull requests we've got. Have a great weekend! Tomás -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F