My curl command works fine for querying, updating etc.
I don't think it is the fault of curl command.
I get the following error message when I tried to change the password of
solr-admin,
Error 403 Unauthorized request, Response code: 403
HTTP ERROR 403
Problem accessing
Hi Salmaan,
Does your curl command works for other curl commands like normal querying?
Or is it just not working when updating password and adding new users?
Regards,
Edwin
On Fri, 2 Aug 2019 at 13:03, Salmaan Rashid Syed
wrote:
> Hi Zheng,
>
> I tried and it works. But, when I use the curl
Hi Zheng,
I tried and it works. But, when I use the curl command to update password
or add new users it doesn't work.
I don't know what is going wrong with curl command!
Regards,
Salmaan
On Fri, Aug 2, 2019 at 8:26 AM Zheng Lin Edwin Yeo
wrote:
> Have you tried to access the Solr Admin UI
Hi,
Does anyone knows if this can be done on the Solr side?
Or it has to be done on the Tika side?
Regards,
Edwin
On Thu, 1 Aug 2019 at 09:38, Zheng Lin Edwin Yeo
wrote:
> Hi,
>
> Would like to check, Is there anyway which we can detect the number of
> attachments and their names during
Have you tried to access the Solr Admin UI with your created user name and
password to see if it works?
Regards,
Edwin
On Thu, 1 Aug 2019 at 19:51, Salmaan Rashid Syed
wrote:
> Hi Solr User,
>
> Please help me with my issue.
>
> I have enabled Solr basic authentication as shown in Solr
Yes, I tried with space and the same error occurs.
I have also tried to put * , but I am getting the same error as well.
4lw.commands.whitelist=*
Regards,
Edwin
On Thu, 1 Aug 2019 at 21:34, Jörn Franke wrote:
> Spaces did not change the situation. In standalone it works without spaces
> and
I don’t think you’re using claudera or ambari, but ambari has an option to
delete the locks. This seems more a configuration/architecture isssue than a
realibility issue. You may want to spin up an alias while you bring down, clear
locks and directories, recreate and index the affected
Been using Solr on HDFS for a while now, and I'm seeing an issue with
redundancy/reliability. If a server goes down, when it comes back up,
it will never recover because of the lock files in HDFS. That solr node
needs to be brought down manually, the lock files deleted, and then
brought back
Also try /admin/zookeeper/status endpoint in solr manually and see if you get a
decent response, if not check error in logs.
Jan Høydahl
> 1. aug. 2019 kl. 20:25 skrev Jörn Franke :
>
> here you go:
> https://issues.apache.org/jira/browse/SOLR-13672
>
> I will check tomorrow Telnet, but I am
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/admin/ZookeeperStatusHandler.java
Jan Høydahl
> 1. aug. 2019 kl. 20:25 skrev Jörn Franke :
>
> here you go:
> https://issues.apache.org/jira/browse/SOLR-13672
>
> I will check tomorrow Telnet, but I am
here you go:
https://issues.apache.org/jira/browse/SOLR-13672
I will check tomorrow Telnet, but I am not so optimistic it is the root
cause, because this I observed already during rolling upgrade where one
node had 3.5.5 and the other 3.4.14. They are all now on 3.5.5.
Do you have a pointer to
Yes, I’m exactly talking about the idea of someone pulling the plug on one of
your machines. RAID doesn’t help you at all with that.
10M docs/shard is pretty low actually, depending on the characteristics of docs
of course. I’ve ween 10M docs strain things. I’ve seen 300M docs fit in 16G
heap.
The hash value
"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
is based on both the plain text password AND the plain test login. Since
"solr" is not the same string as "solr-admin", the password will not work. If
the only authorization in
Yes please do. I made the ZkStatus UI and it works by letting the solr node
that Admin UI is connected to do 4LW commands to each ZK node and then
concatenate the results.
You could try to invoke each of the 4LW commands manually on each ZK server
using telnet, and see if that succeeds for
Spaces did not change the situation. In standalone it works without spaces and
the issue is only if there is an ensemble. I checked all ZK nodes have the
statement and have been restarted .
So issue pics there for a ZK Ensemble only in admin UI. I will create tonight a
JIRA if no one creates
have a SOLR 4.10.2 core, and I am upgrading to 8.1.1.
When I compare parsedQuery for a search 4.10 vs 8.1.1 I am seeing the query
wrapped with SynonymQuery(Synonym( in 8.1.1.
I think it may be because I replaced the deprecated SynonymFilterFactory with
SynonymGraphFilterFactory.
Is this a new
Thank you, I will definitely try it.
Regards,
Salmaan
On Thu, Aug 1, 2019 at 5:40 PM Bernd Fehling
wrote:
>
>
> Am 01.08.19 um 13:57 schrieb Salmaan Rashid Syed:
> > After I make the -Djute.maxbuffer changes to Solr, deployed in
> production,
> > Do I need to restart the solr to be able to
Am 01.08.19 um 13:57 schrieb Salmaan Rashid Syed:
After I make the -Djute.maxbuffer changes to Solr, deployed in production,
Do I need to restart the solr to be able to add synonyms >1MB?
Yes, you have to restart Solr.
Or, Was this supposed to be done before putting Solr to production
After I make the -Djute.maxbuffer changes to Solr, deployed in production,
Do I need to restart the solr to be able to add synonyms >1MB?
Or, Was this supposed to be done before putting Solr to production ever?
Can we make chages when the Solr is running in production?
Thanks.
Regards,
Salmaan
Hi Solr User,
Please help me with my issue.
I have enabled Solr basic authentication as shown in Solr documentations.
I have changed username from solr to solr-admin as follow
{
"authentication":{
"blockUnknown": true,
"class":"solr.BasicAuthPlugin",
Hi Erick,
Thanks for the detailed explanation, much appreciated.
Regarding #1 reason you have mentioned - but if RAID10 is chosen per Shawn's
suggestion, then we should be protected, no ? Unless you mean the whole server
is not available
and not specific disk of configured RAID10.
Interestingly, the code that sets this system property also has spaces, as:
if (System.getProperty(ZK_WHITELIST_PROPERTY) == null) {
System.setProperty(ZK_WHITELIST_PROPERTY, "ruok, mntr, conf");
}
Don’t know if that’s relevant or just a coincidence….
> On Aug 1, 2019, at 6:58 AM, Erick
Please read the “Upgrade Notes” sections of CHANGES.txt for the versions
between 7.3 and 8.2
It’s not necessary to upgrade ZooKeeper, but it is recommended if for no other
reason than SSL isn’t supported on ZK 3.4.x
You should be able to upgrade directly to 8.2, _assuming_ your index was
“why would I need a replication factor of 2….”
Two reasons:
1> assuming your replicas are located on different physical machines, you can
lose one and still keep on running. RAID won’t help if the machine dies.
2> capacity. Depending on your query load, having more than one replica
The issue was only cosmetic in the sense that the admin UI was the only thing
that was affected,
not other Solr functions when I was working on this.
Please check a few things:
1> be absolutely sure that you’ve added this in all your zoo.cfg files
2> the example on the ZooKeeper website has
For me:
* ZK stand-alone mode - no issues
* ZK Ensemble - it seems to be only a cosmetic issue in the Admin UI (I see the
same error message), but aside this Solr is working fine
> Am 01.08.2019 um 12:02 schrieb Zheng Lin Edwin Yeo :
>
> Hi Jörn,
> Thank you for your reply.
>
> I have
Hi Jörn,
Thank you for your reply.
I have encountered problem when I tried to create a collection with this
new version of ZooKeeper. You can find my Solr log file here:
https://drive.google.com/open?id=1qkMLTRJ4eDSFwbqr15wSqjbg4dJV-bGN
Does it work perfectly at your side for creating
I confirm the issue.
Interestingly it does not happen with ZK standalone, but only in a ZK Ensemble.
It seems to be mainly cosmetic in the admin UI because Solr appears to function
normally.
> Am 01.08.2019 um 03:31 schrieb Zheng Lin Edwin Yeo :
>
> Yes. You can get my full solr.log from the
I am not sure but just guessing is this node acting as a repeater?
This seems legitimate as Jai mentioned above, the discrepancy could be
because of unsuccessful replication due to disk space constraints.
On Thu, Aug 1, 2019 at 6:19 AM Aman Tandon wrote:
> Yes, that is what my understanding
Small correction in the user-name. It is solr-admin everywhere.
Hi Solr Users,
I have enabled Solr basic authentication as shown in Solr documentations.
I have changed username from solr to solr-admin as follow
{
"authentication":{
"blockUnknown": true,
"class":"solr.BasicAuthPlugin",
Hi Solr Users,
I have enabled Solr basic authentication as shown in Solr documentations.
I have changed username from solr to solr-admin as follow
{
"authentication":{
"blockUnknown": true,
"class":"solr.BasicAuthPlugin",
Hi Shawn,
Thanks for your reply, fully agree with your comments, it clarifies more the
need of RAID10 in this case.
One additional follow-up question - in case we follow this guidelines and
having RAID10 (which leaves us with effective capacity of 50%), why would I need
replication factor of 2
Hi all,
We have a 3 node solr cluster - version 7.3.0 using zookeeper -version
3.4.12, running on CentOS Linux release 7.6.1810. I would like to upgrade
to Solr version 8.2.
Is it necessary to upgrade zookeeper also?
Is it OK to upgrade directly to 8.2?
Any tips/checklist would be welcome.
33 matches
Mail list logo
