Re: Authorization API versus zkcli.sh
yes, that's the assumption. The reason why there's a version there is to
optimize on reloads i.e. Authentication and Authorization plugins are
reloaded only when the version number is changed. e.g.
* Start with Ver 1 for both authentication and authorization
* Make changes to Authentication, the version for this section is updated
to the znode version, while the version for the authorization section is
not changed. This forces the authentication plugin to be reloaded but not
the authorization plugin. Similarly for authorization.
It's a way to optimize the reloads without splitting the definition into 2
znodes, which is also an option.
On Fri, Dec 11, 2015 at 8:06 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:
> Shouldn't this be the znode version? Why put a version in
> security.json? Or is the idea that the user will upload security.json
> only once and then use the security APIs for all further changes?
>
> On Fri, Dec 11, 2015 at 11:51 AM, Noble Paul <noble.p...@gmail.com> wrote:
> > Please do not put any number. That number is used by the system to
> > optimize loading/reloading plugins. It is not relevant for the user.
> >
> > On Thu, Dec 10, 2015 at 11:52 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
> > <craig.oak...@nih.gov> wrote:
> >> 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
> >
> >
> >
> > --
> > -
> > Noble Paul
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
--
Anshum Gupta
Re: Authorization API versus zkcli.sh
Shouldn't this be the znode version? Why put a version in
security.json? Or is the idea that the user will upload security.json
only once and then use the security APIs for all further changes?
On Fri, Dec 11, 2015 at 11:51 AM, Noble Paul <noble.p...@gmail.com> wrote:
> Please do not put any number. That number is used by the system to
> optimize loading/reloading plugins. It is not relevant for the user.
>
> On Thu, Dec 10, 2015 at 11:52 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
> <craig.oak...@nih.gov> wrote:
>> 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
>
>
>
> --
> -
> Noble Paul
--
Regards,
Shalin Shekhar Mangar.
RE: Authorization API versus zkcli.sh
So, when one has finished constructing the desired security.json (by means of
Authentication and Authorization commands) and then run "zkcli.sh -cmd getfile"
to get this security.json in order for it to be used as a template: one should
edit the template to remove this "":{"v":85} clause (and the comma which
precedes it): correct?
I notice that the documented minimal security.json which simply creates the
solr:SolrRocks login:pswd does not have such a clause: so I assume that the
lack of such a clause is not an error.
From: Anshum Gupta [ans...@anshumgupta.net]
Sent: Friday, December 11, 2015 9:48 AM
To: solr-user@lucene.apache.org
Subject: Re: Authorization API versus zkcli.sh
yes, that's the assumption. The reason why there's a version there is to
optimize on reloads i.e. Authentication and Authorization plugins are
reloaded only when the version number is changed. e.g.
* Start with Ver 1 for both authentication and authorization
* Make changes to Authentication, the version for this section is updated
to the znode version, while the version for the authorization section is
not changed. This forces the authentication plugin to be reloaded but not
the authorization plugin. Similarly for authorization.
It's a way to optimize the reloads without splitting the definition into 2
znodes, which is also an option.
On Fri, Dec 11, 2015 at 8:06 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:
> Shouldn't this be the znode version? Why put a version in
> security.json? Or is the idea that the user will upload security.json
> only once and then use the security APIs for all further changes?
>
> On Fri, Dec 11, 2015 at 11:51 AM, Noble Paul <noble.p...@gmail.com> wrote:
> > Please do not put any number. That number is used by the system to
> > optimize loading/reloading plugins. It is not relevant for the user.
> >
> > On Thu, Dec 10, 2015 at 11:52 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
> > <craig.oak...@nih.gov> wrote:
> >> 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
> >
> >
> >
> > --
> > -
> > Noble Paul
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
--
Anshum Gupta
Re: Authorization API versus zkcli.sh
Oakley,
1) ideally you should only upload the first empty security.json. In
that case there is no need to add the version attributes. Thereafter
you are supposed to use the API
2) Just in case you need to upload the security.json, please remove
that attribute
shalin:
The version is added inside the json is because we have no idea
whether an edit caused authentication or authorization to be reloaded
. By adding separate versions I'm able to make that distinction
On Fri, Dec 11, 2015 at 9:02 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
<craig.oak...@nih.gov> wrote:
> So, when one has finished constructing the desired security.json (by means of
> Authentication and Authorization commands) and then run "zkcli.sh -cmd
> getfile" to get this security.json in order for it to be used as a template:
> one should edit the template to remove this "":{"v":85} clause (and the comma
> which precedes it): correct?
>
> I notice that the documented minimal security.json which simply creates the
> solr:SolrRocks login:pswd does not have such a clause: so I assume that the
> lack of such a clause is not an error.
>
>
> From: Anshum Gupta [ans...@anshumgupta.net]
> Sent: Friday, December 11, 2015 9:48 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Authorization API versus zkcli.sh
>
> yes, that's the assumption. The reason why there's a version there is to
> optimize on reloads i.e. Authentication and Authorization plugins are
> reloaded only when the version number is changed. e.g.
> * Start with Ver 1 for both authentication and authorization
> * Make changes to Authentication, the version for this section is updated
> to the znode version, while the version for the authorization section is
> not changed. This forces the authentication plugin to be reloaded but not
> the authorization plugin. Similarly for authorization.
>
> It's a way to optimize the reloads without splitting the definition into 2
> znodes, which is also an option.
>
>
> On Fri, Dec 11, 2015 at 8:06 PM, Shalin Shekhar Mangar <
> shalinman...@gmail.com> wrote:
>
>> Shouldn't this be the znode version? Why put a version in
>> security.json? Or is the idea that the user will upload security.json
>> only once and then use the security APIs for all further changes?
>>
>> On Fri, Dec 11, 2015 at 11:51 AM, Noble Paul <noble.p...@gmail.com> wrote:
>> > Please do not put any number. That number is used by the system to
>> > optimize loading/reloading plugins. It is not relevant for the user.
>> >
>> > On Thu, Dec 10, 2015 at 11:52 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
>> > <craig.oak...@nih.gov> wrote:
>> >> 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 instanc
RE: Authorization API versus zkcli.sh
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
Re: Authorization API versus zkcli.sh
Please do not put any number. That number is used by the system to
optimize loading/reloading plugins. It is not relevant for the user.
On Thu, Dec 10, 2015 at 11:52 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
<craig.oak...@nih.gov> wrote:
> 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
--
-
Noble Paul
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
Re: Authorization API versus zkcli.sh
As I see things, if you're using Basic Authentication and/or Rule Based Authorization, then the security.json could be copied over to start things. 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. >
