eZ Platform Discussions

Install eZ Platform 2.2 with eZ Launchpad


#1

Good evening guys,

I am trying to install the latest version of ez Platform through eZ LunachPad (ez init)

Apparently there is a problem with solr. problem of rights !!!

ez logs display

solr_1 | mkdir: cannot create directory ‘/ezsolr/server/ez’: Permission denied
solr_1 | cp: cannot create regular file ‘/ezsolr/server/ez’: Permission denied
solr_1 | cp: target ‘/ezsolr/server/ez/template’ is not a directory
solr_1 | sed: can’t read /ezsolr/server/ez/template/solrconfig.xml: No such file or directory
solr_1 | sed: can’t read /ezsolr/server/ez/template/solrconfig.xml: No such file or directory
solr_1 | sed: can’t read /ezsolr/server/ez/template/solrconfig.xml: No such file or directory
solr_1 |
solr_1 | Solr home directory /ezsolr/server/ez not found!

I find it strange that it works for others and for solr no (right case)

Thank you


#2

I’ve experienced this. The core data files were being stored on the dev machines so my pull request to change that location was accepted. I’m trying to remember the details.

You mentioned platform.sh so you are going to run into some things with your project. First multi-core isn’t ready for ez+p.sh. I do have single core working. With your solr core settings you have to move them inside the .platform folder in the root of your project so instead of using the default ezlaunchpad docker-compose path you will have to modify that OR keep two copies of your solr core configs sync by some method. This is because platform.sh needs to know where your solr core config files live since p.sh rebuilds on each commit the first thing p.sh has is what’s inside the .platform folder. So that’s 100% what you will need to do. Also a note if you are an enterprise subscription any of these solr config changes HAVE to be submitted as a support ticket to p.sh for a p.sh engineer to handle the deployment. That hit us as a surprise that there are parts that need p.sh to handle. In my opinion that’s crazy to have to wait for a ticket to be completed but that’s the reality and I want you to know that up front because it took us by surprise.

Here is my .platform/services.yaml

solrsearch:
    type: solr:6.6
    disk: 1024
    configuration:
        # single core
        cores:
            main:
                conf_dir: !archive "solr/mycores/main/conf"
        endpoints:
            main:
                core: main

So essentially I stopped using the shared volume of /ezsolr/server/ez . I decided to embrace the original docker solr container and use the /opt/solr/server/solr for running my solr server. I think I even deleted the solr/entrypoint.bash file. You can manually get the ez solr core templates from that bundle so you can create your solr cores by hand.

Our Setup:

.platform
  solr
    mycores
      default
      eng_gb
      fre_fr
   solr.xml

my docker-compose.yml (provisioning/dev/docker-compose.yml)

solr:
        image: solr:6.6
        volumes:
            - '${PROJECTCOMPOSEPATH}/.platform/solr/mycores:/opt/solr/server/solr/mycores:rw'
            - '${PROJECTCOMPOSEPATH}/.platform/solr/solr.xml:/opt/solr/server/solr/solr.xml:rw'
        volumes_from:
            - 'engine:rw'
        depends_on:
            - engine
        environment:
            - SOLR_HOME=/opt/solr/server/solr
        ports:
            - '${PROJECTPORTPREFIX}983:8983'

The docker solr container being used is smart enough to detect any cores being in a shared volume and will auto-import them into solr. There are a ton of permission errors when it comes to docker so welcome to the docker permissions issue club.

The BIG issue was p.sh handled the location of the solr_home environment variable. You will need to update your solrconfig.xml file for each of your cores on line 101 to <dataDir>${solr.solr.home}/${solr.core.name}</dataDir> This will work for p.sh and local dev on docker. I still need to work with Sebastien to get all this implemented so it works automatically. We are telling each core to store it’s index data file to be kept out of the shared volume and only live inside the container. That should solve the permissions since solr is being run and the uid doesn’t match your dev user I’m assuming.

I ran into so many docker permissions issues not just for ezlaunchpad but personal projects. I have a nodejs project that is using something called fixuid. It’s kinda what Sebastien does in the entrypoint.bash files for making sure the uid’s match. Check out my provisioning stuff in this repo. https://github.com/raupie/nodejs-sandbox It could be nice to implement this package into ezlaunchpad someday.

Hope this helps. Sorry it’s lengthy!


#3

My hope is to have a pull request for refactoring the way ezlaunchpad deals with solr. I have a good start but ran into a few issues with trying to understand how ezlaunchpad works. I needed to add some steps in the init/create process and couldn’t figure out where to do that or what the best way is.


#4

Hi,

Thank you for your reply

I’m sorry for the delay.

It was just a personal project. I did not understand everything that had to be done. at the end I took the solr file of another project and paste it on instance then launch an ez create and it worked

By cons I think we must review the command ez init it never worked for me dice the first time.

Actually, on the project files I told you, they made the change in the solrconfig.xml file

Thank you for your repo :slight_smile:

Amine