RE: Programmatic Basic Auth on CloudSolrClient
Hi Tomas, Tried your suggestion. But last suggestion (directly passing the httpclient) resilts in NonRepeatableRequestException. And using full step, also didn’t recognize the auth. Anything I should look for? Thanks, Subhajit From: Tomás Fernández Löbbe<mailto:tomasflo...@gmail.com> Sent: 05 March 2021 04:23 AM To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org> Subject: Re: Programmatic Basic Auth on CloudSolrClient Ah, right, now I remember that something like this was possible with the "http1" version of the clients, which is why I created the Jira issues for the http2 ones. Maybe you can even skip the "LBHttpSolrClient" step, I believe you can just pass the HttpClient to the CloudSolrClient? you will have to make sure to close all the clients that are created externally after done, since the Solr client won't in this case. On Thu, Mar 4, 2021 at 1:22 PM Mark H. Wood wrote: > On Wed, Mar 03, 2021 at 10:34:50AM -0800, Tomás Fernández Löbbe wrote: > > As far as I know the current OOTB options are system properties or > > per-request (which would allow you to use different per collection, but > > probably not ideal if you do different types of requests from different > > parts of your code). A workaround (which I've used in the past) is to > have > > a custom client that overrides and sets the credentials in the "request" > > method (you can put whatever logic there to identify which credentials to > > use). I recently created > https://issues.apache.org/jira/browse/SOLR-15154 > > and https://issues.apache.org/jira/browse/SOLR-15155 to try to address > this > > issue in future releases. > > I have not tried it, but could you not: > > 1. set up an HttpClient with an appropriate CredentialsProvider; > 2. pass it to HttpSolrClient.Builder.withHttpClient(); > 2. pass that Builder to > LBHttpSolrClient.Builder.withHttpSolrClientBuilder(); > 3. pass *that* Builder to > CloudSolrClient.Builder.withLBHttpSolrClientBuilder(); > > Now you have control of the CredentialsProvider and can have it return > whatever credentials you wish, so long as you still have a reference > to it. > > > On Wed, Mar 3, 2021 at 5:42 AM Subhajit Das > wrote: > > > > > > > > Hi There, > > > > > > Is there any way to programmatically set basic authentication > credential > > > on CloudSolrClient? > > > > > > The only documentation available is to use system property. This is not > > > useful if two collection required two separate set of credentials and > they > > > are parallelly accessed. > > > Thanks in advance. > > > > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu<http://www.ulib.iupui.edu> >
RE: Programmatic Basic Auth on CloudSolrClient
Thanks. This would be very helpful.
From: Tomás Fernández Löbbe<mailto:tomasflo...@gmail.com>
Sent: 04 March 2021 12:32 AM
To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
Subject: Re: Programmatic Basic Auth on CloudSolrClient
Maybe something like this (I omitted a lot of things you'll have to do,
like passing zk or the list of hosts):
static class CustomCloudSolrClient extends CloudSolrClient {
protected CustomCloudSolrClient(CustomCloudSolrClientBuilder builder) {
super(builder);
}
@Override
public NamedList request(SolrRequest request, String
collection) throws SolrServerException, IOException {
// your logic here to figure out which credentials to use...
String user = "user";
String pass = "pass";
request.setBasicAuthCredentials(user, pass);
return super.request(request, collection);
}
}
static class CustomCloudSolrClientBuilder extends CloudSolrClient.Builder {
@Override
public CloudSolrClient build() {
return new CustomCloudSolrClient(this);
}
}
public static void main(String[] args) {
CloudSolrClient c = new CustomCloudSolrClientBuilder().build();
...
}
Do consider that "request" method is called per request, make sure whatever
logic you have there is not super expensive.
On Wed, Mar 3, 2021 at 10:48 AM Subhajit Das
wrote:
> Hi Thomas,
>
> Thanks. Can you please also share a sample of code to configure the client
> with your workaround?
>
> From: Tomás Fernández Löbbe<mailto:tomasflo...@gmail.com>
> Sent: 04 March 2021 12:05 AM
> To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
> Subject: Re: Programmatic Basic Auth on CloudSolrClient
>
> As far as I know the current OOTB options are system properties or
> per-request (which would allow you to use different per collection, but
> probably not ideal if you do different types of requests from different
> parts of your code). A workaround (which I've used in the past) is to have
> a custom client that overrides and sets the credentials in the "request"
> method (you can put whatever logic there to identify which credentials to
> use). I recently created https://issues.apache.org/jira/browse/SOLR-15154
> and https://issues.apache.org/jira/browse/SOLR-15155 to try to address
> this
> issue in future releases.
>
> On Wed, Mar 3, 2021 at 5:42 AM Subhajit Das
> wrote:
>
> >
> > Hi There,
> >
> > Is there any way to programmatically set basic authentication credential
> > on CloudSolrClient?
> >
> > The only documentation available is to use system property. This is not
> > useful if two collection required two separate set of credentials and
> they
> > are parallelly accessed.
> > Thanks in advance.
> >
>
>
RE: Programmatic Basic Auth on CloudSolrClient
Hi Thomas, Thanks. Can you please also share a sample of code to configure the client with your workaround? From: Tomás Fernández Löbbe<mailto:tomasflo...@gmail.com> Sent: 04 March 2021 12:05 AM To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org> Subject: Re: Programmatic Basic Auth on CloudSolrClient As far as I know the current OOTB options are system properties or per-request (which would allow you to use different per collection, but probably not ideal if you do different types of requests from different parts of your code). A workaround (which I've used in the past) is to have a custom client that overrides and sets the credentials in the "request" method (you can put whatever logic there to identify which credentials to use). I recently created https://issues.apache.org/jira/browse/SOLR-15154 and https://issues.apache.org/jira/browse/SOLR-15155 to try to address this issue in future releases. On Wed, Mar 3, 2021 at 5:42 AM Subhajit Das wrote: > > Hi There, > > Is there any way to programmatically set basic authentication credential > on CloudSolrClient? > > The only documentation available is to use system property. This is not > useful if two collection required two separate set of credentials and they > are parallelly accessed. > Thanks in advance. >
Programmatic Basic Auth on CloudSolrClient
Hi There, Is there any way to programmatically set basic authentication credential on CloudSolrClient? The only documentation available is to use system property. This is not useful if two collection required two separate set of credentials and they are parallelly accessed. Thanks in advance.
RE: Zookeeper 3.4.5 with Solr 8.8.0
Hi Shawn, That is not possible at this time. Will it be ok, if remote the zookeeper dependencies (jars) from solr and replace it with 3.5.5 jars? Thanks in advance. From: Shawn Heisey Sent: Monday, March 1, 2021 11:17:24 PM To: solr-user@lucene.apache.org ; u...@zookeeper.apache.org Subject: Re: Zookeeper 3.4.5 with Solr 8.8.0 On 3/1/2021 6:51 AM, Subhajit Das wrote: > I noticed, that Solr 8.8.0 uses Zookeeper 3.6.2 client, while Solr 6.3.0 uses > Zookeeper 3.4.6 client. Is this a client bug or mismatch issue? > If so, how to fix this? The ZK project guarantees that each minor version (X.Y.Z, where Y is the same) will work with the previous minor version or the next minor version. 3.4 and 3.6 are two minor versions apart, and thus compatibility cannot be guaranteed. See the "backward compatibility" matrix here: https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement I think you'll need to upgrade your ZK server ensemble to fix it. Thanks, Shawn
Zookeeper 3.4.5 with Solr 8.8.0
Hi There, I am setting up Solr 8.8.0 with Zookeeper 3.4.5. There seems to an issue. EndOfStream issue is coming, saying client must have closed the connection. If same tried with Solr 6.3.0, the issue dosen’t come. This comes with newer Solr only. I noticed, that Solr 8.8.0 uses Zookeeper 3.6.2 client, while Solr 6.3.0 uses Zookeeper 3.4.6 client. Is this a client bug or mismatch issue? If so, how to fix this? Thanks in advance.
RE: How to read tlog
Thanks for reply. Will try. From: Gael Jourdan-Weil<mailto:gael.jourdan-w...@kelkoogroup.com> Sent: 01 March 2021 05:48 PM To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org> Subject: RE: How to read tlog Hello, You can just use "cat" or "tail", even though the tlog is not a text file, its content can mostly be read using these commands. You will have one document per line and should be able to see the fields content. I don't know is there is a Solr command which would give better display though. Gaël De : Subhajit Das Envoyé : samedi 27 février 2021 16:00 À : solr-user@lucene.apache.org Objet : How to read tlog Hi There, I faced a issue, on a core, in multicore standalone instance. Is there any way to read tlog contents as text files. This might help to resolve the issue. Thanks in advance.
How to read tlog
Hi There, I faced a issue, on a core, in multicore standalone instance. Is there any way to read tlog contents as text files. This might help to resolve the issue. Thanks in advance.
Rule Based Authorization
Hi There, I am trying to create a rule based authorization for two types of user. Role : Access - power-user : Everything except data change in collections/cores ui-user : UI access to view all data. But no edit access except data change in collections/cores How to implement this? No predefined permissions for this. Tried by adding all read permissions to this ui-user. But dosent wok. One of failing APIs is “/admin/info/system”. Cant match this url, with custom permission also. Please help. Thanks in advance.
RE: nodes() stream to infinite depth
Hi Joel,
This stream seems to be somewhat alternative. Thanks for the suggestion.
The main issue here would be:
1. As I am traversing up in a tree, I would need a dummy root node for all
documents, as “to” is mandatory.
2. This emits one tuple per path. So, for my requirement, I will get only
one data tuple. This removes the advantage of streaming, with 1 tuple per node.
So, it seems that I have to use {!graph...} syntax. As, my collection has one
shard, so it should be same, basically.
Though, one noticeable advantage of using shortest path, would be:
1. The list inside tuple, is based on traversal order. Unlike {!graph..}.
Though, I can sort by date to get the same result. Additionally I would get
full result, will all document fields.
Thanks for suggestion though.
From: Joel Bernstein<mailto:joels...@gmail.com>
Sent: 20 February 2021 01:20 AM
To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
Subject: Re: nodes() stream to infinite depth
You could see if this meets you needs:
https://lucene.apache.org/solr/guide/8_8/stream-source-reference.html#shortestpath
Joel Bernstein
http://joelsolr.blogspot.com/
On Fri, Feb 19, 2021 at 2:45 PM Subhajit Das
wrote:
> Hi Joel,
>
> Thanks for response. But, is there any way to simulate the same?
>
>
> From: Joel Bernstein<mailto:joels...@gmail.com>
> Sent: 20 February 2021 01:13 AM
> To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
> Subject: Re: nodes() stream to infinite depth
>
> Nodes is designed for a stepwise graph walk. It doesn't do a full
> traversal.
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Fri, Feb 19, 2021 at 4:47 AM Subhajit Das
> wrote:
>
> >
> > Hi,
> >
> > “{!graph ...}” goes to infinite depth by default. But “nodes()” stream
> > does not go to infinite depth.
> >
> > Is there any way to go to infinite depth?
> >
> >
>
>
RE: nodes() stream to infinite depth
Hi Joel,
Thanks for response. But, is there any way to simulate the same?
From: Joel Bernstein<mailto:joels...@gmail.com>
Sent: 20 February 2021 01:13 AM
To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org>
Subject: Re: nodes() stream to infinite depth
Nodes is designed for a stepwise graph walk. It doesn't do a full traversal.
Joel Bernstein
http://joelsolr.blogspot.com/
On Fri, Feb 19, 2021 at 4:47 AM Subhajit Das
wrote:
>
> Hi,
>
> “{!graph ...}” goes to infinite depth by default. But “nodes()” stream
> does not go to infinite depth.
>
> Is there any way to go to infinite depth?
>
>
nodes() stream to infinite depth
Hi,
“{!graph ...}” goes to infinite depth by default. But “nodes()” stream does not
go to infinite depth.
Is there any way to go to infinite depth?
RE: Is 8.8.x going be stabilized and finalized?
Hi Shawn, Nice to know that Solr will be considered top level project of Apache. I asked based on earlier 3 version patterns. Just hoping that 8.8 would be long term stable, kind of like 7.7.x line-up. Thanks for the clarification. Regards, Subhajit From: Shawn Heisey<mailto:apa...@elyograg.org> Sent: 17 February 2021 09:33 AM To: solr-user@lucene.apache.org<mailto:solr-user@lucene.apache.org> Subject: Re: Is 8.8.x going be stabilized and finalized? On 2/16/2021 7:57 PM, Subhajit Das wrote: > I am planning to use 8.8 line-up for production use. > > But recently, a lot of people are complaining on 8.7 and 8.8. Also, there is > a clearly known issue on 8.8 as well. > > Following trends of earlier versions (5.x, 6.x and 7.x), will 8.8 will also > be finalized? > For 5.x, 5.5.x was last version. For 6.x, 6.6.x was last version. For 7.x, > 7.7.x was last version. It would match the pattern, it seems. > And 9.x is already planned and under development. > And it seems, we require some stability. All released versions are considered stable. Sometimes problems are uncovered after release. Sometimes BIG problems. We try our very best to avoid bugs, but achieving that kind of perfection is nearly impossible for any software project. 8.8.0 is the most current release. The 8.8.1 release is underway, but there's no way I can give you a concrete date. The announcement MIGHT come in the next few days, but it's always possible it could get pushed back. At this time, the changelog for 8.8.1 has five bugfixes mentioned. It should be more stable than 8.8.0, but it's impossible for me to tell you whether you will have any problems with it. On the dev list, the project is discussing the start of work on the 9.0 release, but that work has not yet begun. Even if it started tomorrow, it would be several weeks, maybe even a few months, before 9.0 is actually released. On top of the "normal" headaches involved in any new major version release, there are some other things going on that might further delay 9.0 and future 8.x versions: * Solr is being promoted from a subproject of Lucene to it's own top-level project at Apache. This involves a LOT of work. Much of that work is administrative in nature, which is going to occupy us and take away from time that we might spend working on the code and new releases. * The build system for the master branch, which is currently versioned as 9.0.0-SNAPSHOT, was recently switched from Ant+Ivy to Gradle. It's going to take some time to figure out all the fallout from that migration. * Some of the devs have been involved in an effort to greatly simplify and rewrite how SolrCloud does internal management of a cluster. The intent is much better stability and better performance. You might have seen public messages referring to a "reference implementation." At this time, it is unclear how much of that work will make it into 9.0 and how much will be revealed in later releases. We would like very much to include at least the first phase in 9.0 if we can. From what I have seen over the last several years as one of the developers on this project, it is likely that 8.9 and possibly even 8.10 and 8.11 will be released before we see 9.0. Releases are NOT made on a specific schedule, so I cannot tell you which versions you will see or when they might happen. I am fully aware that despite typing quite a lot of text here, that I provided almost nothing in the way of concrete information that you can use. Sorry about that. Thanks, Shawn
Is 8.8.x going be stabilized and finalized?
Hi there, I am planning to use 8.8 line-up for production use. But recently, a lot of people are complaining on 8.7 and 8.8. Also, there is a clearly known issue on 8.8 as well. Following trends of earlier versions (5.x, 6.x and 7.x), will 8.8 will also be finalized? For 5.x, 5.5.x was last version. For 6.x, 6.6.x was last version. For 7.x, 7.7.x was last version. It would match the pattern, it seems. And 9.x is already planned and under development. And it seems, we require some stability. Thanks in advance.
SolrCloud 8.7.0 with Zookeeper 3.4.5
Hi There, I am planning to implement Solr cloud 8.7.0 with existing Zookeeper 3.4.5. This is cloudera provided zookeeper. Is there any red flags, for such configuration, as I couldn’t find any compatibility matrix? Many thanks in advance. Regards, Subhajit
Solr 8.7.0 in Cloud mode with Zookeeper 3.4.5 cdh 5.16
Hi, We are planning to implement Solr Cloud 8.7.0, running in Kubernetes cluster, with external Zookeeper 3.4.5 cdh 5.16. Solr 8.7.0 seems to be matched with Zookeeper 3.6.2. Is there any issue using Zookeeper 3.4.5 cdh 5.16? Thanks in advance. Regards, Subhajit
