Book Image

Mastering Geoserver

By : Colin Henderson
Book Image

Mastering Geoserver

By: Colin Henderson

Overview of this book

Table of Contents (19 chapters)
Mastering GeoServer
About the Author
About the Reviewers

Installing Apache Tomcat

At the time of writing this book, the most recent version of Apache Tomcat is 8. At the moment, there is limited testing of GeoServer running inside Apache Tomcat 8, which means that we should avoid using it, at least for now. Instead, we will use the latest version of Apache Tomcat 7, which is currently 7.0.50. The download page for this version is

Installing Apache Tomcat 7 on CentOS 6.3

As with all the Linux variants, CentOS has a package management system that can be used to install software, including Apache Tomcat. However, quite often, the packaged software is several versions behind the current version. Unlike other software running on Linux, Tomcat does not actually require compiling, and so installing it directly from Apache is not much of a challenge. Perform the following steps to install Apache Tomcat on CentOS:

  1. First, we need to download the Tomcat package to our system. Go to the download page ( and find the download link for the tar.gz package under the Core entry. With the location of the link, we can download the file with the following command:

    $ wget
  2. Once the download is complete, we need to think about where we want to place the installation on the system. The most common location seems to be /opt, which seems as good a place as any. Extract the Tomcat files using the following command:

    $ sudo tar –xvzf apache-tomcat-7.0.50.tar.gz –C /opt
  3. The contents of the tarball will be extracted to /opt/apache-tomcat-7.0.50/, which will now become our Tomcat home directory. These are the bare minimum steps required to get Tomcat installed, so you can now issue the following command and Tomcat will happily start:

    $ sudo ./opt/apache-tomcat-7.0.50/bin/
  4. Replace with on the last command to shut Tomcat down if you just started it.

This is interesting, but actually not particularly useful in the context of a production environment. In a production environment, we need to be able to set memory parameters for JVM, have Tomcat run as a service on startup, and run the Tomcat service using a user with limited privileges.

Running Apache Tomcat as a service

Security is a key consideration for any production environment, and wherever possible, the applications and services should run using user accounts with just the right level of privileges for them to perform their functions. To adopt this best practice, we will now create a user account under which we can run the Tomcat service:

  1. At your command line, enter the following:

    $ sudo groupadd tomcat
    $ sudo useradd –s /bin/bash –g tomcat tomcat

    The first command creates a new user group called tomcat. The second command creates a new user called tomcat, adds this user to the tomcat group, and sets its shell to bash.

  2. Now that we have a tomcat user, we need to set the ownership of the Tomcat installation folder to this user:

    $ sudo chown –Rf tomcat:tomcat /opt/apache-tomcat-7.0.50/
  3. Now we are ready to create a service control script that will allow us to start, stop, and reload the Tomcat application. To do this, we need to create a service controller script and then register this script with an appropriate run level so that CentOS will start the service on boot:

    $ cd /etc/init.d
    $ sudo vi tomcat-1

    The preceding commands will enter the services directory on CentOS and create a blank script called tomcat-1. The name of the script is not important. However, as we will see later when scaling Tomcat in production, we might want to instantiate multiple services, and so should come up with a suitable naming convention to keep track of them. In this case, we use the convention, tomcat-n, where n will be an incremented number. The vi command will start the vim text editor with an empty file; replace this with whatever your favorite Linux text editor is.

  4. In the text editor, enter the following script:

    # description: Tomcat 1 Start Stop Restart  
    # processname: tomcat-1  
    # chkconfig: 234 20 80  
    export JAVA_HOME  
    export PATH  
    JAVA_OPTS="-server –Xmx1024m –Xms512m –XX:MaxPermSize=128m"
    export JAVA_OPTS  
    case $1 in  
    /bin/su tomcat $CATALINA_HOME/bin/  
    /bin/su tomcat $CATALINA_HOME/bin/  
    /bin/su tomcat $CATALINA_HOME/bin/  
    /bin/su tomcat $CATALINA_HOME/bin/  
    exit 0

There is quite a lot going on in this script, so let's break it down a little. The first four lines beginning with a hash (#) are settings for how the script is run. The last line in this group indicates the run levels that this service will operate under (234) and the stop and start priorities (20 and 80). This information tells the chkconfig command how to run the service.

Next, the script will set environment variables to tell the system where to find Java (JAVA_HOME), making the java command accessible on the command line (PATH) and setting the Tomcat directory (CATALINA_HOME). Next, we set an environment variable called JAVA_OPTS, which provides parameters to run JVM. This is where we can specify the memory configuration for our GeoServer instance. There is a discussion on how to determine the most appropriate memory settings for your server later in this book; for now, we will use settings that are good for an all-rounder instance of GeoServer.

The following table describes what each of these parameters are and why they are set:




This parameter tells JVM to run in the server mode, which enables it to compile the optimized byte code early. Initial calls will be slow because of longer Just-In-Time (JIT) compiling, but subsequent calls will be faster.


This parameter tells JVM the maximum amount of heap memory it can allocate. In this case, JVM will allocate a maximum of 1 GB of memory.


This parameter tells JVM how much heap memory to allocate on startup. This will ensure that memory management is more stable. In this case, we tell JVM to allocate 512 MB heap on startup.


This parameter sets the maximum size of the permanent generation (also known as permgen) allocated for GeoServer. Permgen is where the class byte code is stored. In applications that use a lot of classes, such as GeoServer, it will exhaust the default JVM allocation quickly, leading to permgen memory errors.

The final section of the script is a case statement that will perform different actions according to the first parameter (case $1) passed to the script. This can be one of start, stop, or restart. In each case, the Tomcat and/or scripts are executed.

Now we have our service script created, we need to set appropriate permissions on it, using the following command:

$ sudo chmod 755 tomcat-1

Once the script is executed, we can register it in CentOS as a service. The chkconfig utility is used to register the script as a service:

$ sudo chkconfig --add tomcat-1
$ sudo chkconfig --level 234 tomcat-1 on

The first line adds our script, and the second line sets the runtime levels for it. We can check the configuration to make sure it is registered correctly:

$ sudo chkconfig --list tomcat-1
tomcat-1        0:off   1:off   2:on    3:on    4:on    5:off   6:off

If all goes well, levels 2, 3, and 4 will be marked as on, with all other levels marked off. From this point onward, every time our server restarts, it will automatically run the tomcat-1 service, thereby giving us Tomcat on each boot.

We should now check that the script works as expected, trying each of the following commands in turn:

$ sudo service tomcat-1 start
Using CATALINA_BASE:   /opt/apache-tomcat-7.0.50
Using CATALINA_HOME:   /opt/apache-tomcat-7.0.50
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp
Using JRE_HOME:        /usr/java/latest
Using CLASSPATH:       /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar

$ sudo service tomcat-1 restart
Using CATALINA_BASE:   /opt/apache-tomcat-7.0.50
Using CATALINA_HOME:   /opt/apache-tomcat-7.0.50
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp
Using JRE_HOME:        /usr/java/latest
Using CLASSPATH:       /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar
Using CATALINA_BASE:   /opt/apache-tomcat-7.0.50
Using CATALINA_HOME:   /opt/apache-tomcat-7.0.50
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp
Using JRE_HOME:        /usr/java/latest
Using CLASSPATH:       /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar

$ sudo service tomcat-1 stop
Using CATALINA_BASE:   /opt/apache-tomcat-7.0.50
Using CATALINA_HOME:   /opt/apache-tomcat-7.0.50
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp
Using JRE_HOME:        /usr/java/latest
Using CLASSPATH:       /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar

If everything works as expected, we will see a similar output. Start the Tomcat service again if it is not already running, and then navigate to the server's IP address or the URL. We should get the Tomcat web page like the one shown in the following screenshot:

Congratulations! We now have CentOS 6.3 running Java and Apache Tomcat with the Tomcat service automatically, starting each time the server boots. Go ahead and restart the server to check that the Tomcat service starts automatically.

Securing Apache Tomcat

The default configuration of Apache Tomcat does not have any user configured for access to the web management portal. If you want to have the ability to manage your instance of Tomcat using the web management application, then you will need to configure access.

Tomcat maintains a simple user access database in the form of an XML configuration file in the conf directory. To enable access to the manager web application, you must edit the user database or create one if it does not already exist. The file is called tomcat-users.xml and has a very simple structure. Here is a very basic example of a tomcat-users.xml file:

<?xml version="1.0" encoding="utf-8">
  <role rolename="manager-gui" />
  <user username="r2d2" password="5t4rW4r5" roles="manager-gui" />

The structure of this file is very simple. First, you define the name of a role; in this case, the role name is specific to the web manager application as it expects one called manager-gui. Next, you create a <user> element and specify a username, password, and comma-separated list of roles that the user belongs to. Once you create the necessary entries for all the users, you want to grant access to the web manager application, and then you will need to restart the Tomcat service:

$ sudo service tomcat-1 restart

Once the Tomcat service has restarted, you should be able to access the manager web application at the http://[your server address]/manager/html URL. Enter your username and password when prompted.


Bear in mind that we run GeoServer in a production environment, and as such, security must be upmost in our considerations. Think carefully about the username and password you use. Make sure the password is strong and try to avoid using common usernames such as tomcat, admin, or manager.

Installing Apache Tomcat 7 on Windows Server 2008 R2 SP1

Once again, Windows users get the convenience of an installation wizard to take care of installing Tomcat. For the Windows installation package, choose the 32bit/64bit Windows Service Installer option. Download the installation file to a directory on your local hard drive.

To install Tomcat, perform the following steps:

  1. For Tomcat 7.0.50, the downloaded installation file should be apache-tomcat-7.0.50.exe.

  2. Open the folder where you saved the file, right-click on the file, and choose the Run as administrator menu item:

  3. Use the Next button to move through the installation wizard until you reach the Choose Components page. For a production system, we want to avoid any unnecessary installation, so make sure that the Documentation and Examples boxes are not ticked. Under the Tomcat branch in the components list, we want to make sure the Service Startup box is ticked. This will ensure that the Tomcat service starts when Windows starts, which is very useful in cases when the server has to be rebooted. Finally, we need to tick the box for Native, which will make use of the native APR for better performance and scalability.


    The APR is the Apache Portable Runtime, which is a library that provides Tomcat with better scalability, performance, and integration with other native web technologies.

  4. Click on the Next button to move on to the configuration page. This page is where we will set the configuration for Tomcat and Windows Service. For the first installation, we can leave the default settings for ports as they are. Enter a username and password for the web administration pages:

  5. Before moving on to the next step, an important change to the default configuration is the name of the Windows service. If we want to maximize server resources, then we will want to scale-up on the server by running more than one Tomcat service. In this case, we need to have a naming convention to distinguish between them, so we will use Tomcat7-1 and adopt a naming convention of Tomcat7-n, where n is an incremented number to identify the instance.

  6. Clicking on Next will move to the Java environment page that should have automatically selected the installation of Java we performed earlier. If it did not, you can manually browse to your JRE installation folder.

  7. Clicking on Next will move to the page where we can specify the installation folder. A default will be provided, which will be the combination of a default installation folder, with the Windows Service name set in step 5 appended. You can either accept the default or specify your own. For simplicity, we will set the installation folder to C:\Tomcat7-1.

  8. Once the installation is complete, the final wizard page will allow us the choice to start Tomcat. Uncheck the box marked Start Tomcat Service so that Tomcat does not start when we exit the installer.

Tomcat is now installed as Windows Service, which we can control like any other service.

Controlling the Tomcat service

The Windows version of Tomcat comes with an application called Monitor Tomcat, which starts automatically each time you log on to Windows. It is a System Tray application that allows quick access to monitor and manage the running Tomcat service.

Notice the icon in the top-left corner of System Tray; this is the Monitor Tomcat application and its icon tells us that Tomcat is not currently running (indicated by the red square in the middle).

If the Tomcat service runs, it displays a green triangle on its side, like a "play" symbol. If we right-click on the Monitor Tomcat application icon, we get a context menu as shown in the following screenshot:

The context menu provides us with the ability to access the Tomcat service configuration and allows us to stop and start the service without the need to go through the normal Windows service applet. Of course, Tomcat still runs as a normal Windows service, so there is nothing stopping us to manage it in the normal way; the Monitor Tomcat application is just a convenience tool.

Configuring the Tomcat service

Before we start the Tomcat service to check our installation is alright, we must configure the memory settings that Tomcat will use for Java VM. Right-click on the Monitor Tomcat application icon and select the Configure… menu item to open the Tomcat service configuration dialog. Once it is open, click on the Java tab at the top:

The Java tab allows us to set options that control the way Tomcat starts Java VM; the most important of these, from our perspective, is the memory configuration. Memory settings can be specified in one of the following two ways:

  • Parameters in the Java Options textbox

  • Entering values in Initial memory pool, Maximum memory pool, and Thread stack size

The choice is merely one of the preferences as both will achieve the same effect. My personal preference is to put everything into the Java Options textbox as it is good to remind oneself of the correct Java option parameter names, especially if you have a mixed Linux/Windows server environment.

The actual values to use for memory settings are subjects that we will cover later in this book, and we will very much depend on how you intend to use your GeoServer in production. For example, if you only intend serving vector data (through WFS), then GeoServer requires very little by way of memory allocation. For now, we will set the memory to some good defaults for an all-rounder GeoServer. Click on the Java Options textbox and scroll to the last parameter, press Enter to start a new line, and then enter the following parameters:



These parameters and what their values mean are described in the table given in the Running Apache Tomcat as a service section of this chapter.

With the Java options set, we are now ready to fire up the Tomcat service and check everything as is expected. Click on the General tab, then on the big Start button, and cross your fingers as the service starts up. If everything works, then the Start button will be disabled and the Stop button will be enabled. If the Start button is enabled again, and the Stop button remains disabled, then unfortunately something is wrong. Check that all the option parameters are correct and then try again. If you still don't get the service starting, check the Tomcat logs to try and figure out why.

If all goes well, we should be able to open a browser window, navigate to http://localhost:8080/, and get the Tomcat 7 web page, as shown in the following screenshot:

Tomcat 7 web page

That's it! Java and Tomcat are now both configured on your Windows Server, and it is now ready to take the GeoServer application.