> 14. sep. 2016 kl. 01.42 skrev Aaron Greenspan <aaron.greens...@plainsite.org>:
First of all, thanks for spending some time to give feedback and opening JIRAs (even if some get closed because it is a question, not a bug report). This list is exactly the right forum to bring up frustrations newbie users might have with Solr, and I think we should LISTEN carefully and identify low hanging fruits, as Alexandre is also focusing on! > I’m aware that issues with Java are not Solr’s fault. But most programs still > manage to gracefully fail when they are missing a dependency, and then > clearly report what’s missing. If you’re not actually a Java programmer, > which I am not, "major.minor 52.0" (for example) is meaningless gibberish. > "Please download and install JRE 1.8 to run this software" would be > considerably clearer. How is it that Solr can search through millions of > files, but it can’t do that? I agree that it would help big time if bin/solr would validate correct Java version. Found https://issues.apache.org/jira/browse/SOLR-8080 <https://issues.apache.org/jira/browse/SOLR-8080> for this, will try to cook up something :) Also, over in https://issues.apache.org/jira/browse/SOLR-9508 <https://issues.apache.org/jira/browse/SOLR-9508> I added a check for Java, so it will prompt you to install Java before you can install Solr. Should perhaps check for min-version here as well. > 1. I did. The documentation is severely lacking, apparently having been > written by project contributors who have vastly different goals than their > users. Yea, the ref-guide is a huge beast and aims to list every single setting. Then we have the tutorials that aim to walk new users through installing, indexing and searching. But they don’t cover upgrading etc of course. Then of course you have all the books - which is perhaps the best option right now to get quickly up to speed.. If you could decide, what kind of documentation would you want from the project? A very short “Solr Quick start guide”? with step-by-step instructions for the most common tasks from a User perspective? > Note the red section at the bottom (which originally wasn’t even there): "No > Solr API, including the Admin UI, is designed to be exposed to non-trusted > parties. Tune your firewall so that only trusted computers and people are > allowed access." If one of my employees tried to pull this I would fire them. > Admin UIs in every other product I’ve ever seen are password-protected. > Always. Netscape Enterprise Server in 1996 had a password for its admin UI. The warning is an honest way to tell admins that Solr is not designed to be an internet-facing program, like httpd or nginx. That is not to say that you cannot secure Solr pretty well with what we already got, but there will probably be a bunch of security holes since an internet-facing service is not the goal of Solr. It is not either an excuse for not having a password protection that is easier to understand. Still, the truth is that you CAN add authentication to all of Solr, including the UI. What is confusing though, is that the static (non-sensitive) parts of the UI will load and display, but as soon as the UI attempts to request any kind of information from the Solr APIs, it will fail. In my opinion this is perceived by our users as the Admin UI being insecure, and even if technically not true, we should continue work on https://issues.apache.org/jira/browse/SOLR-7896 <https://issues.apache.org/jira/browse/SOLR-7896> (Add a login page for Solr Administrative Interface). > 2. I have filed several reports on JIRA. Here’s the kind of response I have > received in the past: Again, thanks for contributing all of this, without users who care and suggest stuff there would be no progress… And I apologise if we as a community have not been understanding or had a welcoming attitude to the suggestions. > https://issues.apache.org/jira/browse/SOLR-7896?focusedCommentId=14661324&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14661324 Security is a special case I would say, since the project had an “official” attitude that we’d not add any kind of security whatsoever, to not mislead people into exposing Solr publicly. But then things changed in 5.2 and all the new security stuff got no vetoes anymore, and we’re now in a pretty good position on the API level of security. Wrt SOLR-7896, I re-opened that one after it got prematurely closed. But apparently not enough users have felt the need for it for someone to invest the time or money it takes to implement it. And that’s how open source works, as I’m sure you know. > Lastly, I run a non-profit foundation devoted to transparency, and I think > Solr could do a lot to help further my foundation's goals. That’s why I’m > using it at all. It’s the kind of project I’d be willing to fund (since I > don’t think I can write the code myself in this instance)—except that very > few people working on Solr ever take my concerns seriously (even though users > seem to). If funding is the reason (or even a reason) that Solr isn’t in a > better state, the way users are treated might be part of the problem. In Apache, you cannot really pay (or bribe) for getting a feature committed per se. But you are free to contact myself or other another committer that also work as a consultant, with a request to prioritise a certain feature. Note that there would be no guarantee that the hours you pay for would ever get committed; All development in Solr happens in the open, in a consensus-driven fashion, see http://theapacheway.com/community <http://theapacheway.com/community> -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com
