Install Solr 4.6 with Tomcat 7 on Debian 7


This article is either wrong or out of date. Do not use the instructions here! Refer to this wiki instead:

Solr with Apache Tomcat – Solr Wiki

The article is left as-is for posterity.

The following tutorial will explain the setup procedures for installing Solr 4.6 with Tomcat 7 on Debian 7 with Authentication enabled. The instructions should also work for other versions of Solr / Tomcat / Debian and other GNU/Linux environments if the appropriate commands are used.

Additionally, the authentication will allow for using the Solr admin web page remotely without having it publicly accessible.

Installing Java

First off, Java Needs to be installed so that Tomcat and Solr can run. Because Tomcat is a server app, GUI dependencies for Java are not needed, so installing the headless JRE will do.

# apt-get install openjdk-7-jre-headless

Note: Since Debian supports automatic dependency resolution, installing Tomcat 7 directly and having Debian decide how to install Java will result in the system using Java 6 instead of Java 7 for compatibility reasons. However, Java 7 will enable the addition of WebSockets in Tomcat 7, better concurrency, the client/server compiler for faster long-term running applications like Web apps, and a better garbage collector1.

Installing Tomcat

The following command will install Tomcat server, the Tomcat Web Application Manager and the Tomcat Virtual Host Manager so that the proper installation of Solr can be verified later via a nice web page.

# apt-get install tomcat7 tomcat7-admin

Now that Tomcat has been installed, the server should show a welcome page at http://localhost:8080/, assuming Tomcat is running on the same machine. For remote VMs, replace “localhost” with the server IP or domain.

If the page doesn’t load, make sure Tomcat is running:

# service tomcat7 start

Configuring Tomcat manager webapps authentication

The tomcat7-admin package ships with two Tomcat webapps, the Web Application Manager, and the Virtual Host Manager. However, by default, for security reasons, none of them are accessible. Tomcat’s authentication needs to be enabled in order to access these tools.

First, open the tomcat-users.xml configuration file for editing:

# nano /etc/tomcat7/tomcat-users.xml

Before the closing </tomcat-users> element, add the following lines of XML to provide access to both webapps to a single user as identified by the username and password attributes:

<role rolename="manager-gui"/>
<role rolename="admin-gui"/>
<user username="your_username" password="your_password" roles="manager-gui,admin-gui"/>

Save the file and restart the Tomcat server for the configuration changes to take effect.

# service tomcat7 restart

The manager webapps should now be accessible behind the login prompt at http://localhost:8080/manager/html and http://localhost:8080/host-manager/html.

Tomcat Manager

Installing Solr

Download and extract the Solr 4.6.1 tarball:

# curl | tar xz

Note: Navigate to the following address for faster mirrors:

Next, the Solr example app that comes bundled with the tarball will be set up. To do that, required libraries must be placed into Tomcat’s classpath. On Debian, simply copy the JARs from ~/solr-4.6.1/example/lib/ext to /usr/share/tomcat7/lib.

# cp ~/solr-4.6.1/example/lib/ext/* /usr/share/tomcat7/lib/

Note: Tomcat’s classpath directory contains symlinks to the actual JARs in the /usr/share/java classpath folder. The same can be done if desired, but it doesn’t matter in practice. The apparent structure is only an illusion and the symlinks follow a variety of logics for a variety of reasons. Since Tomcat loads libraries regardless of the filename, copying the JARs directly will do. The JARs can always be updated later by simply copying newer versions and removing the old ones in the same folder.

Next, Solr’s WAR file has to be placed inside Tomcat’s webapps directory so that Tomcat can deploy the Solr app.

# cp ~/solr-4.6.1/dist/solr-4.6.1.war /var/lib/tomcat7/webapps/solr.war

Note that by default, Tomcat deploys WAR files to folders with the same name, so once the app is running, the folder /var/lib/tomcat7/webapps/solr should have been created and the server will run from there.

The final step involves copying the example app’s support files to Tomcat’s Catalina base folder: /var/lib/tomcat7 and updating the folder permissions to give ownership to the Tomcat server.

# cp -R ~/solr-4.6.1/example/solr /var/lib/tomcat7
# chown -R tomcat7:tomcat7 /var/lib/tomcat7/solr

Catalina is Tomcat’s servlet container, or, simply said, the component of the Tomcat server which interacts with Java servlets.

Next, restart the Tomcat server and the Solr app should show up as running in the Web Application Manager at http://localhost:8080/manager/html

If it’s not, restart the server to make sure the app is being deployed correctly.

# service tomcat7 restart

Securing the Solr admin page

