I’ve discovered the authorization works properly if I use the FQDN to access
the Solr node, but the short hostname completely circumvents it.
They are all internal server clusters, so I’m using self-signed certificates
[the same exact certificate] on each. The SAN portion of the cert contains the
IP, short, and FQDN of each server.
I also diff’d the two servers Solr installation directories, and confirmed they
are identical.
They are using the same exact versions of Java and zookeeper, with the same
chroot configuration. [different zk clusters]
Jeremy Branham
jb...@allstate.com
On 3/14/19, 10:44 AM, "Branham, Jeremy (Experis)" <jb...@allstate.com> wrote:
I’m using Basic Auth on 3 different clusters.
On 2 of the clusters, authorization works fine. A 401 is returned when I
try to access the core/collection apis.
On the 3rd cluster I can see the authorization failed, but the api results
are still returned.
Solr.log
2019-03-14 09:25:47.680 INFO (qtp1546693040-152) [ ]
o.a.s.s.RuleBasedAuthorizationPlugin request has come without principal. failed
permission {
"name":"core-admin-read",
"role":"*"}
I’m using different zookeeper clusters for each solr cluster, but using the
same security.json contents.
I’ve tried refreshing the ZK node, and bringing the whole Solr cluster down
and back up.
Is there some sort of caching that could be happening?
I wrote an installation script that I’ve used to setup each cluster, so I’m
thinking I’ll wipe it out and re-run.
But before I do this, I thought I’d ask the community for input. Maybe a
bug?
Jeremy Branham
jb...@allstate.com<mailto:jb...@allstate.com>
Allstate Insurance Company | UCV Technology Services | Information Services
Group
