Using Localhost with SOLR

According to the SolrPlugin docs,

By default Solr listens to port 8983 on the localhost and is configured to only allow connections from localhost for security reasons.

That's not useful in my situation, where I need to be able to access the wiki from other hosts by URL as wiki.cfcl.com.

I tried changing solr/etc/jetty.xml as follows:

    <Call name="addConnector">
      <Arg>
          <New class="org.mortbay.jetty.nio.SelectChannelConnector">
            <Set name="host">wiki.cfcl.com</Set>
            <Set name="port"><SystemProperty name="jetty.port" default="8983"/></Set>
            <Set name="maxIdleTime">30000</Set>
            <Set name="Acceptors">2</Set>
            <Set name="confidentialPort">8443</Set>
          </New>
      </Arg>
    </Call>

and modified the configuration variables to set

{SolrPlugin}{Url}   http://wiki.cfcl.com:8983/solr

If I access http://wiki.cfcl.com:8983/solr/ directly, I see "Welcome to Solr!".

If I click the "Solr Admin" link, it takes me to http://wiki.cfcl.com:8983/solr/admin/ which gives a 404 Error:

HTTP ERROR: 404

missing core name in path
RequestURI=/solr/admin/index.jsp

and I still see can't connect to solr server at SolrSearch.

Apparently there's some small piece I'm missing that connects all of this together.

-- VickiBrown - 15 Jul 2012

The docs suggest that the default core is foswiki and say

Test if your new core is available by accessing the admin console.
http://<server-name>:<port>/solr/<core-name>/admin

but http://wiki.cfcl.com:8983/solr/foswiki/admin also throws a 404 error

NOT_FOUND
RequestURI=/solr/foswiki/admin

-- VickiBrown - 16 Jul 2012

Hello Vicki, Solr configuration can be a pain. Regarding the initial statement about localhost vs FQDN, that's a server-to-server (Foswiki-to-Solr) thing, if you're running solr on the same machine as Foswiki then the localhost restriction should be fine.

Solr doesn't have any per-record ACL features of its own, so anybody who can access the solr server can also access all of the cached Foswiki content. So if you allow connections to solr unrestricted, you risk exposing your access-controlled documents via Solr's cache of the Foswiki data.

For debugging from a remote PC (so I can talk to the solr server without tripping up the localhost restriction) I normally use SSH port-forwarding using something like

ssh -L8443:localhost:8443 user@my.solr.server.org

and then I can access http://localhost:8443 on my local PC which actually forwards the connections so that solr sees my connections coming from the server itself, rather than my PC (sorry if you already know about SSH forwarding!)

I wrote up my recipe for securing with tomcat, because our organization has a lot of in-house tomcat knowledge whereas jetty isn't as well known: BestPracticeTip23

Regarding NOT_FOUND errors - I'm not sure how to progress that under jetty. With tomcat, /solr/admin/ works for me. Sorry I'm not able to be more helpful at this time, one of us SolrPlugin users should really sit down and document a step-by-step installation using a vanilla Foswiki 1.1.5 installation

-- PaulHarvey - 19 Jul 2012

I'm running solr on the same machine as Foswiki but accessing both from another machine. And that access isn't possible if the URL is "...localhost...". The URL needs to be wiki.cfcl.com.

> if you allow connections to solr unrestricted, you risk exposing your access-controlled documents via Solr's cache of the Foswiki data.

I'm afraid I have no idea what that means. I need to be able to access this from another machine on the net. If that's not possible, SOLR is not usable.

Unfortunately, I don't understand anything else you wrote. I don't do Java. (Both tomcat and jetty are foreign terms). I have a client that wants to be able to search through MS Word documentes attached to Foswiki. They will never be sitting at the keyboard in front of the Linux server that hosts Foswiki. They know nothing about SSH forwarding and don't want to know. They only want to be able to search within Foswiki and have some MS Word docs returned.

-- VickiBrown - 24 Jul 2012

OK. To simplify things I've set the configuration variables back to the default (localhost). The issues are the same.

I'll open a different question.

-- VickiBrown - 24 Jul 2012