On 6/4/2013 11:48 PM, Aaron Greenspan wrote: > I thought I'd document my process of getting set up with Solr 4.3.0 on a > Linux server in case it's of use to anyone. I'm a moderately experienced > Linux system administrator, so without passing judgment (at least for now), > let me just say that I found getting Solr to work to be extremely > difficult--more difficult than just about any other package I've ever dealt > with, including ones I've built from source.
Thank you for your feedback. Solr has always had a high learning curve, and you've pointed out a lot of places we can improve things. We have a number of Jira issues that specifically deal with something called "Developer Curb Appeal." I think it's pretty clear that we need to tackle a bunch of things we could call "Newcomer Curb Appeal." I can work on filing some issues, some of which will address code, some of which will address the docs included with Solr and the wiki pages referenced there. I realize that the software is at version 4.3, but the UI isn't - it is brand new. The old UI in 3.x and earlier versions was a place to go for information, but you couldn't actually DO anything that would make changes. Historically, this is the reason for the admin UI - making test queries, watching statistics, and gathering information. The ability to make changes is very recent. The UI you've seen first appeared in 4.0.0, released last October. It was a complete rewrite in an entirely new language. The old one was JSP, the new one is javascript. On requiring a username/password: Solr doesn't include any security mechanisms. We leave that to other software written by people who do security really well. It can be handled by the servlet container, or a proxy. Solr should not be directly reachable by users. The intended usage is to have your website process user-entered text to turn it into a query and make sure it's clean before sending it to your Solr server(s), which should be only reachable from behind the firewall. Even if you use the servlet container's security features to really lock things down - block access to the admin UI, the update handler, and anything else that might get you into trouble, if someone can get directly to the query interface, it's relatively easy to send denial of service queries. Most attempts to detect and block DoS would also block legitimate queries that just happen to be slow. Solr is a java servlet. Servlet containers have historically used XML config files, so as a natural consequence, Solr uses XML config files. XML does allow for very precise and multi-layered configurations, but it can be very confusing. Version 4.4 will take the first tentative steps towards moving away from XML. The central config is still XML, but the individual cores won't be: http://wiki.apache.org/solr/Core%20Discovery%20%284.4%20and%20beyond%29 http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond There is only one specific problem that I will attempt to address in this reply. At this point, any advice I might give is probably too little too late. If I'm wrong and you do want some additional specific help, let me know. When you duplicate collection1 to make a new core, it is enough to simply duplicate the main directory and the conf subdirectory. I am aware as I write this that there is probably no documentation that states this clearly. Thanks, Shawn
