Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade version #117

Closed
edouardkleinhans opened this issue Sep 7, 2020 · 7 comments
Closed

Upgrade version #117

edouardkleinhans opened this issue Sep 7, 2020 · 7 comments
Labels

Comments

@edouardkleinhans
Copy link

Hello,

I've deployed solr 8.5.2 and I want to upgrade it to 8.6.X and the script don't let me do that.

Is it possible to force an upgrade ?

Regards,

Edouard

@p0ntsNL
Copy link

p0ntsNL commented Sep 11, 2020

Looking forward to this as well.

@p0ntsNL
Copy link

p0ntsNL commented Sep 11, 2020

So I have just tested this, you can remove the following files to force re-installation while the platform stays online (at least on my side)

  • symlink under solr_install_path
  • /etc/init.d/solr (otherwise "Run Solr installation script" fails)

Then re-run ansible to make it install the newest version and re-create the symlink for you after installation.

@stale
Copy link

stale bot commented Dec 10, 2020

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

@stale stale bot added the stale label Dec 10, 2020
@stale
Copy link

stale bot commented Jan 9, 2021

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

@michaellenahan
Copy link

michaellenahan commented Jan 12, 2022

In order to update to the latest version 8.11.1 ...

I took these steps on my solr server before running the playbook:

  • remove the /opt/solr symlink
    rm /opt/solr

  • rename /etc/init.d/solr
    mv /etc/init.d/solr /etc/init.d/solr-backup

  • copy /etc/default/solr.in.sh (to create a backup)
    cp /etc/default/solr.in.sh /etc/default/solr.in.sh.solr-backup

  • rename /var/solr/data/solr.xml
    mv /var/solr/data/solr.xml /var/solr/data/solr.xml.solr-backup

  • rename /var/solr/log4j2.xml ...
    mv /var/solr/log4j2.xml /var/solr/log4j2.xml.solr-backup

After this my playbook ran through to the end, and it updated solr, in my case no solr downtime was experienced.

@michaellenahan
Copy link

michaellenahan commented Jan 13, 2022

Note that running the current playbook installs Solr 8.11.1, this contains the now outdated log4j 2.16.0

Note that the solr team still considers log4j 2.16.0 to be not causing a security issue within solr (of course in other contexts it is a security issue):
https://solr.apache.org/security.html
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools

To play it safe, it is possible to swap out the log4j *.jar files to the latest version (at time of writing, 2.17.1).

We did this without any noticed bad effects (YMMV):

download and extract https://dlcdn.apache.org/logging/log4j/2.17.1/apache-log4j-2.17.1-bin.tar.gz

replace the *.jar files in:
/opt/solr/server/lib/ext/
... with the 2.17.1 versions from the download

@geerlingguy
Copy link
Owner

@michaellenahan - Yeah, since it seems the Solr usage isn't affected, I'm okay with just keeping 2.16.0 running on my servers for now. I'm still following the discussion around Log4J and will update the role's defaults quickly again if I see any further developments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants