lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oakley, Craig (NIH/NLM/NCBI) [C]" <>
Subject RE: Re:Re: Implementing security.json is breaking ADDREPLICA
Date Thu, 19 Nov 2015 16:23:06 GMT
Thank you for the reply.

What we are attempting is to require a password for practically everything, so that even were
a hacker to get within the firewall, they would have limited access to the various services
(the Security team even complained that, for Solr 4.5 servers, attempts to access host:port
(without "/solr") resulted in an error message that gave the full pathname to solr.war)

I am sending the solr.log files directly to Anshum, so as not to clutter up the Email list.

The steps I used to recreate the problem are as follows:
cd zookeeper-3.4.6/conf/
sed 's/2181/4545/' zoo_sample.cfg | tee zoo_sample4545.cfg 
cd ../bin
./ start zoo_sample4545.cfg
cd ../../solr-5.3.1/server/solr
mkdir xmpl
echo 'name=xmpl' | tee xmpl/
mkdir xmpl/data
mkdir xmpl/data/index
mkdir xmpl/data/tlog
cd ../scripts/cloud-scripts/
./ --zkhost localhost:4545 -cmd makepath /solr
./ --zkhost localhost:4545 -cmd makepath /solr/xmpl
./ --zkhost localhost:4545/solr/xmpl  -cmd upconfig -confdir ../../solr/configsets/basic_configs/conf
-confname xmpl
mkdir ../../example/solr
cp solr.xml ../../example/solr
./ --zkhost localhost:4545/solr/xmpl  -cmd putfile /security.json ~/solr/security151117a.json

cd ../../../bin
mkdir  ../example/solr/pid
./solr -c -p 4575 -d ~dbman/solr/straight531outofbox/solr-5.3.1/server/ -z localhost:4545/solr/xmpl
-s ~dbman/solr/straight531outofbox/solr-5.3.1/example/solr
./solr -c -p 4565 -d ~dbman/solr/straight531outofbox/solr-5.3.1/server/ -z localhost:4545/solr/xmpl
-s ~dbman/solr/straight531outofbox/solr-5.3.1/server/solr
curl -u solr:SolrRocks 'http:// {IP-address-redacted}:4575/solr/admin/collections?action=ADDREPLICA&collection=xmpl&shard=shard1&node={IP-address-redacted}:4575_solr&wt=json&indent=true'

The contents of security151117a.json is included in the original post

If there is a better way using the Well Known Permissions as described at,
I'm open to trying that.

I would like to acknowledge that there definitely seem to be some IMPROVEMENTS in the security.json
implementation: particularly in terms of Core Admin (using jetty-implemented Authentication
in webdefault.xml, anyone who could get into the GUI front page could rename cores, unless
prevented by OS-level permissions on

Thanks again

View raw message