date:20191206

janhoy commented on a change in pull request #1058: SOLR-13972: Warn about 
insecure settings on startup
URL: https://github.com/apache/lucene-solr/pull/1058#discussion_r354736229
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
 ##
 @@ -897,6 +899,20 @@ private void reloadSecurityProperties() {
 initializeAuditloggerPlugin((Map) 
securityConfig.getData().get("auditlogging"));
   }
 
+  private void warnUsersIfSecurityDisabled() {
+if (authenticationPlugin == null || authorizationPlugin == null) {
+  log.warn("Not all security plugins configured!  authentication={} 
authorization={}.  Solr is only as secure as " +
+  "you make it. Consider configuring authentication/authorization 
before exposing Solr to users internal or " +
+  "external.  See 
https://lucene.apache.org/solr/guide/authentication-and-authorization-plugins.html
 for more info",
 
 Review comment:
   Point to securing-solr parent page instead?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13972) Insecure Solr should generate startup warning



[ 
https://issues.apache.org/jira/browse/SOLR-13972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989584#comment-16989584
 ] 

Jan Høydahl commented on SOLR-13972:


Commented on the PR.

Linking with SOLR-13985 since I think these two should be seen together. Should 
be no need to warn about SSL etc for localhost dev use?

> Insecure Solr should generate startup warning
> -
>
> Key: SOLR-13972
> URL: https://issues.apache.org/jira/browse/SOLR-13972
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Warning to the effect of, start Solr with: "solr auth enable -credentials 
> solr:foo -blockUnknown true” (or some other way to achieve the same effect) 
> if you want to expose this Solr instance directly to users. Maybe the link to 
> the ref guide discussing all this might be in good measure here.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13954) Embedded ZooKeeper in Solr fails to load JettyAdminServer

2019-12-06 Thread Colvin Cowie (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989597#comment-16989597
 ] 

Colvin Cowie commented on SOLR-13954:
-

(y)

> Embedded ZooKeeper in Solr fails to load JettyAdminServer
> -
>
> Key: SOLR-13954
> URL: https://issues.apache.org/jira/browse/SOLR-13954
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2, 8.3
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: ZooKeeper
> Fix For: 8.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Running solr with the embedded zookeeper, e.g. when running _solr -e cloud_ 
> results in a ClassNotFoundException / NoClassDefFoundError in the log as 
> below. The server still functions correctly (except JettyAdminServer won't 
> work obviously), but it _looks_ like a problem, and isn't good for a first 
> time user to see
> {noformat}
> 2019-11-21 17:25:14.292 INFO  (main) [   ] o.a.s.c.SolrZkServer STARTING 
> EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
> 2019-11-21 17:25:14.792 INFO  (main) [   ] o.a.s.c.ZkContainer Zookeeper 
> client=localhost:9983
> 2019-11-21
>  17:25:18.833 WARN  (Thread-13) [   ] o.a.z.s.a.AdminServerFactory 
> Unable to load jetty, not starting JettyAdminServer => 
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method)
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method) ~[?:1.8.0_191]
>   at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_191]
>   at 
> org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
>  ~[?:?]
>   at 
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:136)
>  ~[?:?]
>   at org.apache.solr.cloud.SolrZkServer$1.run(SolrZkServer.java:121) 
> ~[?:?]
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector
>   at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:577)
>  ~[jetty-webapp-9.4.19.v20190610.jar:9.4.19.v20190610]
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_191]
>   ... 5 more
> 2019-11-21 17:25:19.365 INFO  (main) [   ] o.a.s.c.c.ConnectionManager 
> Waiting for client to connect to ZooKeeper
> 2019-11-21 17:25:19.396 INFO  (zkConnectionManagerCallback-7-thread-1) [   ] 
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2019-11-21 17:25:19.396 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Client 
> is connected to ZooKeeper{noformat}
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] janhoy merged pull request #1059: SOLR-13954: Embedded ZK in Solr now does not try to load JettyAdminServer

2019-12-06 Thread ASF subversion and git services (Jira)

janhoy merged pull request #1059: SOLR-13954: Embedded ZK in Solr now does not 
try to load JettyAdminServer
URL: https://github.com/apache/lucene-solr/pull/1059
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13954) Embedded ZooKeeper in Solr fails to load JettyAdminServer



[ 
https://issues.apache.org/jira/browse/SOLR-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989599#comment-16989599
 ] 

ASF subversion and git services commented on SOLR-13954:


Commit 7417fa1cf3a7875b76419793a38080059f52b1fc in lucene-solr's branch 
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7417fa1 ]

SOLR-13954: Embedded ZooKeeper in Solr now does not try to load 
JettyAdminServer (#1059)



> Embedded ZooKeeper in Solr fails to load JettyAdminServer
> -
>
> Key: SOLR-13954
> URL: https://issues.apache.org/jira/browse/SOLR-13954
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2, 8.3
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: ZooKeeper
> Fix For: 8.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Running solr with the embedded zookeeper, e.g. when running _solr -e cloud_ 
> results in a ClassNotFoundException / NoClassDefFoundError in the log as 
> below. The server still functions correctly (except JettyAdminServer won't 
> work obviously), but it _looks_ like a problem, and isn't good for a first 
> time user to see
> {noformat}
> 2019-11-21 17:25:14.292 INFO  (main) [   ] o.a.s.c.SolrZkServer STARTING 
> EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
> 2019-11-21 17:25:14.792 INFO  (main) [   ] o.a.s.c.ZkContainer Zookeeper 
> client=localhost:9983
> 2019-11-21
>  17:25:18.833 WARN  (Thread-13) [   ] o.a.z.s.a.AdminServerFactory 
> Unable to load jetty, not starting JettyAdminServer => 
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method)
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method) ~[?:1.8.0_191]
>   at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_191]
>   at 
> org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
>  ~[?:?]
>   at 
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:136)
>  ~[?:?]
>   at org.apache.solr.cloud.SolrZkServer$1.run(SolrZkServer.java:121) 
> ~[?:?]
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector
>   at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:577)
>  ~[jetty-webapp-9.4.19.v20190610.jar:9.4.19.v20190610]
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_191]
>   ... 5 more
> 2019-11-21 17:25:19.365 INFO  (main) [   ] o.a.s.c.c.ConnectionManager 
> Waiting for client to connect to ZooKeeper
> 2019-11-21 17:25:19.396 INFO  (zkConnectionManagerCallback-7-thread-1) [   ] 
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2019-11-21 17:25:19.396 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Client 
> is connected to ZooKeeper{noformat}
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13954) Embedded ZooKeeper in Solr fails to load JettyAdminServer

2019-12-06 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989601#comment-16989601
 ] 

ASF subversion and git services commented on SOLR-13954:


Commit 912789bb933b18742c72c48b6018985fd53f69ce in lucene-solr's branch 
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=912789b ]

