Configuring GeoNode for Production

This page documents recommendations for configuring GeoNode in production environments. The steps mentioned in the first section are required to run GeoNode, the ones in the second section are either optional or ways to get more performance.

Note

This document makes numerous references to the <host> variable, please replace it with the IP Address of your GeoNode or the DNS entry.

For example: instead of http://<host>/geoserver, write down: http://mygeonode.com/geoserver or http://127.0.0.1/geoserver

Set the correct GeoServer Proxy URL value

Navigate to http://localhost/geoserver, log in and click on the Global link in the Settings section.

../../_images/geoserver_global_settings.png

Find the Proxy Base URL text field, put the complete address there:

http://<host>/geoserver/
../../_images/geoserver_proxy_url.png

Configure the Printing Module

This lives in the GeoServer Data dir /var/lib/geoserver/geonode-data/printing/config.yaml, add your server’s IP address or domain name to the list of exceptions:

hosts:
  - !dnsMatch
    host: YOUR_IP_ADDRESS
    port: 80

Adding layers from Google, Bing and other providers

Get an API key from Microsoft at http://bingmapsportal.com/ and place it in local_settings.py.:

BING_API_KEY="zxcxzcXAWdsdfkjsdfWWsdfjpowxcxz"

Copy the MAP_BASELAYERS dictionary from settings.py into local_settings.py and add the following snippet:

},{
"source": {
           "ptype":"gxp_bingsource",
           "apiKey": BING_API_KEY
          },
"group":"background",
"name":"Aerial",
"visibility": False,
"fixed": True,

Get an API key from Google at http://code.google.com/apis/maps/signup.html and place it in local_settings.py, for example:

GOOGLE_API_KEY="zxcxzcXAWdqwdQWWQEDzxcxz"

Copy the MAP_BASELAYERS dictionary from settings.py into local_settings.py (or edit the previously copied snippet) and add the following snippet:

},{
"source": {
     "ptype":"gxp_googlesource",
     "apiKey": GOOGLE_API_KEY
    },
"group":"background",
"name":"SATELLITE",
"visibility": False,
"fixed": True,

Sitemaps Configuration

GeoNode can automatically generate a sitemap suitable for submission to search engines which can help them to index your GeoNode site more efficiently and effectively.

In order to generate the sitemap properly, the sites domain name must be set within the sites framework. This requires that an superuser login to the admin interface and navigate to the sites module and change example.com to the actual domain name (and port if applicable). The admin interface can be accessed at http://<host>/admin/sites/site/. Click on the example.com link, and change both the Domain name and Display name entries to match your system.

It is possible to ‘inform’ google of changes to your sitemap. This is accomplished using the ping_google management command. More information can be found here http://docs.djangoproject.com/en/dev/ref/contrib/sitemaps/#django.contrib.sitemaps.ping_google It is recommended to put this call into a cron (scheduled) job to update google periodically.

Configuring User Registration

You can optionally configure GeoNode to allow new users to register through the web. New registrants will be sent an email inviting them to activate their account.

To allow new user registration:

  1. Set up the email backend for Django (see Django documentation) and add the appropriate settings to ./src/GeoNodePy/geonode/settings.py. For example:

    EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
    EMAIL_HOST = 'smtp.gmail.com'
    EMAIL_HOST_USER = 'foo@gmail.com'
    EMAIL_HOST_PASSWORD = 'bar'
    EMAIL_PORT = 587
    EMAIL_USE_TLS = True
    
  2. One week activation window:

    ACCOUNT_ACTIVATION_DAYS = 7
    
  3. In the same settings file set:

    REGISTRATION_OPEN=True
    
  4. With the Django application running, set the domain name of the service properly through the admin interface as specified above in the Sitemaps section. (This domain name is used in the account activation emails.).

To register as a new user, click the ‘’Register’’ link in the GeoNode index header.

Additional Configuration

Some other things that require tweaking:

  • Web-accessible uploads directory for user profile photos

Robot Exclusion File

GeoNode has several views that require considerable resources to properly respond - for example, the download links on layer detail pages require GeoServer to dynamically generate output in PDF, PNG, etc. format.

Crawlers for web search engines such as Google may cause problems by quickly following many such links in succession.

In order to request that “robots” do not make requests directly to GeoServer, you can ensure that requests to /robots.txt return a text file with the following content:

User-agent: *
Disallow: /geoserver/

This will only affect automated web agents; web browsers in particular are unaffected.

Memory Management

At the time of the GeoNode 1.0 release, the GeoNode manual recommended at least 4GB RAM for servers running GeoNode.

While 4GB physical RAM is sufficient, it is recommended that machines be configured with at least 6GB total virtual memory.

For example, a machine with 4GB physical RAM and 2GB swap space should be able to run GeoNode, but if you would like to run without a swapfile then you should configure the machine with at least 6GB RAM.

On Linux and MacOSX hosts, you can check the available RAM with the following command:

$ free -m
             total         used       free     shared    buffers     cached
Mem:          6096         3863       2232          0          0          0
-/+ buffers/cache:         3863       2232
Swap:            0            0          0

The “total” column lists the available physical memory and swap space in megabytes; adding them together yields the amount of virtual memory available to the system.

In this example, there is no Swap space so that field is 0 and the available RAM on the system is 6096MB (6 GB).

Security Integration Optimization

GeoServer delegates authentication and authorization to GeoNode. The default configuration uses an HTTP endpoint in GeoNode to discover the current user and the layers that are accessible. For production, it is advisable to use a database-level connection.

The SQL for the stored procedure is distributed with the GeoServer web application archive and can be found at WEB-INF/classes/org/geonode/security/geonode_authorize_layer.sql in the webapps directory. It can be loaded using the psql command by following these steps (if not using tomcat6 or Ubuntu, locate the webapps directory for your configuration):

$ cd /var/lib/tomcat6/webapps
$ sudo su - postgres
$ psql -d YOUR_DATABASE < geoserver/WEB-INF/classes/org/geonode/security/geonode_authorize_layer.sql

If a context configuration XML file does not already exist, create one for GeoServer. If using Tomcat6 on Ubuntu, this file resides at /etc/tomcat6/Catalina/localhost/geoserver.xml. If creating a new file, the following XML should be added (replace ALLCAPS with your specific values):

<Context path="/geoserver"
    antiResourceLocking="false" >
  <Parameter name="org.geonode.security.databaseSecurityClient.url"
    value="jdbc:postgresql://localhost:5432/DATABASE?user=USER&amp;password=PASSWORD"/>
</Context>

If the file exists already, just add the Parameter element from above.

To verify the settings change, look in the GeoServer logs for a line that notes: “using geonode database security client”. If any issues arise, check your connection configuration as specified in the context file above.

Configuring the Servlet Container

GeoServer is the most resource intensive component of GeoNode.

There are some general notes on setting up GeoServer for production environments in the GeoServer manual .

However, the following are some GeoServer recommendations with GeoNode’s specific needs in mind.

The JRE used with GeoNode should be that distributed by Oracle.

Others such as OpenJDK may work but Oracle’s JRE is recommended for higher performance rendering.

Startup options should include the following:

-Xmx1024M -Xms1024M -XX:MaxPermSize=256M \
    -XX:CompileCommand=exclude,net/sf/saxon/event/ReceivingContentHandler.startEvent

These can be specified using the CATALINA_OPTS variable in Tomcat’s bin/catalina.sh file, or the JETTY_OPTS in Jetty’s bin/jetty.sh file.

While the JVM provides memory management for most operations in Java applications, the memory used for rendering (in GeoServer’s case, responding to WMS GetMap requests) is not managed this way, so it is allocated in addition to the memory permitted by the JVM options above.

If GeoServer receives many concurrent requests, it may increase the memory usage significantly, so it is recommended to constrain the number of concurrent requests at the servlet container (ie, Jetty or Tomcat).

For Tomcat, you can edit conf/server.xml. By default, this file contains an entry defining a ContextHandler:

<Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443"/>

Add a maxThreads attribute to limit the number of threads (concurrent requests) to 50 (the default in Tomcat is 200):

<Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" maxThreads="50"/>

Note

This configuration is possible in Jetty as well but not yet documented in this manual.

Using the native-code implementation of JAI and JAI ImageIO speeds up GeoServer, thereby requiring less concurrency at the same level of throughput.

The GeoServer manual contains platform-specific instructions for configuring JAI and JAI ImageIO.

GeoServer Configuration

There are a few controls to be set in the GeoServer configuration itself as well.

On the JAI Settings page

../../_images/GeoServer-JAI-Settings.png

There are two considerations for the JAI settings.

  • Enable JPEG and PNG Native Acceleration to speed up the performance of WMS requests
  • Disable Tile Recycling as this optimization is less relevant on recent JVM implementations and has some overhead itself.

On the WMS Service page

../../_images/GeoServer-Web-Map-Service.png

There is only one consideration for the Web Map Service page

  • Don’t set the “Resource Consumption Limits.” This sounds a bit counter intuitive, but these limits are implemented in an inefficient way such that unless resource-intensive requests are common on your server it is more efficient to avoid the limits. A better implementation of this feature is available for GeoServer 2.1 and will be incorporated in GeoNode 1.1.

Printing with the Mapfish Print Service

The GeoNode map composer can “print” maps to PDF documents using the Mapfish print service. The recommended way to run this service is by using the printing extension to GeoServer (if you are using the pre-built GeoNode package, this extension is already installed for you). However, the print service includes restrictions on the servers that can provide map tiles for printed maps. These restrictions have a fairly strict default, so you may want to loosen these constraints.

Adding servers by hostname

The Mapfish printing module is configured through a YAML configuration file, usually named print.yaml. If you are using the GeoServer plugin to run the printing module, this configuration file can be found at GEOSERVER_DATA_DIR/printing/config.yaml. The default configuration should contain an entry like so:

hosts:
  - !dnsMatch
    host: labs.metacarta.com
    port: 80
  - !dnsMatch
    host: terraservice.net
    port: 80

You can add host/port entries to this list to allow other servers.

See also

The Mapfish documentation on configuring the print module.

The GeoServer documentation on configuring the print module.