Git Product home page Git Product logo

ansible-role-solr's Introduction

Ansible Role: Apache Solr

CI

Installs Apache Solr on Linux servers.

Requirements

Java must be available on the server. You can easily install Java using the geerlingguy.java role. Make sure the Java version installed meets the minimum requirements of Solr (e.g. Java 8 for Solr 6+).

This role is currently tested and working with Solr 3.x, 4.x, 5.x, 6.x, 7.x, and 8.x.

Role Variables

Available variables are listed below, along with default values (see defaults/main.yml):

solr_workspace: /root

Files will be downloaded to this path on the remote server before being moved into place.

solr_create_user: true
solr_user: solr
solr_group: "{{ solr_user }}"

Solr will be run under the solr_user. Set solr_create_user to false if solr_user is created before this role runs, or if you're using Solr 5+ and want Solr's own installation script to set up the user. By default, solr_group equals solr_user, but it can be overwritten to fit your own configuration.

solr_version: "8.11.2"

The Apache Solr version to install. For a full list, see available Apache Solr versions.

solr_mirror: "https://archive.apache.org/dist"

The Apache Project mirror from which the Solr tarball will be downloaded. In case of slow download speed or timeouts it is useful to set the mirror to the one suggested by Apache's mirror download site.

solr_remove_cruft: false

Whether to remove unneccessary documentation and examples from the solr directory.

solr_service_manage: true
solr_service_name: solr
solr_service_state: started

By default, this role will manage the solr service, ensuring it is enabled at system boot and is running. You can ensure Solr is stopped by setting solr_service_state: stopped, or you can disable this role's management of the solr service entirely by setting solr_service_manage: false. You may also want to set solr_restart_handler_enabled: false (documented later) in this case.

solr_install_dir: /opt
solr_install_path: /opt/solr

The path where Apache Solr will be installed. For Solr 5+, the solr_install_dir will be used by Solr's installation script. For Solr < 5, the Solr installation files will be copied in place in the solr_install_path.

solr_home: /var/solr

The path where local Solr data (search collections and configuration) will be stored. Should typically be outside of the solr_path, to make Solr upgrades easier.

solr_port: "8983"

The port on which Solr will run.

solr_xms: "256M"
solr_xmx: "512M"

Memory settings for the JVM. These should be set as high as you can allow for best performance and to reduce the chance of Solr restarting itself due to OOM situations.

solr_timezone: "UTC"

Default timezone of JVM running solr. You can override this if needed when using dataimport and delta imports (ex: comparing against a MySQL external data source). Read through Apache Solr's Working with Dates documentation for more background.

solr_opts: "$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"

Solr options. This option was added to the role in part to mitigate CVE-2021-44228.

solr_cores:
  - collection1