SOLR-13954: Embedded ZooKeeper in Solr now does not try to load 
JettyAdminServer (#1059)

(cherry picked from commit 7417fa1cf3a7875b76419793a38080059f52b1fc)


> Embedded ZooKeeper in Solr fails to load JettyAdminServer
> -
>
> Key: SOLR-13954
> URL: https://issues.apache.org/jira/browse/SOLR-13954
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2, 8.3
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: ZooKeeper
> Fix For: 8.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Running solr with the embedded zookeeper, e.g. when running _solr -e cloud_ 
> results in a ClassNotFoundException / NoClassDefFoundError in the log as 
> below. The server still functions correctly (except JettyAdminServer won't 
> work obviously), but it _looks_ like a problem, and isn't good for a first 
> time user to see
> {noformat}
> 2019-11-21 17:25:14.292 INFO  (main) [   ] o.a.s.c.SolrZkServer STARTING 
> EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
> 2019-11-21 17:25:14.792 INFO  (main) [   ] o.a.s.c.ZkContainer Zookeeper 
> client=localhost:9983
> 2019-11-21
>  17:25:18.833 WARN  (Thread-13) [   ] o.a.z.s.a.AdminServerFactory 
> Unable to load jetty, not starting JettyAdminServer => 
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method)
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method) ~[?:1.8.0_191]
>   at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_191]
>   at 
> org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
>  ~[?:?]
>   at 
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:136)
>  ~[?:?]
>   at org.apache.solr.cloud.SolrZkServer$1.run(SolrZkServer.java:121) 
> ~[?:?]
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector
>   at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:577)
>  ~[jetty-webapp-9.4.19.v20190610.jar:9.4.19.v20190610]
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_191]
>   ... 5 more
> 2019-11-21 17:25:19.365 INFO  (main) [   ] o.a.s.c.c.ConnectionManager 
> Waiting for client to connect to ZooKeeper
> 2019-11-21 17:25:19.396 INFO  (zkConnectionManagerCallback-7-thread-1) [   ] 
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2019-11-21 17:25:19.396 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Client 
> is connected to ZooKeeper{noformat}
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Resolved] (SOLR-13954) Embedded ZooKeeper in Solr fails to load JettyAdminServer



 [ 
https://issues.apache.org/jira/browse/SOLR-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl resolved SOLR-13954.

Resolution: Fixed

> Embedded ZooKeeper in Solr fails to load JettyAdminServer
> -
>
> Key: SOLR-13954
> URL: https://issues.apache.org/jira/browse/SOLR-13954
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2, 8.3
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: ZooKeeper
> Fix For: 8.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Running solr with the embedded zookeeper, e.g. when running _solr -e cloud_ 
> results in a ClassNotFoundException / NoClassDefFoundError in the log as 
> below. The server still functions correctly (except JettyAdminServer won't 
> work obviously), but it _looks_ like a problem, and isn't good for a first 
> time user to see
> {noformat}
> 2019-11-21 17:25:14.292 INFO  (main) [   ] o.a.s.c.SolrZkServer STARTING 
> EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
> 2019-11-21 17:25:14.792 INFO  (main) [   ] o.a.s.c.ZkContainer Zookeeper 
> client=localhost:9983
> 2019-11-21
>  17:25:18.833 WARN  (Thread-13) [   ] o.a.z.s.a.AdminServerFactory 
> Unable to load jetty, not starting JettyAdminServer => 
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method)
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method) ~[?:1.8.0_191]
>   at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_191]
>   at 
> org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
>  ~[?:?]
>   at 
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:136)
>  ~[?:?]
>   at org.apache.solr.cloud.SolrZkServer$1.run(SolrZkServer.java:121) 
> ~[?:?]
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector
>   at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:577)
>  ~[jetty-webapp-9.4.19.v20190610.jar:9.4.19.v20190610]
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_191]
>   ... 5 more
> 2019-11-21 17:25:19.365 INFO  (main) [   ] o.a.s.c.c.ConnectionManager 
> Waiting for client to connect to ZooKeeper
> 2019-11-21 17:25:19.396 INFO  (zkConnectionManagerCallback-7-thread-1) [   ] 
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2019-11-21 17:25:19.396 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Client 
> is connected to ZooKeeper{noformat}
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13987) fix admin UI to not rely on javascript eval()



[ 
https://issues.apache.org/jira/browse/SOLR-13987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989605#comment-16989605
 ] 

Jan Høydahl commented on SOLR-13987:


Thanks Kevin. I remember having looked at some of this crazy angular CSP at 
some point, perhpas even tried a quick fix but ran out of time or something. 
I'm happy to try out whatever you end up with and perhaps help out - I've been 
around most of the UI earlier.

> fix admin UI to not rely on javascript eval()
> -
>
> Key: SOLR-13987
> URL: https://issues.apache.org/jira/browse/SOLR-13987
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
>
> Followup from SOLR-13982: currently any CSP is weak because it must allow 
> this eval: means arbitrary javascript can still be executed. 
> Let's fix the admin UI to not require eval so it can be disabled by the 
> browser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14023) tests.src.home points at ${user.dir}" for tests (?!)

Dawid Weiss created SOLR-14023:
--

 Summary: tests.src.home points at ${user.dir}" for tests (?!)
 Key: SOLR-14023
 URL: https://issues.apache.org/jira/browse/SOLR-14023
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Dawid Weiss


The "tests.src.home" variable points at ${user.dir} in common-build.xml. This 
property is used as a fallback in ExternalPaths to locate Solr sources to 
resolve certain paths...

All of the logic present in ExternalPaths is just wrong, really. It should be 
an explicit property pointing at an explicit location (ideally the output of a 
distribution assemble folder) which tests would then use.

As it stands now the code scans upwards from user.dir...

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14014) Allow Solr to start with Admin UI disabled



[ 
https://issues.apache.org/jira/browse/SOLR-14014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989623#comment-16989623
 ] 

Jan Høydahl commented on SOLR-14014:


{quote}Having the convenience of the admin UI has led us to neglect our APIs.
{quote}
That's a simplification and no excuse for designing bad APIs, but I get your 
point that you don't feel the pain of awkward APIs every day if you always just 
use the UI. But it is anyway not an argument to remove the UI. Remember where 
we came from with JSP and no APIs - the only way to do certain things was 
through inline Java code in those JSPs (yuck!).

I support the idea of a way to disable Admin UI for those that do not use it 
anyway. I think too that something like {{-DenableAdminUI=false}} is a better 
value. Also there should be no reason to disable it by default. The presence of 
the UI is no threat in itself, it is in the moment an Admin person loads it and 
becomes victim of XSS, cliks a link etc that it can hurt the Solr server.

My proposal is thus to educate the user through the AdminUI itself by adding a 
big fat INFO message on top of the dashboard that everyone will see. The 
message will be something like this:
{noformat}
IMPORTANT NOTICE

This is the Solr Administrative interface. It is a HTML5 application running in 
your browser. It talks to the Apache Solr server using HTTP calls, just as any 
other client. The UI gives great power, and can open up new security threats 
such as XSS attacks, if you as an administrator is not very careful when using 
it. Please read our recommendations in the Reference Guide  on what 
precautions to take. The most important are:

* Require some form of authentication to Solr
* Use a separate web browser for Solr, do not load other web sites in other tabs
* Log out when you are done
* Keep up to date on CVE vulnerabilities and keep Solr updated 

If you do not need the Admin UI, it can be disabled by starting Solr with the 
System property -DenableAdminUI=false.

WARNING: Your Solr instance is not protected by Authentication. 
WARNING: Your Solr instance does not use SSL. 
WARNING: Your Solr instance allows config edit though REST API 
WARNING: There is a newer version of Solr available, consider upgrading 


[Learn more about securing Solr]   [Dismiss. We'll set a cookie and not 
show this again]{noformat}
This would probably be a better channel to reach out to Admins than both the 
Ref-guide, mailing list and the Web page combined :)