By now, the Solr app should be running at http://localhost:8080/solr. If port 8080 is publicly accessible on the server, however, as is the case by default for a public Debian VM, the complete Solr admin page is now accessible to the whole Internet without any restrictions.

To prevent his, shut down the Tomcat server immediately to avoid exposing the system to attacks.

# service tomcat7 stop

Once the server is stopped, it’s time to set up authentication for the Solr admin page. Even if port 8080 is not accessible publicly, it’s a good idea to set up authentication to prevent unauthorized access by other users on the subnet.

To do this, edit the /var/lib/tomcat7/webapps/solr/WEB-INF/web.xml file. This file contains the configurations for the deployed Solr app.

# nano /var/lib/tomcat7/webapps/solr/WEB-INF/web.xml

In this file, insert the following before the closing </web-app> element:

    <web-resource-name>Solr GUI Authentication</web-resource-name>



This will add app-wide authentication in plain HTTP with a basic password prompt for the role solr-gui.

Next, edit the /etc/tomcat7/tomcat-users.xml file to add the role to the user previously created:

<role rolename="manager-gui"/>
<role rolename="admin-gui"/>
<user username="your_username" password="your_password" roles="manager-gui,admin-gui,solr-gui"/>

Start the Tomcat server again, and the Solr app at http://localhost:8080/solr should now be accessible with the same username and password previously created. Of course, a separate username and password may be created if desired.


This is it. The server should now be running a fully functional Tomcat + Solr setup.

  1. Wikipedia – Java performance – History of performance improvements – Java 7

