Looking at security.json in Zookeeper, I notice that both the authentication 
section and the authorization section ends with something like

"":{"v":47}},

Am I correct in thinking that this 47 (in this case) is a version number, and 
that ANY number could be used in the file uploaded to security.json using 
"zkcli.sh -putfile"?

Or is this some sort of checksum whose value must match some unclear criteria?


-----Original Message-----
From: Anshum Gupta [mailto:ans...@anshumgupta.net] 
Sent: Sunday, December 06, 2015 8:42 AM
To: solr-user@lucene.apache.org
Subject: Re: Authorization API versus zkcli.sh

There's nothing cluster specific in security.json if you're using those
plugins. It is totally safe to just take the file from one cluster and
upload it for another for things to work.

On Sat, Dec 5, 2015 at 3:38 AM, Oakley, Craig (NIH/NLM/NCBI) [C] <
craig.oak...@nih.gov> wrote:

> Looking through
> cwiki.apache.org/confluence/display/solr/Authentication+and+Authorization+Plugins
> one notices that security.json is initially created by zkcli.sh, and then
> modified by means of the Authentication API and the Authorization API. By
> and large, this sounds like a good way to accomplish such tasks, assuming
> that these APIs do some error checking to prevent corruption of
> security.json
>
> I was wondering about cases where one is cloning an existing Solr
> instance, such as when creating an instance in Amazon Cloud. If one has a
> security.json that has been thoroughly tried and successfully tested on
> another Solr instance, is it possible / safe / not-un-recommended to use
> zkcli.sh to load the full security.json (as extracted via zkcli.sh from the
> Zookeeper of the thoroughly tested existing instance)? Or would the
> official verdict be that the only acceptable way to create security.json is
> to load a minimal version with zkcli.sh and then to build the remaining
> components with the Authentication API and the Authorization API (in a
> script, if one wants to automate the process: although such a script would
> have to include plain-text passwords)?
>
> I figured there is no harm in asking.
>



-- 
Anshum Gupta

Reply via email to