> Allow Solr to start with Admin UI disabled
> --
>
> Key: SOLR-14014
> URL: https://issues.apache.org/jira/browse/SOLR-14014
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, security
>Affects Versions: master (9.0), 8.3.1
>Reporter: Jason Gerlowski
>Priority: Major
>
> Currently Solr always runs the Admin UI. With the history of XSS issues and 
> other security concerns that have been found in the Admin UI, Solr should 
> offer a mode where the Admin UI is disabled. Maybe, and this is a topic 
> that'll need some serious discussion, this should even be the default when 
> Solr starts.
> NOTE: Disabling the Admin UI removes XSS and other attack vectors. But even 
> with the Admin UI disabled, Solr will still be inherently unsafe without 
> firewall protection on a public network.
> *Proposed design:*
> A java system property called *headless* will be used as an internal flag for 
> starting Solr in headless mode. This property will default to true. A java 
> property can be used at startup to set this flag to false.
> Here is an example:
> {code:java}
>  bin/solr start -Dheadless=false {code}
> A message will be added following startup describing the mode.
> In headless mode the following message will be displayed:
> "solr is running in headless mode. The admin console is unavailable. To to 
> turn off headless mode and allow the admin console use the following 
> parameter startup parameter:
> -Dheadless=false 
>   
> In non-headless mode the following message will be displayed:
> "solr is running with headless mode turned off. The admin console is 
> available in this mode. Disabling the Admin UI removes XSS and other attack 
> vectors"  
> If a user attempts to access the admin console while Solr is in headless mode 
> it Solr will return 401 unauthorized.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (LUCENE-9077) Gradle build



 [ 
https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-9077:

Description: 
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * [dw] Port other settings and randomizations from common-build.xml
 * [dw] Configure security policy/ sandboxing for tests.
 * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid 
it'll be difficult to run it sensibly because gradle doesn't offer cwd 
separation for the forked test runners.
 * jar checksums, jar checksum computation and validation. This should be done 
without intermediate folders (directly on dependency sets).
 * add a :helpDeps explanation to how the dependency system works (palantir 
plugin, lockfile) and how to retrieve structured information about current 
dependencies of a given module (in a tree-like output).
 * if you diff solr packaged distribution against ant-created distribution 
there are minor differences in library versions and some JARs are excluded/ 
moved around. I didn't try to force these as everything seems to work (tests, 
etc.) – perhaps these differences should  be fixed in the ant build instead.
 * identify and list precommit tasks so that they can be ported one by one. 
(Mark's branch has some of this stuff already implemented)
 * identify and port any other "check" utilities that may be called from ant. 
(Mark's branch has some of this stuff already implemented)
 * [EOE] identify and port various "regenerate" tasks from ant builds (javacc, 
precompiled automata, etc.)
 * add rendering of javadocs (gradlew javadoc) and attaching them to maven 
publications.
 * fill in POM details in gradle/defaults-maven.gradle so that they reflect the 
previous content better (dependencies aside).
 * Add any IDE integration layers that should be added (I use IntelliJ and it 
imports the project out of the box, without the need for any special tuning).
 * *Clean up dependencies, especially for Solr*: any \{ transitive = false } 
should just explicitly exclude whatever they don't need (and their dependencies 
currently declared explicitly should be folded). Figure out which scope to 
import a dependency to.
 * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; currently 
XSLT...)
 * I didn't bother adding Solr dist/test-framework to packaging (who'd use it 
from a binary distribution? 
 * ant build uses 'tempDir' system property: this is only used in a few places 
and is really irrelevant (should be just a regular temporary directory).

 

*{color:#ff}Note:{color}* this builds on the work done by Mark Miller and 
Cao Mạnh Đạt but also applies lessons learned from those two efforts:
 * *Do not try to do too many things at once*. If we deviate too far from 
master, the branch will be hard to merge.
 * *Do everything in baby-steps* and add small, independent build fragments 
replacing the old ant infrastructure.
 * *Try to engage people to run, test and contribute early*. It can't be a 
one-man effort. The more people understand and can contribute to the build, the 
more healthy it will be.

 

  was:
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * [dw] Port other settings and randomizations from common-build.xml
 * [dw] Co

[jira] [Comment Edited] (SOLR-14014) Allow Solr to start with Admin UI disabled

[
https://issues.apache.org/jira/browse/SOLR-14014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989623#comment-16989623
]

Jan Høydahl edited comment on SOLR-14014 at 12/6/19 10:41 AM:
--

{quote}Having the convenience of the admin UI has led us to neglect our APIs.
{quote}
That's a simplification and no excuse for designing bad APIs, but I get your
point that you don't feel the pain of awkward APIs every day if you always just
use the UI. But it is anyway not an argument to remove the UI. Remember where
we came from with JSP and no APIs - the only way to do certain things was
through inline Java code in those JSPs (yuck!).

I support the idea of a way to disable Admin UI for those that do not use it
anyway. I think too that something like {{-DenableAdminUI=false}} is a better
value. Also there should be no reason to disable it by default. The presence of
the UI is no threat in itself, it is in the moment an Admin person loads it and
becomes victim of XSS, cliks a link etc that it can hurt the Solr server.

My proposal is thus to educate the user through the AdminUI itself by adding a
big fat INFO message on top of the dashboard that everyone will see on first
use of the UI. The message will be something like this:
{quote}
*IMPORTANT NOTICE*

This is the Solr Administrative interface. It is a HTML5 application running in
your browser. It talks to the Apache Solr server using HTTP calls, just as any
other client. The UI gives great power, and can open up new security threats
such as XSS attacks, if you as an administrator is not very careful when using
it. Please read our recommendations in the Reference Guide on what
precautions to take. The most important are:

* Require some form of authentication to Solr
* Use a separate web browser for Solr, do not load other web sites in other tabs
* Log out when you are done
* Keep up to date on CVE vulnerabilities and keep Solr updated

If you do not need the Admin UI, it can be disabled by starting Solr with the
System property {{-DenableAdminUI=false}}.

WARNING: Your Solr instance is not protected by Authentication.
WARNING: Your Solr instance does not use SSL.
WARNING: Your Solr instance allows config edit though REST API
WARNING: There is a newer version of Solr available, consider upgrading

[Learn more about securing Solr] [Dismiss. We'll set a cookie and not
show this again]{quote}

This would probably be a better channel to reach out to Admins than both the
Ref-guide, mailing list and the Web page combined :)

was (Author: janhoy):
{quote}Having the convenience of the admin UI has led us to neglect our APIs.
{quote}
That's a simplification and no excuse for designing bad APIs, but I get your
point that you don't feel the pain of awkward APIs every day if you always just
use the UI. But it is anyway not an argument to remove the UI. Remember where
we came from with JSP and no APIs - the only way to do certain things was
through inline Java code in those JSPs (yuck!).

My proposal is thus to educate the user through the AdminUI itself by adding a
big fat INFO message on top of the dashboard that everyone will see. The
message will be something like this:
{noformat}
IMPORTANT NOTICE

If you do not need the Admin UI, it can be disabled by starting Solr with the
System property -DenableAdminUI=false.

[Learn more about securing Solr] [Dismiss. We'll set a cookie and not
show this again]{noformat}
This would probably be a better channel to reach out to Admins than both the
Ref-guide, mailing list and the Web page combined :)

> Allo

[jira] [Commented] (SOLR-13985) bind to localhost by default



[ 
https://issues.apache.org/jira/browse/SOLR-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989630#comment-16989630
 ] 

Jan Høydahl commented on SOLR-13985:


[~uschindler] You almost had a patch ready to replace Jetty's start.jar with a 
solr.jar which moves all jetty xml configs into our own Java class instead. Is 
this a good time to pick it up again, would think that it would give us full 
control of what to bind to as well? I don't think it is as risky as it sounds 
like. We just do the Jetty init and servlet wirings from code instead of from 
xml. We already to this for our tests.

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13985) bind to localhost by default