A list of cores / collections which should exist on the server. Each one will be created (if it doesn't exist already) using the default example configuration that ships with Solr. Note that this variable only applies when using Solr 5+.

solr_connect_host: localhost

The hostname or IP address on which Solr will be reachable. localhost should work in most circumstances, but there are special cases where you may only be able to access the local Solr instance via another IP or hostname.

solr_restart_handler_enabled: true

Whether the restart solr handler should be used or not. If you're building containers or AMIs, you might need to disable the restart handler for a provisioning run.

Variables used only for Solr < 5.

The following variables are currently only applied to installations of Solr 4 and below:

solr_log_file_path: /var/log/solr.log

Path where Solr log file will be created.

solr_host: "0.0.0.0"

The hostname or IP address to which Solr will bind. Defaults to 0.0.0.0 which allows Solr to listen on all interfaces.

Dependencies

None.

Example Playbook

- hosts: solr-servers
  roles:
    - geerlingguy.java
    - geerlingguy.solr

License

MIT / BSD

Author Information

This role was created in 2014 by Jeff Geerling, author of Ansible for DevOps.

ansible-role-solr's People

Contributors

allardhoeve avatar baschny avatar dale-c-anderson avatar diadzine avatar dkd-schmidt avatar fredleger avatar gadelkareem avatar gdelafond avatar geerlingguy avatar gremid avatar ixai avatar jonathonwalz avatar kekkis avatar longwave avatar lopf avatar mhitza avatar mroest avatar nemeth avatar raistlin avatar saily avatar sermo-de-arboribus avatar timohund avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ansible-role-solr's Issues

Create cores task fails

When trying to install solr through this role, it fails at the cores.yml task. When I remove this task from the role file (because I have no cores defined anyway, I want an empty solr install) it runs fine. My guess is that is somehow doesn't parse the response of the URL correctly to find the list of current cores (there are none in my case).

fatal: [cluster-worker000000]: FAILED! => {"failed": true, "msg": "The conditional check ''{{ item }}' not in '{{ solr_cores_current.content }}'' failed. The error was: Invalid conditional detected: EOL while scanning string literal (<unknown>, line 1)\n\nThe error appears to have been in '/home/rose/.ansible/roles/geerlingguy.solr/tasks/cores.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Ensure Solr conf directories exist.\n  ^ here\n"}
fatal: [cluster-worker000001]: FAILED! => {"failed": true, "msg": "The conditional check ''{{ item }}' not in '{{ solr_cores_current.content }}'' failed. The error was: Invalid conditional detected: EOL while scanning string literal (<unknown>, line 1)\n\nThe error appears to have been in '/home/rose/.ansible/roles/geerlingguy.solr/tasks/cores.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Ensure Solr conf directories exist.\n  ^ here\n"}```

Fix initial installation for Solr 4.x

Right now the initial install (at least via Travis CI) returns:

The command "grep -q 'changed=0.*failed=0'" exited with 0.
$ curl http://localhost:8080/solr/core0/admin/ping

<html><head><title>Apache Tomcat/6.0.35 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.35</h3></body></html>

With Solr 4.x, it requires the openjdk-7-jdk installed (rather than version 6). I'm testing an updated test.yml file...

Add ability to disable Solr service management or change service state

Right now the service management is hardcoded—when you run this role, the role presumes you will want to run solr under sysvinit or systemd, and further, that you want it started. I would like to add two variables:

  • solr_service_manage — defaults true, if false, the service task is skipped entirely.
  • solr_service_state — defaults started, but user can control whether solr is stopped if running, restarted, etc. as needed.

This is especially helpful from the perspective of making the role work inside containers, which may not even have an init system running.

Fix multi-core support and initial installation

Right now, even though tests are passing, the initial installation fails because the multicore configuration used by this role is a little brittle.

Though curl exits with a 0 status (I should really check the response headers and parse them in the test), it returns the Tomcat error page:

$ curl http://localhost:8080/solr/core0/admin/ping

<html><head><title>Apache Tomcat/6.0.35 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.35</h3></body></html>

Solr service not installing with solr version < 5

Hey,

My playbook:

---
- hosts: all
  become: yes
  roles:
    - { role: geerlingguy.java }
    - { role: geerlingguy.solr, solr_version: "4.10.4" }

Fails on this task:

TASK [geerlingguy.solr : Ensure solr is started and enabled on boot.] **********
fatal: [192.168.104.11]: FAILED! => {"changed": false, "failed": true, "msg": "Could not find the requested service \"'solr'\": "}

See full output here: http://pastebin.com/w3CSYCSa

I'm using your geerlingguy/ubuntu1604 vagrant box, ansible 2.2.0.0 and release 3.4.1 of this role.

I was able to work around the issue if I run this command in the vagrant machine:

sudo update-rc.d solr defaults

Any thoughts?

Ansible Container warning

I am getting a new warning when using this role in a build:

- downloading role 'solr', owned by geerlingguy
[WARNING]: geerlingguy.solr is a Container Enabled role and should only be installed using Ansible Container

Though looking at https://github.com/geerlingguy/solr-container it seems this role is meant to work both with Ansible Container and standalone, and this can be ignored, is that right? Is there a way to suppress this warning?

Add tests so all supported versions are tested (3.x, 4.x, 5.x, 6.x)

Currently only 3.x and 4.x are tested in Ubuntu 12.04.

First, I want to make sure 5.x is tested.

Then I want to test under RedHat + Ubuntu (at least the latest LTS releases of each) for at least 6.x and 5.x of Solr, and also run tests on 3.x/4.x on Ubuntu 14, maybe.

Download directory and temporary directory should be distinct

Imagine a scenario where you provide all binary archives and other external resources on a read-only NFS server, for example. In this scenario, you would like to read archives from NFS but expand their contents somewhere else.

In other words, create an additional {{ solr_downloads }} which is intended to keep the download binary. If it is already there, like in the example of a read-only NFS server, nothing needs to be downloaded.

solr_service_name not used in init script for debian

In the init script for debian the variable "provides" is hardcoded to "solr". When you want to spinup multible solr versions, the result is that you get an error when the secode service is registered.

It think

# Provides:             solr

should be

# Provides:             {{ solr_service_name }}

Because this variable is used when the service is registed in Ubuntu 16.04 as system service.

https://github.com/geerlingguy/ansible-role-solr/blob/master/templates/solr-init-Debian-pre5.j2#L12

Init script behaviour

Current service behaviour:

User start stop status restart
root OK OK OK OK
solr Error OK OK Error
other Error OK OK Error

Desired service behaviour:

User start stop status restart
root OK OK OK OK
solr OK OK OK OK
other Message Message OK Message

Suggestions:

  • allow solr user to start solr by removing "--user" option from daemon when current user equals solr user.
  • disallow stopping of solr by non-root, non-solr users.
  • provide "invalid" users with an informative message

Comments?

Unconditional include

when: solr_create_user

Even though the "when" is specified when Include: user.yml, the file gets included unconditionally and breaks the build in some cases.

"when" does not work with "include" statements and should be used in individual tasks instead.

Allow Solr memory settings to be configured (Solr 5+)

In Solr 4.x and below, the custom init script included with this role passes along java options like solr_xms and solr_xmx in the start command... in Solr 5.x+, the install script sets everything up for us, and uses an include file for extra settings (see: https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production#TakingSolrtoProduction-MemoryandGCSettings).

We could set the variable correctly like so, in that include file:

SOLR_JAVA_MEM="-Xms{{ solr_xms }} -Xmx{{ solr_xmx }}"

Solr 5.3.1, solr.in.sh doesn't exist (centos7)

See geerlingguy/drupal-vm#1028

TASK [geerlingguy.solr : Apply Solr memory configuration changes.] *************
failed: [drupalvm] (item={u'regexp': u'^.?SOLR_JAVA_MEM=', u'line': u'SOLR_JAVA_MEM="-Xms64M -Xmx128M"'}) => {"failed": true, "item": {"line": "SOLR_JAVA_MEM=\"-Xms64M -Xmx128M\"", "regexp": "^.?SOLR_JAVA_MEM="}, "msg": "Destination /etc/default/solr.in.sh does not exist !", "rc": 257}
failed: [drupalvm] (item={u'regexp': u'^SOLR_PORT=', u'line': u'SOLR_PORT="8983"'}) => {"failed": true, "item": {"line": "SOLR_PORT=\"8983\"", "regexp": "^SOLR_PORT="}, "msg": "Destination /etc/default/solr.in.sh does not exist !", "rc": 257}

Add 'remove cruft' option

It seems that Solr 5.x, at least, leaves a decent amount of cruft in the default install, e.g.:

90M	/opt/solr-6.4.0/docs
8.3M	/opt/solr-6.4.0/example

Those are easy wins if we can just drop them through the use of a variable like solr_remove_cruft.

I'll have to verify they're named similarly in older Solr releases (besides just 5.x and 6.x).

404 on solr UI

I took this for a spin, both with the solr box in your Ansible Vagrant Examples as well as in my own test ansible project. In both cases I get a 404 navigating to [host]:8080/solr, but as far as I can tell all the tasks ran successfully on provision. The 404 is provided by tomcat, so it looks like things are almost setup but not quite finishing. Not sure what else to provide on this since the provision seems successful, but if there's anything I can provide to help with this let me know.

Combine 'Download' and 'Expand' solr tasks using unarchive

Since 2.0 is pretty much everywhere, we can use unarchives ability to download and expand-into-place the Solr archive.

Currently, the download file sits on the system after the role is finished, but that's annoying... it's like 150MB! And it's causing downstream projects to also be larger than necessary. See, for example: https://github.com/geerlingguy/docker-image-solr/issues/5

Basically, with Ansible 2.x, we should be able to combine these two tasks:

- name: Download Solr.
  get_url:
    url: "{{ solr_mirror }}/lucene/solr/{{ solr_version }}/{{ solr_filename }}.tgz"
    dest: "{{ solr_workspace }}/{{ solr_filename }}.tgz"
    force: no

- name: Expand Solr.
  unarchive:
    src: "{{ solr_workspace }}/{{ solr_filename }}.tgz"
    dest: "{{ solr_workspace }}"
    creates: "{{ solr_workspace }}/{{ solr_filename }}/CHANGES.txt"
    copy: no

Also, related: #14

Service does not work on SOLR 4.x and Ubuntu 16.04

I am using this role as part of DrupalVM. I have set solr_version to 4.5.1.

SOLR installs correctly (at least as far as the Ansible tasks dictate), but the service never starts. However, when running the init.d version of the script, it works fine:

$ sudo /etc/init.d/solr start

I was wondering why it doesn't do the same thing when run as sudo service solr start. Then I realized that Ubuntu 16.04 uses systemd which does not use the init.d script. I saw the systemd version of the file and saw the problem.

ExecStart={{ solr_install_path }}/bin/solr -e cloud -noprompt

The {{ solr_install_path }}/bin directory on SOLR 4.5.1 is empty. To make sure that this is not a packaging problem, I even cross-checked it with SOLR 4.9.1 and it was still empty. I am assuming this is true for all 4.x releases. As a side note, the configure-solr.sh included in DrupalVM doesn't work for the same reason.

I see the above being changed in #56 but that has not been merged yet. I know there is a reason that is not merged yet and I want to bring this issue to your attention as well.

Question about solr core creation on <5

Just a quick question as I'm in the process of working out how to automate solr cores on installations using major versions 3-6.

The solr core creation script only came into place officially in version 5, what would be your recommended method of automation for versions 3 and 4?

I understand this has no real chance of becoming a part of the workflow of this role, but I believe the question is worth asking.

Support Apache Solr 5.x

5.x is another large change to the entire Solr deployment/configuration process, as it no longer supports other Java servlet containers out of the box, and relies instead on built-in tooling.

The recommended setup uses a shell script with command line flags, but we can do better than that (what is this, 1999? Who logs into servers anymore?).

See:

I did a lot of the ground work in #8, but there are still some things that need to be changed to get 5.x deployed and configured correctly out of the box. So far, since none of the projects I'm working on even have rudimentary support for 5.x (they're all only recently updated for later versions of 4.x!), this isn't a pressing issue. But I would like to be able to get the role to support at least 4.x and 5.x, if not 3/4/5.

Solr package name has been changed starting with version 4.1.0

Hi Jeff,

thank you for the role, it works fine for the default version 3.6.2. Starting with 4.1.0 Solr package name has been changed from "apache-solr-..." to just "solr..." (http://archive.apache.org/dist/lucene/solr/4.1.0/), which cause following error, when I try to change version to 4.8.0:

ASK: [geerlingguy.solr | Download Solr.] *************************************
failed: [default] => {"dest": "/root/apache-solr-4.8.0.tgz", "failed": true, "item": "", "response": "HTTP Error 404: Not Found", "state": "absent", "status_code": 404, "url": "http://archive.apache.org/dist/lucene/solr/4.8.0/apache-solr-4.8.0.tgz"}
msg: Request failed

Thanks in advance.

Fix restart handler for misbehaving daemonization on Debian/Ubuntu

Using Ubuntu's init script, which uses daemon from libslack to daemonize Solr, the service solr stop command returns immediately, even though solr hasn't yet shut down. Then Ansible runs service solr start immediately after, reports success on a restart, and the playbook completes.

However, this results in solr being stopped instead, which is not desirable.

I really would like to find a simple way to daemonize solr with a better and cross-platform init script, but at this point, I'll be happy just adding a sleep parameter to the restart solr handler.

Complete rewrite for modern Solr installation

Solr has improved quite a bit since the initial version of this role was written (for early 3.x versions of Solr). In Solr 4.x and now 5.0.0 (just released), it's preferred to use the included Jetty-based servlet, which is simpler to install and configure than Tomcat.

Plus, I only have a crufty old 'tomcat6' role to use, and don't have any other projects where I use Tomcat anymore, so there's no real reason for me to create or update tomcat roles. And since Jetty's preferred anyways, and should have comparable performance nowadays... no reason not to use Jetty :)

So I'm going to completely rewrite the role, and still hopefully be able to support any version of Solr from 3.x to 5.x, installed with Java 7+. I can also drop the dependency on geerlingguy.tomcat6, and just have no dependencies (people can install Java however they please... though the geerlingguy.java role makes this simple as well).

httplib2 error in release 3.1.0 on provisioning

Hi there,

I updated my solr role to the newest release, 3.1.0 and when provisioning I encountered this error:

Alt text

Once I downgraded to 3.0.0 provisioning works again.

Sorry that I don't have any more detailed info right now, please ask if you want to know something specific about my setup.

ansible-role-solr/tasks/cores.yml cannot be run with --check

In --check mode the task Check current list of Solr cores. is skipped thus solr_cores_current is never populated. This means that the subsequent Ensure Solr conf directories exist. fails with:

FAILED! => {"failed": true, "msg": "The conditional check 'item not in solr_cores_current.content' failed. The error was: error while evaluating conditional (item not in solr_cores_current.content): Unable to look up a name or access an attribute in template string ({% if item not in solr_cores_current.content %} True {% else %} False {% endif %}).\nMake sure your variable name does not contain invalid characters like '-': argument of type 'StrictUndefined' is not iterable

Pre5 solr on Centos7 restart problem

I'm having an issue with restarting solr 4.10 on Centos 7. Calling restart via the handler causes solr to stop, but it does not restart.

I've already hit an issue with solr not starting due to the daemon needing to be reloaded, so I've copied the 5+ logic into the pre5-install.yml tasks but I'm really having trouble sussing out why the restart command is not working.

If I run the commands at the command line, I see a similar issue. If I have a running solr and issue systemctl restart solr, the solr process stops (the log ends with org.eclipse.jetty.util.thread.ShutdownThread – shutdown already commenced , but is not restarted.

If I then issue a systemctl status solr it outputs:

● solr.service - SYSV: Controls an Apache Solr process.
   Loaded: loaded (/etc/rc.d/init.d/solr)
   Active: active (exited) since Thu 2016-12-15 19:48:37 UTC; 2min 35s ago
     Docs: man:systemd-sysv-generator(8)

Dec 15 19:48:37 dangerzone.mydomain systemd[1]: Starting SYSV: Controls an Apache Solr process....
Dec 15 19:48:37 dangerzone.mydomain solr[12063]: Starting solr... already started... done.
Dec 15 19:48:37 dangerzone.mydomain systemd[1]: Started SYSV: Controls an Apache Solr process..

Any thoughts? Happy to test things and submit a PR if you can point me in the right direction.

Does not work with systemd

Thank you for this role! I tested out using this role with Debian wheezy but it looks like that is unsupported?

TASK: [geerlingguy.solr | Ensure solr is started and enabled on boot.] ******** 
failed: [33.33.33.24] => {"failed": true}
msg: update-rc.d: error: solr Default-Start contains no runlevels, aborting.
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.5 (wheezy)
Release:    7.5
Codename:   wheezy

Solr version < 5 doesn't read solr cores from the correct path

When installing Solr version 4.10.4 with the latest release of this role, Solr doesn't read the solr cores from the correct path, which would be {{ solr_home }} (defaults to /var/solr).

Rather the cores are read from /opt/solr/node1/solr, that is from the solr install path. See screenshot from the solr admin tool:
Alt text

I'm using geerlingguy/ubuntu1604 vagrant box, ansible 2.2.0.0 and release 3.4.2 of this role.

My playbook is

---
- hosts: all
  sudo: yes
  vars:
    solr_version: "4.10.4"
    solr_cores:
      - common
  roles:
    - geerlingguy.java
    - geerlingguy.solr
  post_tasks:
    - name: Remove default core
      file:
        path: "{{ solr_home }}/collection1"
        state: absent
      when: solr_cores is defined

    - name: Create solr core paths
      file:
        path: "{{ solr_home }}/{{ item }}"
        state: directory
        owner: "{{ solr_user }}"
        group: "{{ solr_user }}"
      with_items: "{{ solr_cores }}"
      when: solr_cores is defined

    - name: Copy solr core configs
      copy:
        src: "solr-cores/{{ item }}/"
        dest: "{{ solr_home }}/{{ item }}"
        owner: "{{ solr_user }}"
        group: "{{ solr_user }}"
      with_items: "{{ solr_cores }}"
      notify: restart solr
      when: solr_cores is defined

The core I'm using looks like this
Alt text

core.properties:

name=common

The conf dir is identical to the one from Drupal's search_api_solr module, http://cgit.drupalcode.org/search_api_solr/tree/solr-conf/4.x

Initial provision failed to create temporary content file: timed out

I'm running into this error on my clean copy of drupal-vm:

TASK [geerlingguy.solr : Download Solr.] ***************************************
fatal: [collegescorecard]: FAILED! => {"changed": false, "failed": true, "msg": "failed to create temporary content file: timed out"}

I tried running vagrant provision again a few times but appear to be getting the same error.

My config.yml isn't too far from the example config, other than uncommenting solr from installed_extras, using Drupal 7 and not installing the site or running the make file on provision.

Systemd status incorrect on RHEL/CentOS 7, causing fail

In Drupal VM (see geerlingguy/drupal-vm#789), some have noticed that the combo of this role and CentOS 7 results in the following fail:

TASK [geerlingguy.solr : Ensure solr is started and enabled on boot.] **********
fatal: [drupalvm]: FAILED! => {"changed": false, "failed": true, "msg": "Job for solr.service failed because the control process exited with error code. See \"systemctl status solr.service\" and \"journalctl -xe\" for details.\n"}

It looks like the systemctl config for Solr (at least 5.x) might not be configured correctly... going to look into this.

Init script wrong user

I have a strange problem, after installing this role on a Debian Jessie, daemon is started with user 'root', and error org.apache.solr.common.SolrException: java.io.FileNotFoundException: /var/solr/collection1/data/tlog/tlog.0000000000000000000 is displayed at log console on Solr admin. I need to manually stop daemon and run su -c "/etc/init.d/solr start solr" solr to run daemon with solr user at least once. And only then data directory is created and initializated.

I expected process owner to be solr always, even when we run service solr start as root.

'Create configured cores' task is too fragile

I'm getting inconsistent results when using this role (3.4.1) with Debian Jessie.

On the first run I'll get:

TASK [geerlingguy.solr : Create configured cores.] *****************************
changed: [203.0.113.13] => (item=collection1)

TASK [geerlingguy.solr : debug] ************************************************
ok: [203.0.113.13] => {
    "msg": {
        "changed": true, 
        "msg": "All items completed", 
        "results": [
            {
                "_ansible_item_result": true, 
                "_ansible_no_log": false, 
                "_ansible_parsed": true, 
                "changed": true, 
                "cmd": "/opt/solr/bin/solr create -c collection1", 
                "delta": "0:00:02.713352", 
                "end": "2017-01-16 17:13:00.886274", 
                "invocation": {
                    "module_args": {
                        "_raw_params": "/opt/solr/bin/solr create -c collection1", 
                        "_uses_shell": true, 
                        "chdir": null, 
                        "creates": null, 
                        "executable": null, 
                        "removes": null, 
                        "warn": true
                    }, 
                    "module_name": "command"
                }, 
                "item": "collection1", 
                "rc": 0, 
                "start": "2017-01-16 17:12:58.172922", 
                "stderr": "", 
                "stdout": "\nCreating new core 'collection1' using command:\nhttp://localhost:8983/solr/admin/cores?action=CREATE&name=collection1&instanceDir=collection1\n\n{\n  \"responseHeader\":{\n    \"status\":0,\n    \"QTime\":2154},\n  \"core\":\"collection1\"}", 
                "stdout_lines": [
                    "", 
                    "Creating new core 'collection1' using command:", 
                    "http://localhost:8983/solr/admin/cores?action=CREATE&name=collection1&instanceDir=collection1", 
                    "", 
                    "{", 
                    "  \"responseHeader\":{", 
                    "    \"status\":0,", 
                    "    \"QTime\":2154},", 
                    "  \"core\":\"collection1\"}"
                ], 
                "warnings": []
            }
        ]
    }
}

Which is expected, since the Solr core doesn't exist yet.

What's more surprising is on subsequent runs I'll get:

TASK [geerlingguy.solr : Create configured cores.] *****************************
...ignoring
failed: [203.0.113.13] (item=collection1) => {"changed": true, "cmd": "/opt/solr/bin/solr create -c collection1", "delta": "0:00:00.681810", "end": "2017-01-16 17:13:41.423812", "failed": true, "item": "collection1", "rc": 1, "start": "2017-01-16 17:13:40.742002", "stderr": "\nERROR: \nCore 'collection1' already exists!\nChecked core existence using Core API command:\nhttp://localhost:8983/solr/admin/cores?action=STATUS&core=collection1", "stdout": "", "stdout_lines": [], "warnings": []}

TASK [geerlingguy.solr : debug] ************************************************
ok: [203.0.113.13] => {
    "msg": {
        "changed": true, 
        "failed": true, 
        "msg": "One or more items failed", 
        "results": [
            {
                "_ansible_item_result": true, 
                "_ansible_no_log": false, 
                "_ansible_parsed": true, 
                "changed": true, 
                "cmd": "/opt/solr/bin/solr create -c collection1", 
                "delta": "0:00:00.681810", 
                "end": "2017-01-16 17:13:41.423812", 
                "failed": true, 
                "invocation": {
                    "module_args": {
                        "_raw_params": "/opt/solr/bin/solr create -c collection1", 
                        "_uses_shell": true, 
                        "chdir": null, 
                        "creates": null, 
                        "executable": null, 
                        "removes": null, 
                        "warn": true
                    }, 
                    "module_name": "command"
                }, 
                "item": "collection1", 
                "rc": 1, 
                "start": "2017-01-16 17:13:40.742002", 
                "stderr": "\nERROR: \nCore 'collection1' already exists!\nChecked core existence using Core API command:\nhttp://localhost:8983/solr/admin/cores?action=STATUS&core=collection1", 
                "stdout": "", 
                "stdout_lines": [], 
                "warnings": []
            }
        ]
    }
}

The error Core 'collection1' already exists! shouldn't be happening in the first place because we should have been able to test that the default Solr core already exists.

I've been thinking about simply checking that collection1 exists but that wouldn't be that simple because, as I understand, solr_cores is an array of cores that we should potentially be ready to check for should they have been defined.

Is it me doing something foolish or could we possibly improve the conditions such as we're making this task more solid?

Install issue on CentOS 6

On a pre-Solr 5 install on CentOS 6 I am getting an error, because systemd is not installed:

TASK [geerlingguy.solr : Copy solr systemd unit file into place (for systemd systems).] ***
fatal: [127.0.0.1]: FAILED! => {"changed": true, "failed": true, "msg": "Destination directory /etc/systemd/system does not exist"}

I don't immediately see why this is happening because the when clause should be skipping this step:

$ ansible -ilocalhost, all --connection local -m setup -a 'filter=ansible_distribution*'
localhost | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "CentOS", 
        "ansible_distribution_major_version": "6", 
        "ansible_distribution_release": "Final", 
        "ansible_distribution_version": "6.9"
    }, 
    "changed": false
}

Would it be simpler to check for the existence of the directory and put the unit file into place only if it exists?

Using the new solr.xml format

The new solr.xml format (https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml) makes it a lot easier to auto-discover cores and removes the need for hardcoding the 2 cords that are currently mentioned in this role. We will still need a default core, but the configuration is much simplified as per the above example.

I was able to modify your role using the above to get this to work, the only quirk being that solrconfig.xml has relative paths to some of the jars in the "contrib" and "dist" folder which I had to fix manually (but can be done through the role itself). This wasnt a problem in the way the role is currently available but inside example/multicore/core0/conf/solrconfig.xml is this statement

<!--
 This is a stripped down config file used for a simple example...
 It is *not* a good example to work from.
-->

Instead using the example/solr/collection1/conf/solrconfig.xml has a more complete configuration file, but has the reference issue that I mentioned above.

I can provide a PR if thats okay with you, quite new to ansible roles, so might need some work before I send it out to you.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.