Re: "this.authenticationStore" is null after 9.7.0 Update

[Patrik Peng]

Hi Jason

I can confirm the workaround seems to work.



unexpected docvalues type NONE for field '_version_' (expected=NUMERIC)

So, all good from our side.

Regards,
Patrik


On 28.10.2024 17:18, Jason Gerlowski wrote:

In our case, some new errors showed up, but which are related to the docvalues changes and need to be fixed on our end:

Hi all,

I found a workaround which you guys might be able to make use of.  In
short - SolrCloud users should be able to avoid the problem by
removing the "SOLR_AUTH_TYPE" envvar and
"solr.httpclient.builder.factory" sysprop from their configuration.
(Note that the 'bin/solr auth" tool appends the "SOLR_AUTH_TYPE"
setting to the end of Solr's "solr.in.sh" include file.  Check there
first if you're not sure where this setting is coming from.). If
anyone tries this out, please report back with your results!

Additionally, we've got a fix that's going through review upstream.
Will share here if there's any update on what release(s) that'll be
going into.

Best,

Jason

On Fri, Oct 25, 2024 at 10:34 AM Jason Gerlowski<gerlowsk...@gmail.com> wrote:

Hi guys,

Thanks for the info!  I managed to reproduce this locally and created
a JIRA ticket to investigate and release a fix:
https://issues.apache.org/jira/browse/SOLR-17515

To me at least it looks like a pretty serious bug, and might end up
resulting in a 9.7.1 release if other folks agree (and we can find a
volunteer to do the release).  But I'll poke around a bit to see if we
can't figure out a workaround for everyone in the meantime, and let
you guys know if I find anything!

Best,

Jason

On Fri, Oct 25, 2024 at 5:01 AM Patrik Peng
<patrik.p...@hostpoint.ch.invalid> wrote:

Hi Jason

Thanks for looking into this.

- what authc/authz plugins are enabled on your cluster?  If basicAuth
is in use (as the stack suggests), is "forwardCredentials" setup?

We have BasicAuth and RuleBasedAuthorization in use with blockUnknown enabled 
and forwardCredentials disabled.

- is SSL/TLS enabled on these clusters?  If so, can you share the
controlling sysprops?

TLS is enabled with the following properties:

     -Dsolr.keyStoreReload.enabled=true
     -Dsolr.jetty.keystore=/var/solr/keystore.p12
     -Dsolr.jetty.truststore=/var/solr/truststore.p12
     -Djavax.net.ssl.keyStore=/var/solr/keystore.p12
     -Dsolr.ssl.checkPeerName=true
     -Dsolr.jetty.ssl.sniHostCheck=true
     -Djavax.net.ssl.trustStore=/var/solr/truststore.p12
     -Dsolr.jetty.https.port=8983
     
-Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory
     -Dbasicauth=--REDACTED--
     -Djava.security.auth.login.config=/var/solr/jaas_client.conf
     -Dsolr.jetty.ssl.sniHostCheck=false
     -DzkACLProvider=org.apache.solr.common.cloud.SaslZkACLProvider
     
-DzkCredentialsProvider=org.apache.solr.common.cloud.DigestZkCredentialsProvider
     
-DzkCredentialsInjector=org.apache.solr.common.cloud.VMParamsZkCredentialsInjector

Checking these properties, I realized "solr.jetty.ssl.sniHostCheck" being there 
twice with differing values.
This has been fixed but the issue persists.

- have you made any customizations to Jetty HttpClient creation? (Solr
exposes sysprop-based hooks for influencing HttpClient settings)

None that I'm aware of.


Regards,
Patrik

OpenPGP_signature.asc
Description: OpenPGP digital signature