2019-12-06 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989630#comment-16989630
 ] 

Jan Høydahl edited comment on SOLR-13985 at 12/6/19 10:54 AM:
--

[~uschindler] You almost had a patch ready to replace Jetty's start.jar with a 
solr.jar which moves all jetty xml configs into our own Java class instead. Is 
this a good time to pick it up again, would think that it would give us full 
control of what to bind to as well? I don't think it is as risky as it sounds 
like. We just do the Jetty init and servlet wirings from code instead of from 
xml. We already to this for our tests.
*EDIT*: Ok I just saw SOLR-13984 which is exactly about this


was (Author: janhoy):
[~uschindler] You almost had a patch ready to replace Jetty's start.jar with a 
solr.jar which moves all jetty xml configs into our own Java class instead. Is 
this a good time to pick it up again, would think that it would give us full 
control of what to bind to as well? I don't think it is as risky as it sounds 
like. We just do the Jetty init and servlet wirings from code instead of from 
xml. We already to this for our tests.

> bind to localhost by default
> 
>
> Key: SOLR-13985
> URL: https://issues.apache.org/jira/browse/SOLR-13985
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-13985.patch
>
>
> Currently solr binds to all interfaces by default. 
> The default should be safer, so that e.g. the user is not exposed to the 
> internet until they make an explicit step to do so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API



[ 
https://issues.apache.org/jira/browse/SOLR-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989645#comment-16989645
 ] 

ASF subversion and git services commented on SOLR-13990:


Commit 2387bb9d60ae44eeeb4fbcb2f2877f46be5303a0 in lucene-solr's branch 
refs/heads/gradle-master from Anshum Gupta
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2387bb9 ]

SOLR-13990: Switch out woodstox-core-asl with aalto-xml and upgrade woodstox 
stax-2 API (#1050)




> Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
> ---
>
> Key: SOLR-13990
> URL: https://issues.apache.org/jira/browse/SOLR-13990
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2 
> API. 
> About aalto-xml:
> Aalto XML processor is an ultra-high performance next generation Stax XML 
> processor implementation, implementing both basic Stax API 
> ({{javax.xml.stream}}) and Stax2 API extension 
> ({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13954) Embedded ZooKeeper in Solr fails to load JettyAdminServer

2019-12-06 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989648#comment-16989648
 ] 

ASF subversion and git services commented on SOLR-13954:


Commit 7417fa1cf3a7875b76419793a38080059f52b1fc in lucene-solr's branch 
refs/heads/gradle-master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7417fa1 ]

SOLR-13954: Embedded ZooKeeper in Solr now does not try to load 
JettyAdminServer (#1059)



> Embedded ZooKeeper in Solr fails to load JettyAdminServer
> -
>
> Key: SOLR-13954
> URL: https://issues.apache.org/jira/browse/SOLR-13954
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2, 8.3
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Minor
>  Labels: ZooKeeper
> Fix For: 8.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Running solr with the embedded zookeeper, e.g. when running _solr -e cloud_ 
> results in a ClassNotFoundException / NoClassDefFoundError in the log as 
> below. The server still functions correctly (except JettyAdminServer won't 
> work obviously), but it _looks_ like a problem, and isn't good for a first 
> time user to see
> {noformat}
> 2019-11-21 17:25:14.292 INFO  (main) [   ] o.a.s.c.SolrZkServer STARTING 
> EMBEDDED STANDALONE ZOOKEEPER SERVER at port 9983
> 2019-11-21 17:25:14.792 INFO  (main) [   ] o.a.s.c.ZkContainer Zookeeper 
> client=localhost:9983
> 2019-11-21
>  17:25:18.833 WARN  (Thread-13) [   ] o.a.z.s.a.AdminServerFactory 
> Unable to load jetty, not starting JettyAdminServer => 
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method)
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Connector
>   at java.lang.Class.forName0(Native Method) ~[?:1.8.0_191]
>   at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_191]
>   at 
> org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
>  ~[?:?]
>   at 
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:136)
>  ~[?:?]
>   at org.apache.solr.cloud.SolrZkServer$1.run(SolrZkServer.java:121) 
> ~[?:?]
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector
>   at 
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:577)
>  ~[jetty-webapp-9.4.19.v20190610.jar:9.4.19.v20190610]
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_191]
>   ... 5 more
> 2019-11-21 17:25:19.365 INFO  (main) [   ] o.a.s.c.c.ConnectionManager 
> Waiting for client to connect to ZooKeeper
> 2019-11-21 17:25:19.396 INFO  (zkConnectionManagerCallback-7-thread-1) [   ] 
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2019-11-21 17:25:19.396 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Client 
> is connected to ZooKeeper{noformat}
> Caused by: java.lang.ClassNotFoundException: 
> org.eclipse.jetty.server.Connector



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13831) Support defining arbitrary autoscaling simulation scenarios

2019-12-06 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989646#comment-16989646
 ] 

ASF subversion and git services commented on SOLR-13831:


Commit d2b01ef28f918e2f3575081c206203be49889501 in lucene-solr's branch 
refs/heads/gradle-master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d2b01ef ]

SOLR-13831: Context property _loop_iter_ should be a string in order to support
variable expansion.


> Support defining arbitrary autoscaling simulation scenarios
> ---
>
> Key: SOLR-13831
> URL: https://issues.apache.org/jira/browse/SOLR-13831
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-13831.patch, SOLR-13831.patch
>
>
> In many cases where the {{bin/solr autoscaling}} tool is used it would be 
> very useful to be able to specify a concrete scenario to play out, eg:
>  * load a snapshot (or create a simulated cluster of N nodes)
>  * calculate suggestions
>  * apply suggestions
>  * kill one or more nodes
>  * loop N times
>  * make some arbitrary SolrRequest-s
>  * save snapshot
>  * etc...
>  
> This could be expressed as a very simple DSL that can be loaded from a text 
> file, with the following format:
> {code:java}
> # comments
> // or comments
> create_cluster numNodes=5 // inline comment
> solr_request 
> /admin/collections?action=CREATE&name=testCollection&numShards=2&replicationFactor=2
> loop_start iterations=10
>   calculate_suggestions
>   apply_suggestions
> loop_end
> save_snapshot path=/foo{code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14020) move hadoop hacks out of lucene TestSecurityManager into a solr one

2019-12-06 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989647#comment-16989647
 ] 

ASF subversion and git services commented on SOLR-14020:


Commit 33ca971d2b5af1ee674752dd3fb76ce512299bb2 in lucene-solr's branch 
refs/heads/gradle-master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=33ca971 ]

SOLR-14020: move hadoop hacks out of lucene TestSecurityManager into a solr one


> move hadoop hacks out of lucene TestSecurityManager into a solr one
> ---
>
> Key: SOLR-14020
> URL: https://issues.apache.org/jira/browse/SOLR-14020
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-14020.patch
>
>
> The hadoop hacks here have a heavy toll: because we have to override some 
> methods like checkRead, it inserts non-jdk stack frame and breaks a lot of 
> JDK doPriv calls. So for example, it means permissions must be added to stuff 
> like /dev/random or windows fonts or all kinds of other nonsense.
> This is a price only solr should pay, not lucene. Lets split the stuff out.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-13979) Expose separate metrics for distributed and non-distributed requests