29 thoughts on “Install Solr 4.6 with Tomcat 7 on Debian 7”

  1. Thanks for writing this. The official documentation is not entirely helpful for people not terribly familiar with Java servlet deployment, and all the various options and tools.

    Near the end of “Installing Solr”, you change permissions, but for a tomcat6-directory instead of tomcat7.

  2. Hi,

    Thanks for such a nice tutorial. I am stuck after the deployment part. I restarted tomcat. When I log to tomcat-manager and start solr I get “FAIL – Application at context path /solr could not be started” error. I have done exactly what you said verified all the copied jars, but still getting this error.

    Any help is highly appriciated

  3. Can you get the localhost log from /var/log/tomcat7?

    Copy/paste the error in here, just the part that looks like this:

    07.05.2013 11:05:36 org.apache.catalina.core.StandardContext filterStart
    SCHWERWIEGEND: Exception starting filter SolrRequestFilter
    org.apache.solr.common.SolrException: Could not find necessary SLF4j logging jars. If using Jetty, the SLF4j logging jars need to go in the jetty lib/ext directory. For other containers, the corresponding directory should be used. For more information, see:
    at org.apache.solr.servlet.SolrDispatchFilter.(
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
    at java.lang.reflect.Constructor.newInstance(
    at java.lang.Class.newInstance0(
    at java.lang.Class.newInstance(
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(
    at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(
    at org.apache.catalina.core.ApplicationFilterConfig.
    at org.apache.catalina.core.StandardContext.filterStart(
    at org.apache.catalina.core.StandardContext.start(
    at org.apache.catalina.manager.ManagerServlet.start(
    at org.apache.catalina.manager.HTMLManagerServlet.start(
    at org.apache.catalina.manager.HTMLManagerServlet.doGet(
    at javax.servlet.http.HttpServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.catalina.core.StandardWrapperValve.invoke(
    at org.apache.catalina.core.StandardContextValve.invoke(
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
    at org.apache.catalina.core.StandardHostValve.invoke(
    at org.apache.catalina.valves.ErrorReportValve.invoke(
    at org.apache.catalina.core.StandardEngineValve.invoke(
    at org.apache.catalina.connector.CoyoteAdapter.service(
    at org.apache.coyote.http11.Http11Processor.process(
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
    Caused by: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
    at org.apache.solr.servlet.SolrDispatchFilter.
    … 32 more
    Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
    at org.apache.catalina.loader.WebappClassLoader.loadClass(
    at org.apache.catalina.loader.WebappClassLoader.loadClass(
    … 33 more

    That is, one date instance. No need for the whole thing. Find the error that looks the most relevant.

  4. I’ve been going through tons of different instructions for installing Solr with Tomcat. After about two weeks of hair pulling, I finally found your instructions, and they worked for me perfectly. Thanks so much for posting this. BTW, I am on CentOS and had installed Tomcat using EasyApache, and your instructions still worked 🙂

  5. Dude you are awsome!!! Have been fiddling around getting solr to work.. and this was a very good explaination of stuff I got solr working in like 10 min!!! after hours of pain reading all over.. your blog was the best method thanks so much…

    Anyone trying install solr… this is the best tutorial around look no further.

  6. have same error as Jay Chakra

    here is error log—
    INFO: Deploying web application archive /var/lib/tomcat7/webapps/solr.war
    13.05.2014 8:49:39 org.apache.catalina.startup.ContextConfig validateSecurityRoles
    INFO: WARNING: Security role name solr-gui used in an without being defined in a
    13.05.2014 8:49:39 org.apache.catalina.core.StandardContext startInternal
    SEVERE: Error filterStart
    13.05.2014 8:49:39 org.apache.catalina.core.StandardContext startInternal
    SEVERE: Context [/solr] startup failed due to previous errors

  7. It looks like you haven’t defined the solr-gui role, as explained by the error. Maybe look at the full log file for more info and review all steps here.

    There’s likely something amiss in your /etc/tomcat7/tomcat-users.xml and /var/lib/tomcat7/webapps/solr/WEB-INF/web.xml config files.

  8. I have apache, tomcat and solr running. I have a basic home page that is a directory listing of files. How do I configure my home page to use the solr search engine ?

  9. Wokred like a charm!!!

    Thank you very much, the hard part now is to integrate in Drupal 😉

  10. I keep getting this error: FAIL – Encountered exception org.apache.catalina.LifecycleException: Failed to start component [/solr]

    I’m attempting to install Solr 4.9.0 within Tomcat 7. And I keep getting the above error. Please see my comments with ***(ALL CAPS). THE DIRECTORY ***~/solr-4.9.0/example/solr *** DOES NOT EXIST.

    in this step:

    The final step involves copying the example app’s support files to Tomcat’s Catalina base folder: /var/lib/tomcat7 and updating the folder permissions to give ownership to the Tomcat server.

    # cp -R ~***THE FOLLOWING DIRECTORY DOES NOT EXIST***/solr-4.9.0/example/solr /var/lib/tomcat7
    # chown -R tomcat7:tomcat7 /var/lib/tomcat7/solr

    Any direction would be greately appreciated.

    Thanks, Chris

  11. The tutorial assumes a tiny little bit of basic Linux knowledge, which implies that you would have run this command from your home folder:

    curl | tar xz

    If you didn’t, you may have extracted the solr folder somewhere else completely.

    If you don’t know what your home folder is, you can get to it by simply typing the following command:


    This will change your prompt from something like:

    The ~ indicates that you’re in the home folder.

  12. It worked like a charm, thanks a lot for that walkthrough, you saved me a lot of time and aggravation 🙂

  13. Hi,
    Why are you using two paths for tomcat. It’s slight confusing.
    First, you copy lib files to /usr/share/tomcat7/lib and then you deploy solr.war in /var/lib/tomcat7/webapps/solr.war. Correct me if I’m wrong

  14. This is an architectural characteristic of UNIX and Linux. Most distributions follow the same conventions called the Filesystem Hierarchy Standard:

    The /usr directory (for UNIX System Resources, not for user) is a place where shareable (i.e. between applications) read-only data is put. In Tomcat’s case, this is used to store Java classes for use by the JVM. The directory is referred to as CATALINA_HOME, an environmental variable which refers to Tomcat’s servlet container’s (i.e. Catalina) home directory, which itself symlinks to Java’s actual classpath. That way, Java can see all of the necessary classes when running your Tomcat app.

    /var (for variable) is used to store things that change, like logs, databases, websites, etc. Therefore, this is where we normally put the Tomcat web apps.

  15. Thank you for this very helpful post. I was able to set up my solr instance on GCE, however I am looking for advise on calling the service from python code using pysolr. I am not sure how to send authentication parameters.

    This is the error I get:

    Apache Tomcat/7.0.28 – Error report HTTP Status 401 – type Status reportmessage description This request requires HTTP authentication ().Apache Tomcat/7.0.28

    Can you recommend what is the best way to access this from python?

    Many Thanks!

  16. Very clear, and so easy to follow 😉

    Any hints on how to add cores/collections ? At the moment there is the default “collection1”. As I’ve read, I’m just supposed to copy/paste that directory and rename the core in “” inside. But doing that gives an initialization failure “collection2: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Error opening new searche”.

  17. I’ve found the reason ! When you copy/paste the core directory, you need to chown it to tomcat7 too :

    sudo chown -R tomcat7:tomcat7 /var/lib/tomcat7/solr/collection2

  18. For me, it worked from the beginning to the near end. But when I go to http: // localhost: 8080 / manager / html, I have an error message and I restart the service tomcat7, I always have this error. Why?

Leave a Reply

Your email address will not be published. Required fields are marked *