Re: Solr Upgrade

[Jan Høydahl]

Just retain your SOLR_HOME folder with all your data and point your new install 
to the same. If SolrCloud, point to the same Zookeeper.

Assuming you installed a standalone single node Solr with the Linux 
installation script, then your solr unpack wil be in /opt/solr-8.11.1, with a 
symbolic link from /opt/solr, and your data will be at /var/solr/data.

You can then run the installation script for 8.11.2 with the -f option, which 
will install 8.11.2 in /opt/solr-8.11.2 and change the symbolic link to point 
to the new install. Your data will be left unchanged, and a stop/start is all 
you need.

Detailed instructions in for the install script in 
https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#service-installation-script
 

 and for the upgrade process in 
https://solr.apache.org/guide/solr/latest/deployment-guide/upgrading-a-solr-cluster.html
 

 

If you have installed in some other way, follow the same principle of retaining 
your SOLR_HOME. If you have a Cloud cluster, upgrade one node at a time.

Jan

> 11. aug. 2022 kl. 07:57 skrev HariBabu kuruva :
> 
> Hi All,
> 
> I would like to upgrade Solr from 8.11.1 to 8.11.2.
> 
> Please help me with the steps I should follow so that the existing solr
> data is not affected. Thanks.
> 
> -- 
> 
> Thanks and Regards,
> Hari
> Mobile:9790756568

Re: Haystack EU the search relevance conference, 27th Sept, Berlin - CFP is open!

[Charlie Hull]

Hi all,

Quick reminder that our CFP closes this coming Monday 15th - please 
consider submitted a talk! 
https://opensourceconnections.com/haystack-eu-2022-the-call-for-presentations-is-open/


Tickets are also now on sale at www.haystackconf.com with hotel options 
from 158 Euros/night and a special return train ticket deal from 
anywhere in Germany for 49.50 Euro. There's also several other search 
events happening that week in Berlin.


Best

Charlie

On 14/07/2022 15:13, Charlie Hull wrote:


Hi all,

Haystack  is the conference for improving 
search relevance. If you're like us, you work to understand the shiny 
new tools or dense academic papers out there that promise the moon. 
Then you puzzle how to apply those insights to your search problem, in 
your search stack. But the path isn't always easy, and the promised 
gains don't always materialize.


Haystack is the conference for organizations where search, matching, 
and relevance really matters to the bottom line. For search managers, 
developers, relevance engineers & data scientists finding ways to 
innovate, see past the silver bullets, and share what actually has 
worked well for their unique problems. Please come share and learn!


Our CFP for Haystack EU 2022 to be held in Berlin on September 27th is 
open here 
. 
Find out what makes a great Haystack talk 
 
– we are looking for talks of 30-40 minutes. Curious what a Haystack 
talk looks like? Explore past Haystack Events 
 or check out past Haystack LIVE! 
talks in our Youtube channel 
.


Best

Charlie

--
Charlie Hull - Managing Consultant at OpenSource Connections Limited
Founding member of The Search Network 
 and co-author of Searching the 
Enterprise 


tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828

OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin
Amtsgericht Charlottenburg | HRB 230712 B
Geschäftsführer: John M. Woodell | David E. Pugh
Finanzamt: Berlin Finanzamt für Körperschaften II

--
Charlie Hull - Managing Consultant at OpenSource Connections Limited
Founding member of The Search Network  
and co-author of Searching the Enterprise 


tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828

OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin
Amtsgericht Charlottenburg | HRB 230712 B
Geschäftsführer: John M. Woodell | David E. Pugh
Finanzamt: Berlin Finanzamt für Körperschaften II

sorl version 6.3 - log4j question

[Ardian Krivca]

Hi,

I have a support question and was wondering if you can please help me.

I have Sorl version 6.3, I am trying to understand if I am vulnerable to the 
log4j issue.  Solr(tm) Security News - Apache 
Solr
 I looked on your site and it says "Description: Apache Solr releases prior to 
8.11.1 were using a bundled version of the Apache Log4J library vulnerable to 
RCE. For full impact and additional detail consult the Log4J security page.
Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 through 7.3) 
use Log4J 1.2.17 which may be vulnerable for installations using non-default 
logging configurations that include the JMS Appender,".

Can you please help me understand this. This means I am NOT vulnerable to the 
log4j issue? What does this mean exactly? "which may be vulnerable for 
installations using non-default logging configurations that include the JMS 
Appender?

Thank you

[cid:image001.png@01D8ACDA.A6AEA120]

Re: sorl version 6.3 - log4j question

[Gus Heck]

Hi Ardian,

You will want to review the various CVE's related to log4j1.2.17 to
evaluate your risk level. The log4j2 vulnerabilities (i.e. log4shell) are
not relevant to 6.3. There are several 1.2 vulnerabilities, but most of
them are only activated by the use of some less common logging
configurations, or certain tools that were distributed with Log4J 1.2. If
you do not use the affected tools, and do not use the appenders
(JMSAppender being one) in your configurations, then if you have good
controls over the configuration of your logging (so that nobody untrusted
or unaware of the danger might add affected appenders), you should be safe
from most of those CVE's. A good starting point is the list on the log4j
1.2 site:

https://logging.apache.org/log4j/1.2/

Log4j 1.2 is end of life and unmaintained, so you should not expect fixes
for these issues from the log4j team.