2019-12-06 Thread Andrzej Bialecki (Jira)



 [ 
https://issues.apache.org/jira/browse/SOLR-13979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki updated SOLR-13979:

Attachment: SOLR-13979.patch

> Expose separate metrics for distributed and non-distributed requests
> 
>
> Key: SOLR-13979
> URL: https://issues.apache.org/jira/browse/SOLR-13979
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0), 8.4
>
> Attachments: SOLR-13979.patch
>
>
> Currently we expose metrics such as count, rate and latency on a per handler 
> level however for search requests there is no distinction made for distrib vs 
> non-distrib requests. This means that there is no way to find the count, rate 
> or latency of only user-sent queries.
> I propose that we expose distrib vs non-distrib metrics separately.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13979) Expose separate metrics for distributed and non-distributed requests

2019-12-06 Thread Andrzej Bialecki (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989695#comment-16989695
 ] 

Andrzej Bialecki commented on SOLR-13979:
-

This patch adds a set of separate "requestTimes" and "totalTime" metrics for 
distributed and local requests, based on the value of {{distrib}} parameter 
(defaults to true when in ZK mode).
These metrics are added to all handlers that inherit from 
{{RequestHandlerBase}}. This may be probably a bit too many, we could've added 
it to {{SearchHandler}} only, but on the other hand there are other handlers 
where this info comes useful, it also ensures that these metrics are also 
available in other custom handlers that inherit from this class.

> Expose separate metrics for distributed and non-distributed requests
> 
>
> Key: SOLR-13979
> URL: https://issues.apache.org/jira/browse/SOLR-13979
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0), 8.4
>
> Attachments: SOLR-13979.patch
>
>
> Currently we expose metrics such as count, rate and latency on a per handler 
> level however for search requests there is no distinction made for distrib vs 
> non-distrib requests. This means that there is no way to find the count, rate 
> or latency of only user-sent queries.
> I propose that we expose distrib vs non-distrib metrics separately.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API



[ 
https://issues.apache.org/jira/browse/SOLR-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989705#comment-16989705
 ] 

Dawid Weiss edited comment on SOLR-13990 at 12/6/19 12:32 PM:
--

Hadoop requires woodstock. Tests don't pass.

ant test -Dtestcase=TestHdfsUpdateLog -Dtests.disableHdfs=false


was (Author: dweiss):
Hadoop requires woodstock. Tests don't pass.

> Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
> ---
>
> Key: SOLR-13990
> URL: https://issues.apache.org/jira/browse/SOLR-13990
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2 
> API. 
> About aalto-xml:
> Aalto XML processor is an ultra-high performance next generation Stax XML 
> processor implementation, implementing both basic Stax API 
> ({{javax.xml.stream}}) and Stax2 API extension 
> ({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API



[ 
https://issues.apache.org/jira/browse/SOLR-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989705#comment-16989705
 ] 

Dawid Weiss commented on SOLR-13990:


Hadoop requires woodstock. Tests don't pass.

> Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
> ---
>
> Key: SOLR-13990
> URL: https://issues.apache.org/jira/browse/SOLR-13990
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2 
> API. 
> About aalto-xml:
> Aalto XML processor is an ultra-high performance next generation Stax XML 
> processor implementation, implementing both basic Stax API 
> ({{javax.xml.stream}}) and Stax2 API extension 
> ({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (LUCENE-9077) Gradle build



 [ 
https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-9077:

Description: 
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * (/) Port other settings and randomizations from common-build.xml
 * [dw] Configure security policy/ sandboxing for tests.
 * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid 
it'll be difficult to run it sensibly because gradle doesn't offer cwd 
separation for the forked test runners.
 * jar checksums, jar checksum computation and validation. This should be done 
without intermediate folders (directly on dependency sets).
 * add a :helpDeps explanation to how the dependency system works (palantir 
plugin, lockfile) and how to retrieve structured information about current 
dependencies of a given module (in a tree-like output).
 * if you diff solr packaged distribution against ant-created distribution 
there are minor differences in library versions and some JARs are excluded/ 
moved around. I didn't try to force these as everything seems to work (tests, 
etc.) – perhaps these differences should  be fixed in the ant build instead.
 * identify and list precommit tasks so that they can be ported one by one. 
(Mark's branch has some of this stuff already implemented)
 * identify and port any other "check" utilities that may be called from ant. 
(Mark's branch has some of this stuff already implemented)
 * [EOE] identify and port various "regenerate" tasks from ant builds (javacc, 
precompiled automata, etc.)
 * add rendering of javadocs (gradlew javadoc) and attaching them to maven 
publications.
 * fill in POM details in gradle/defaults-maven.gradle so that they reflect the 
previous content better (dependencies aside).
 * Add any IDE integration layers that should be added (I use IntelliJ and it 
imports the project out of the box, without the need for any special tuning).
 * *Clean up dependencies, especially for Solr*: any \{ transitive = false } 
should just explicitly exclude whatever they don't need (and their dependencies 
currently declared explicitly should be folded). Figure out which scope to 
import a dependency to.
 * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; currently 
XSLT...)
 * I didn't bother adding Solr dist/test-framework to packaging (who'd use it 
from a binary distribution? 
 * ant build uses 'tempDir' system property: this is only used in a few places 
and is really irrelevant (should be just a regular temporary directory).

 

*{color:#ff}Note:{color}* this builds on the work done by Mark Miller and 
Cao Mạnh Đạt but also applies lessons learned from those two efforts:
 * *Do not try to do too many things at once*. If we deviate too far from 
master, the branch will be hard to merge.
 * *Do everything in baby-steps* and add small, independent build fragments 
replacing the old ant infrastructure.
 * *Try to engage people to run, test and contribute early*. It can't be a 
one-man effort. The more people understand and can contribute to the build, the 
more healthy it will be.

 

  was:
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * [dw] Port other settings and randomizations from common-build.xml
 * [dw] Con

[jira] [Updated] (LUCENE-9077) Gradle build



 [ 
https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-9077:

Description: 
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * (/) Port other settings and randomizations from common-build.xml
 * [dw] Configure security policy/ sandboxing for tests.
 * Full test's console output on failure?
 * jar checksums, jar checksum computation and validation. This should be done 
without intermediate folders (directly on dependency sets).
 * add a :helpDeps explanation to how the dependency system works (palantir 
plugin, lockfile) and how to retrieve structured information about current 
dependencies of a given module (in a tree-like output).
 * identify and list precommit tasks so that they can be ported one by one. 
(Mark's branch has some of this stuff already implemented)
 * 

Of lesser importance:
 * add rendering of javadocs (gradlew javadoc) and attaching them to maven 
publications.
 * Repro-line for failed tests/ runs.
 * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid 
it'll be difficult to run it sensibly because gradle doesn't offer cwd 
separation for the forked test runners.
 * if you diff solr packaged distribution against ant-created distribution 
there are minor differences in library versions and some JARs are excluded/ 
moved around. I didn't try to force these as everything seems to work (tests, 
etc.) – perhaps these differences should  be fixed in the ant build instead.
 * identify and port any other "check" utilities that may be called from ant. 
(Mark's branch has some of this stuff already implemented)
 * [EOE] identify and port various "regenerate" tasks from ant builds (javacc, 
precompiled automata, etc.)
 * fill in POM details in gradle/defaults-maven.gradle so that they reflect the 
previous content better (dependencies aside).
 * Add any IDE integration layers that should be added (I use IntelliJ and it 
imports the project out of the box, without the need for any special tuning).
 * *Clean up dependencies, especially for Solr*: any \{ transitive = false } 
should just explicitly exclude whatever they don't need (and their dependencies 
currently declared explicitly should be folded). Figure out which scope to 
import a dependency to.
 * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; currently 
XSLT...)
 * I didn't bother adding Solr dist/test-framework to packaging (who'd use it 
from a binary distribution? 

 

*{color:#ff}Note:{color}* this builds on the work done by Mark Miller and 
Cao Mạnh Đạt but also applies lessons learned from those two efforts:
 * *Do not try to do too many things at once*. If we deviate too far from 
master, the branch will be hard to merge.
 * *Do everything in baby-steps* and add small, independent build fragments 
replacing the old ant infrastructure.
 * *Try to engage people to run, test and contribute early*. It can't be a 
one-man effort. The more people understand and can contribute to the build, the 
more healthy it will be.

 

  was:
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * (/) Port other settings and randomizations from common-build.xml
 * [dw] Configure security policy/ sandboxing for tests.

[jira] [Commented] (SOLR-14021) Remove HDFS support from Solr



[ 
https://issues.apache.org/jira/browse/SOLR-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989726#comment-16989726
 ] 

Joel Bernstein commented on SOLR-14021:
---

There appears to be growing consensus among committers that it's time to start 
removing features so committers can have a manageable system to maintain. HDFS 
has come up a number of times as needing to be removed. The HDFS tests have not 
been maintained over years and fail frequently. We need to start removing 
features that no one cares about enough to even maintain the tests.

> Remove HDFS support from Solr
> -
>
> Key: SOLR-14021
> URL: https://issues.apache.org/jira/browse/SOLR-14021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove HDFS support from the Solr project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14024) Invalid html generated by changes2html.pl

2019-12-06 Thread Andras Salamon (Jira)

Andras Salamon created SOLR-14024:
-

 Summary: Invalid html generated by changes2html.pl
 Key: SOLR-14024
 URL: https://issues.apache.org/jira/browse/SOLR-14024
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andras Salamon


I've validated the Changes.html file generated by the 
[changes2html.pl|https://github.com/apache/lucene-solr/blob/master/lucene/site/changes/changes2html.pl]
 file, and https://validator.w3.org/ listed hundreds of errors. The script 
should validate a valid HTML.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] asalamon74 opened a new pull request #1060: SOLR-14024: Invalid html generated by changes2html.pl

asalamon74 opened a new pull request #1060: SOLR-14024: Invalid html generated 
by changes2html.pl
URL: https://github.com/apache/lucene-solr/pull/1060
 
 
   
   
   
   # Description
   
   changes2html.pl generates invalid html
   
   # Solution
   
   Fix it to generate a valid html.
   
   # Tests
   
   Created the html and tested it using https://validator.w3.org/
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [x] I am authorized to contribute this code to the ASF and have removed 
any code I do not have a license to distribute.
   - [x] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [x] I have developed this patch against the `master` branch.
   - [x] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1058: SOLR-13972: Warn about insecure settings on startup

gerlowskija commented on a change in pull request #1058: SOLR-13972: Warn about 
insecure settings on startup
URL: https://github.com/apache/lucene-solr/pull/1058#discussion_r354818496
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/CoreContainer.java
 ##
 @@ -897,6 +899,20 @@ private void reloadSecurityProperties() {
 initializeAuditloggerPlugin((Map) 
securityConfig.getData().get("auditlogging"));
   }
 
+  private void warnUsersIfSecurityDisabled() {
+if (authenticationPlugin == null || authorizationPlugin == null) {
+  log.warn("Not all security plugins configured!  authentication={} 
authorization={}.  Solr is only as secure as " +
+  "you make it. Consider configuring authentication/authorization 
before exposing Solr to users internal or " +
+  "external.  See 
https://lucene.apache.org/solr/guide/authentication-and-authorization-plugins.html
 for more info",
 
 Review comment:
   Sure.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14021) Remove HDFS support from Solr



[ 
https://issues.apache.org/jira/browse/SOLR-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989726#comment-16989726
 ] 

Joel Bernstein edited comment on SOLR-14021 at 12/6/19 1:00 PM:


There appears to be growing consensus among committers that it's time to start 
removing features so committers can have a manageable system to maintain. HDFS 
has come up a number of times as needing to be removed. The HDFS tests have not 
been maintained over the years and fail frequently. We need to start removing 
features that no one cares about enough to even maintain the tests.


was (Author: joel.bernstein):
There appears to be growing consensus among committers that it's time to start 
removing features so committers can have a manageable system to maintain. HDFS 
has come up a number of times as needing to be removed. The HDFS tests have not 
been maintained over years and fail frequently. We need to start removing 
features that no one cares about enough to even maintain the tests.

> Remove HDFS support from Solr
> -
>
> Key: SOLR-14021
> URL: https://issues.apache.org/jira/browse/SOLR-14021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove HDFS support from the Solr project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija edited a comment on issue #1058: SOLR-13972: Warn about insecure settings on startup

gerlowskija edited a comment on issue #1058: SOLR-13972: Warn about insecure 
settings on startup
URL: https://github.com/apache/lucene-solr/pull/1058#issuecomment-562564527
 
 
   > I hoped we had a way to only log such warning if Solr is bound to a public 
network.
   
   I'd rather keep that sort of logic out of it.  I can imagine situations 
where Solr is nominally bound to "localhost", but is actually exposed more 
broadly because of traffic forwarding, iptables rules, etc.
   
   (I'm not the strongest network guy - if someone wants to argue with me that 
this isn't possible and we can always rely that localhost-binding == 
no-need-for-auth I'm happy to be corrected.)


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on issue #1058: SOLR-13972: Warn about insecure settings on startup

gerlowskija commented on issue #1058: SOLR-13972: Warn about insecure settings 
on startup
URL: https://github.com/apache/lucene-solr/pull/1058#issuecomment-562564527
 
 
   > I hoped we had a way to only log such warning if Solr is bound to a public 
network.
   I'd rather keep that sort of logic out of it.  I can imagine situations 
where Solr is nominally bound to "localhost", but is actually exposed more 
broadly because of traffic forwarding, iptables rules, etc.
   
   (I'm not the strongest network guy - if someone wants to argue with me that 
this isn't possible and we can always rely that localhost-binding == 
no-need-for-auth I'm happy to be corrected.)


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14021) Remove HDFS support from Solr



[ 
https://issues.apache.org/jira/browse/SOLR-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989742#comment-16989742
 ] 

Joel Bernstein commented on SOLR-14021:
---

I think anything that either is associated with a failing test or has no test 
should be removed. If there are parts of HDFS support that have working tests 
and there is consensus about letting them remain, then it makes sense to keep 
those parts.

> Remove HDFS support from Solr
> -
>
> Key: SOLR-14021
> URL: https://issues.apache.org/jira/browse/SOLR-14021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove HDFS support from the Solr project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14021) Remove HDFS support from Solr



 [ 
https://issues.apache.org/jira/browse/SOLR-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-14021:
--
Description: 
This ticket will remove HDFS support from the Solr project.

There appears to be growing consensus among committers that it's time to start 
removing features so committers can have a manageable system to maintain. HDFS 
has come up a number of times as needing to be removed. The HDFS tests have not 
been maintained over the years and fail frequently. We need to start removing 
features that no one cares about enough to even maintain the tests.

  was:This ticket will remove HDFS support from the Solr project.


> Remove HDFS support from Solr
> -
>
> Key: SOLR-14021
> URL: https://issues.apache.org/jira/browse/SOLR-14021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove HDFS support from the Solr project.
> There appears to be growing consensus among committers that it's time to 
> start removing features so committers can have a manageable system to 
> maintain. HDFS has come up a number of times as needing to be removed. The 
> HDFS tests have not been maintained over the years and fail frequently. We 
> need to start removing features that no one cares about enough to even 
> maintain the tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Issue Comment Deleted] (SOLR-14021) Remove HDFS support from Solr



 [ 
https://issues.apache.org/jira/browse/SOLR-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-14021:
--
Comment: was deleted

(was: There appears to be growing consensus among committers that it's time to 
start removing features so committers can have a manageable system to maintain. 
HDFS has come up a number of times as needing to be removed. The HDFS tests 
have not been maintained over the years and fail frequently. We need to start 
removing features that no one cares about enough to even maintain the tests.)

> Remove HDFS support from Solr
> -
>
> Key: SOLR-14021
> URL: https://issues.apache.org/jira/browse/SOLR-14021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove HDFS support from the Solr project.
> There appears to be growing consensus among committers that it's time to 
> start removing features so committers can have a manageable system to 
> maintain. HDFS has come up a number of times as needing to be removed. The 
> HDFS tests have not been maintained over the years and fail frequently. We 
> need to start removing features that no one cares about enough to even 
> maintain the tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14021) Remove HDFS support from Solr



[ 
https://issues.apache.org/jira/browse/SOLR-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989753#comment-16989753
 ] 

Erick Erickson commented on SOLR-14021:
---

For backups etc., maybe this Jira might be relevant? It looks like a major 
effort though.

> Remove HDFS support from Solr
> -
>
> Key: SOLR-14021
> URL: https://issues.apache.org/jira/browse/SOLR-14021
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Joel Bernstein
>Priority: Major
>
> This ticket will remove HDFS support from the Solr project.
> There appears to be growing consensus among committers that it's time to 
> start removing features so committers can have a manageable system to 
> maintain. HDFS has come up a number of times as needing to be removed. The 
> HDFS tests have not been maintained over the years and fail frequently. We 
> need to start removing features that no one cares about enough to even 
> maintain the tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14014) Allow Solr to start with Admin UI disabled



[ 
https://issues.apache.org/jira/browse/SOLR-14014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989758#comment-16989758
 ] 

Jason Gerlowski commented on SOLR-14014:


bq. I don't like it; I liken it to removing useful features just because of the 
possibility of bugs.

I don't think that comparison is accurate.  The proposal here isn't to rip out 
the Admin UI, it's just to add a feature flag for it.  No one's suggesting 
removing features.  We should 100% fix the problems we know about in the Admin 
UI, and this shouldn't replace that work.  I'd like to think that work will 
prevent all future UI vulnerabilities but we've been wrong so many times 
recently that it seems prudent to give our users a safety net just in case.

Other thoughts.

1. Don't feel strongly about the name.  +1 to {{enableAdminUI}} if people like 
that.
2. I don't feel strongly about whether the UI is enabled/disabled by default. A 
smarter option (maybe?) would be to have this ticket set the default to 
"disabled" and make changing the default back to "enabled" be a part of 
SOLR-13987.  That way the UI being enabled (by default) would be contingent on 
fixing the XSS exploit paths.  But again, I think the important thing is 
getting a feature flag in, I think the default is secondary.

> Allow Solr to start with Admin UI disabled
> --
>
> Key: SOLR-14014
> URL: https://issues.apache.org/jira/browse/SOLR-14014
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, security
>Affects Versions: master (9.0), 8.3.1
>Reporter: Jason Gerlowski
>Priority: Major
>
> Currently Solr always runs the Admin UI. With the history of XSS issues and 
> other security concerns that have been found in the Admin UI, Solr should 
> offer a mode where the Admin UI is disabled. Maybe, and this is a topic 
> that'll need some serious discussion, this should even be the default when 
> Solr starts.
> NOTE: Disabling the Admin UI removes XSS and other attack vectors. But even 
> with the Admin UI disabled, Solr will still be inherently unsafe without 
> firewall protection on a public network.
> *Proposed design:*
> A java system property called *headless* will be used as an internal flag for 
> starting Solr in headless mode. This property will default to true. A java 
> property can be used at startup to set this flag to false.
> Here is an example:
> {code:java}
>  bin/solr start -Dheadless=false {code}
> A message will be added following startup describing the mode.
> In headless mode the following message will be displayed:
> "solr is running in headless mode. The admin console is unavailable. To to 
> turn off headless mode and allow the admin console use the following 
> parameter startup parameter:
> -Dheadless=false 
>   
> In non-headless mode the following message will be displayed:
> "solr is running with headless mode turned off. The admin console is 
> available in this mode. Disabling the Admin UI removes XSS and other attack 
> vectors"  
> If a user attempts to access the admin console while Solr is in headless mode 
> it Solr will return 401 unauthorized.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14014) Allow Solr to start with Admin UI disabled



[ 
https://issues.apache.org/jira/browse/SOLR-14014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989758#comment-16989758
 ] 

Jason Gerlowski edited comment on SOLR-14014 at 12/6/19 1:35 PM:
-

bq. I don't like it; I liken it to removing useful features just because of the 
possibility of bugs.

I don't think that comparison is accurate.  The proposal here isn't to rip out 
the Admin UI, it's just to add a feature flag for it.  No one's suggesting 
removing features.  We should 100% fix the problems we know about in the Admin 
UI, and this shouldn't replace that work.  I'd like to think that work will 
prevent all future UI vulnerabilities but we've been wrong so many times 
recently that it seems prudent to give our users a safety net just in case.

Other thoughts.

1. Don't feel strongly about the name.  +1 to {{enableAdminUI}} if people like 
that.
2. I don't feel strongly about whether the UI is enabled/disabled by default. A 
smarter option (maybe?) would be to have this ticket set the default to 
"disabled" and make changing the default back to "enabled" be a part of 
SOLR-13987.  That way the UI being enabled (by default) would be contingent on 
fixing the XSS exploit paths.  But again, I think the important thing is 
getting a feature flag in, I think the default is secondary.
3. +1 to Jan's warnings and documentation suggestions.


was (Author: gerlowskija):
bq. I don't like it; I liken it to removing useful features just because of the 
possibility of bugs.

I don't think that comparison is accurate.  The proposal here isn't to rip out 
the Admin UI, it's just to add a feature flag for it.  No one's suggesting 
removing features.  We should 100% fix the problems we know about in the Admin 
UI, and this shouldn't replace that work.  I'd like to think that work will 
prevent all future UI vulnerabilities but we've been wrong so many times 
recently that it seems prudent to give our users a safety net just in case.

Other thoughts.

1. Don't feel strongly about the name.  +1 to {{enableAdminUI}} if people like 
that.
2. I don't feel strongly about whether the UI is enabled/disabled by default. A 
smarter option (maybe?) would be to have this ticket set the default to 
"disabled" and make changing the default back to "enabled" be a part of 
SOLR-13987.  That way the UI being enabled (by default) would be contingent on 
fixing the XSS exploit paths.  But again, I think the important thing is 
getting a feature flag in, I think the default is secondary.

> Allow Solr to start with Admin UI disabled
> --
>
> Key: SOLR-14014
> URL: https://issues.apache.org/jira/browse/SOLR-14014
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, security
>Affects Versions: master (9.0), 8.3.1
>Reporter: Jason Gerlowski
>Priority: Major
>
> Currently Solr always runs the Admin UI. With the history of XSS issues and 
> other security concerns that have been found in the Admin UI, Solr should 
> offer a mode where the Admin UI is disabled. Maybe, and this is a topic 
> that'll need some serious discussion, this should even be the default when 
> Solr starts.
> NOTE: Disabling the Admin UI removes XSS and other attack vectors. But even 
> with the Admin UI disabled, Solr will still be inherently unsafe without 
> firewall protection on a public network.
> *Proposed design:*
> A java system property called *headless* will be used as an internal flag for 
> starting Solr in headless mode. This property will default to true. A java 
> property can be used at startup to set this flag to false.
> Here is an example:
> {code:java}
>  bin/solr start -Dheadless=false {code}
> A message will be added following startup describing the mode.
> In headless mode the following message will be displayed:
> "solr is running in headless mode. The admin console is unavailable. To to 
> turn off headless mode and allow the admin console use the following 
> parameter startup parameter:
> -Dheadless=false 
>   
> In non-headless mode the following message will be displayed:
> "solr is running with headless mode turned off. The admin console is 
> available in this mode. Disabling the Admin UI removes XSS and other attack 
> vectors"  
> If a user attempts to access the admin console while Solr is in headless mode 
> it Solr will return 401 unauthorized.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14026) Upgrade Jetty to 9.4.24.v20191120

Erick Erickson created SOLR-14026:
-

 Summary: Upgrade Jetty to 9.4.24.v20191120
 Key: SOLR-14026
 URL: https://issues.apache.org/jira/browse/SOLR-14026
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Assignee: Erick Erickson


Prompted by the linked JIRA.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error



[ 
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989762#comment-16989762
 ] 

Erick Erickson commented on SOLR-13974:
---

We should make the Jetty upgrade its own Jira for tracking purposes.

> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during 
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
>  at 
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
>  at 
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) 
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) 
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) 
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>  at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at org.eclipse.jetty.server.Server.handle(Server.java:505) at 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at 
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>  at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>  at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>  at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>  at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(

[jira] [Commented] (SOLR-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error



[ 
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989764#comment-16989764
 ] 

Erick Erickson commented on SOLR-13974:
---

This'll be awkward to test. [~jaceq] If we upgraded jetty, would you be 
able/willing to test before we release the next version of Solr?

> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during 
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
>  at 
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
>  at 
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) 
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) 
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) 
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>  at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>  at org.eclipse.jetty.server.Server.handle(Server.java:505) at 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at 
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>  at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>  at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>  at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>  at 
> org

[jira] [Created] (SOLR-14027) Zookeeper Status Page does not work with SSL Enabled Zookeeper

2019-12-06 Thread Ryan Rockenbaugh (Jira)

Ryan Rockenbaugh created SOLR-14027:
---

 Summary: Zookeeper Status Page does not work with SSL Enabled 
Zookeeper
 Key: SOLR-14027
 URL: https://issues.apache.org/jira/browse/SOLR-14027
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Affects Versions: 8.3.1, 8.3, 8.2
Reporter: Ryan Rockenbaugh


In class org.apache.solr.handler.admin.ZookeeperStatusHandler, method 
getZkRawResponse uses a standard java.net.Socket to communicate with Zookeeper 
and get the status.  This does not work for SSL-Enabled zookeeper communication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on issue #1015: SOLR-13936 : expose endpoint to support changing schema without collection

gerlowskija commented on issue #1015: SOLR-13936 : expose endpoint to support 
changing schema without collection
URL: https://github.com/apache/lucene-solr/pull/1015#issuecomment-562586282
 
 
   > Current apis do not allow modifying a configset if it is not associated 
with a collection/core
   For cases where a configset is created, modified and then used this is 
necessary
   
   If you're uploading and modifying the configset before it's ever used, why 
wouldn't you just make your edits locally before uploading the configset?  Is 
there a particular use-case I'm missing here?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on issue #1015: SOLR-13936 : expose endpoint to support changing schema without collection

gerlowskija commented on issue #1015: SOLR-13936 : expose endpoint to support 
changing schema without collection
URL: https://github.com/apache/lucene-solr/pull/1015#issuecomment-562591284
 
 
   Two other comments/concerns:
   
   1. This PR adds a new API for modifying configsets, but AFAICT it doesn't 
deprecate the old configset API.  We aren't going to want to maintain two APIs 
going forward, are we?  If we really want/need this new API we should deprecate 
the old one.
   2. There's no documentation for the new API at all.  This should be covered 
_somewhere_ in the ref guide.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13936) Schema/Config endpoints to modify configset with no core/collection



[ 
https://issues.apache.org/jira/browse/SOLR-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989818#comment-16989818
 ] 

Jason Gerlowski commented on SOLR-13936:


I put a similar comment on your PR, but I'm not sure I see the use case for 
this API.  If you want the ability to upload a config and then modify it before 
it's ever used, couldn't you just do the edits locally and upload the configset 
the way you actually intend to use it?

I'm not against the new API necessarily. I just wonder whether it's worth the 
increased API surface area without a clear use case.

> Schema/Config endpoints to modify configset with no core/collection
> ---
>
> Key: SOLR-13936
> URL: https://issues.apache.org/jira/browse/SOLR-13936
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: config-api
>Reporter: Apoorv Bhawsar
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> All schema/config configurations should work even in cases where a collection 
> is not associated with them
>  This jira will involve
>  1. Refactoring existing handler/manager to work without {{SolrCore}}
>  2. Adding {{/api/cluster}} endpoints to support such modifications
>  Endpoints -
>  * {{/api/cluster/configset/\{name}/schema}}
>  * {{/ap/cluster/configset/\{name}/config}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13936) Schema/Config endpoints to modify configset with no core/collection



[ 
https://issues.apache.org/jira/browse/SOLR-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989818#comment-16989818
 ] 

Jason Gerlowski edited comment on SOLR-13936 at 12/6/19 2:32 PM:
-

I put a similar comment on your PR, but I'm not sure I see the use case for 
this API.  If you want the ability to upload a config and then modify it before 
it's ever used, couldn't you just do the edits locally and upload the configset 
the way you actually intend to use it?

I'm not against the new API necessarily. I just wonder whether it's worth the 
increased API surface area since I don't understand the use case yet.


was (Author: gerlowskija):
I put a similar comment on your PR, but I'm not sure I see the use case for 
this API.  If you want the ability to upload a config and then modify it before 
it's ever used, couldn't you just do the edits locally and upload the configset 
the way you actually intend to use it?

I'm not against the new API necessarily. I just wonder whether it's worth the 
increased API surface area without a clear use case.

> Schema/Config endpoints to modify configset with no core/collection
> ---
>
> Key: SOLR-13936
> URL: https://issues.apache.org/jira/browse/SOLR-13936
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: config-api
>Reporter: Apoorv Bhawsar
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> All schema/config configurations should work even in cases where a collection 
> is not associated with them
>  This jira will involve
>  1. Refactoring existing handler/manager to work without {{SolrCore}}
>  2. Adding {{/api/cluster}} endpoints to support such modifications
>  Endpoints -
>  * {{/api/cluster/configset/\{name}/schema}}
>  * {{/ap/cluster/configset/\{name}/config}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13942) /api/cluster/zk/* to fetch raw ZK data



[ 
https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989832#comment-16989832
 ] 

Jason Gerlowski commented on SOLR-13942:


I echo some of Anshum and Jan's concerns here.  Good ZooKeeper clients abound.  
We ship one in the current Solr distribution, and we provide support for some 
ZK commands in {{bin/solr}} itself.  I don't see the use case to add API 
surface area to provide yet-another way to access ZooKeeper.  ZooKeeper access 
is only intended for administrators, and there are plenty of other tools that 
allow them to do that just fine right now.

> /api/cluster/zk/* to fetch raw ZK data
> --
>
> Key: SOLR-13942
> URL: https://issues.apache.org/jira/browse/SOLR-13942
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> If the requested path is a node with children show the list of child nodes 
> and their meta data



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13942) /api/cluster/zk/* to fetch raw ZK data