>From a security perspective, the "easy" way to be sure of the best possible
security is to upgrade to the latest Solr, but that's unlikely to be "easy"
from any other perspective. Next best is to use the Log4j 1.2->2.0 bridge
library (https://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html)
to allow your old (also end of life) solr version to use new Log4j logging
classes. It is important to use log4j 2.18.0 not 2.17.2 for best results if
you go that route, since the increased use of the bridge after this crisis
seems to have led to several fixes/enhancements in 2.18.0. Be aware however
that you should test carefully after applying the bridge. I've seen it
succeed with 6.4, but I can't be 100% sure it also works well with 6.3.

-Gus

On Thu, Aug 11, 2022 at 1:01 PM Ardian Krivca
 wrote:

> Hi,
>
>
>
> I have a support question and was wondering if you can please help me.
>
>
>
> I have Sorl version 6.3, I am trying to understand if I am vulnerable to
> the log4j issue.  Solr™ Security News - Apache Solr
> 
> I looked on your site and it says “*Description: Apache Solr releases
> prior to 8.11.1 were using a bundled version of the Apache Log4J library
> vulnerable to RCE. For full impact and additional detail consult the Log4J
> security page.*
>
> *Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7
> through 7.3) use Log4J 1.2.17 which may be vulnerable for installations
> using non-default logging configurations that include the JMS Appender,*”.
>
>
>
> Can you please help me understand this. This means I am NOT vulnerable to
> the log4j issue? What does this mean exactly? “*which may be vulnerable
> for installations using non-default logging configurations that include the
> JMS Appender?*
>
>
>
> Thank you
>
>
>
>
>


-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Solr Upgrade

[HariBabu kuruva]

Hi Jai dutt,

Thanks for your reply.

The main reason I am thinking of the upgrade is that : I have recently
upgraded ZK to 3.7.1 after which in the Solr console,
I see the  error: "Java Socket Exception " when I click the ZK status page.
So to address this issue  I came to know that we have to upgrade Solr to
8.11.2.

Please give your suggestions/inputs on this.




On Thu, Aug 11, 2022 at 12:15 PM jai dutt 
wrote:

> Just download new version and consider all customisation you did in your
> current version and do same in upgraded version. As 8.11.2 is just a
> minor change so I would suggest you to ignore this upgrade.
>
> On Thu, 11 Aug 2022 at 11:26 AM, HariBabu kuruva <
> hari2708.kur...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > I would like to upgrade Solr from 8.11.1 to 8.11.2.
> >
> > Please help me with the steps I should follow so that the existing solr
> > data is not affected. Thanks.
> >
> > --
> >
> > Thanks and Regards,
> >  Hari
> > Mobile:9790756568
> >
>


-- 

Thanks and Regards,
 Hari
Mobile:9790756568

RE: [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7

[kittichan Khankid]

On 2011/07/28 23:13:36 Uwe Schindler wrote:
> Hello Apache Lucene & Apache Solr users,
> Hello users of other Java-based Apache projects,
>
> Oracle released Java 7 today. Unfortunately it contains hotspot compiler
> optimizations, which miscompile some loops. This can affect code of
several
> Apache projects. Sometimes JVMs only crash, but in several cases, results
> calculated can be incorrect, leading to bugs in applications (see Hotspot
> bugs 7070134 [1], 7044738 [2], 7068051 [3]).
>
> Apache Lucene Core and Apache Solr are two Apache projects, which are
> affected by these bugs, namely all versions released until today. Solr
users
> with the default configuration will have Java crashing with SIGSEGV as
soon
> as they start to index documents, as one affected part is the well-known
> Porter stemmer (see LUCENE-3335 [4]). Other loops in Lucene may be
> miscompiled, too, leading to index corruption (especially on Lucene trunk
> with pulsing codec; other loops may be affected, too - LUCENE-3346 [5]).
>
> These problems were detected only 5 days before the official Java 7
release,
> so Oracle had no time to fix those bugs, affecting also many more
> applications. In response to our questions, they proposed to include the
> fixes into service release u2 (eventually into service release u1, see
[6]).
> This means you cannot use Apache Lucene/Solr with Java 7 releases before
> Update 2! If you do, please don't open bug reports, it is not the
> committers' fault! At least disable loop optimizations using the
> -XX:-UseLoopPredicate JVM option to not risk index corruptions.
>
> Please note: Also Java 6 users are affected, if they use one of those JVM
> options, which are not enabled by default: -XX:+OptimizeStringConcat or
> -XX:+AggressiveOpts
>
> It is strongly recommended not to use any hotspot optimization switches in
> any Java version without extensive testing!
>
> In case you upgrade to Java 7, remember that you may have to reindex, as
the
> unicode version shipped with Java 7 changed and tokenization behaves
> differently (e.g. lowercasing). For more information, read
> JRE_VERSION_MIGRATION.txt in your distribution package!
>
> On behalf of the Lucene project,
> Uwe
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134
> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738
> [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068051
> [4] https://issues.apache.org/jira/browse/LUCENE-3335
> [5] https://issues.apache.org/jira/browse/LUCENE-3346
> [6] http://s.apache.org/StQ
>
> -
> Uwe Schindler
> uschind...@apache.org
> Apache Lucene PMC Member / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>