Version 42 (modified by pjkersha, 11 years ago) (diff)


Installing the Pylons stack: Discovery, Browse, and CSML services

All the NDG services are now built on top of the the  Pylons framework. This is a guide to installing the framework and all the NDG services based on my experiences of installing from scratch on the glue development server. Most of the install uses 'easy_install' to install python eggs.

Step 1: Choose your Python

This process is going to install a lot of packages (mainly eggs) to your python distribution. You may or may not want to use the system python for this. However we are recommending python 2.5 for this install so if your system python is different you will want to create a separate python.

On Glue a fresh python 2.5 was installed into /usr/local.

Whichever python you use (system or otherwise), in the following instructions, whenever you see the command 'python' it refers to your chosen python so make sure your PATH environment variable is correct. The command 'sudo' is used throughout as I was in a directory owned by the root user, but this may or may not apply to you.

Python 2.5 can be downloaded  here along with install instructions.

Step 2: Install the latest setuptools egg


sudo wget

If that didn't work you probably need to set the http_proxy environment variable:

export http_proxy=

Run it and setuptools will be installed:

sudo python

And you can now delete

sudo rm

Step 3: Install CSML

This stage will install the CSML, cdat_lite and numpy eggs. As of CDatLite 5.0, the Numeric package is replaced by numpy. These instructions are given here but more details of the new CDatLite package can be found here.

Download the netCDF tarball from  here. Extract and follow the instructions in the INSTALL file. If you encounter problems there is a  help page with a list of known issues

Install numpy:

sudo python -m easy_install numpy

Install CDatLite:

sudo python -m easy_install -f cdat_lite

Install CSML:

sudo python -m easy_install -f csml

Step 4: Recap

If you've got to this stage you should be able to start python and test out your imports:

-bash-2.05b$ python
Python 2.5.2 (r252:60911, Jun  4 2008, 11:30:27)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-59)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import cdms2
>>> import csml
NASAAmes interface not available. CSML will still work, but won't support NASA Ames files
Python Image Library not available. CSML will still work, but won't support image files

The message about 'Image' means the python imaging library is not installed. This is not mandatory, and is only needed for PML at the moment.

So now all the components are there except for the discovery, browse and security code...

Step 5: Install the OWS Framework Eggs

Install ows_server egg:

sudo python -m  easy_install -f ows_server

This will also install required dependencies such as ows_common, ndgUtils, Pylons, Paste (itself a dependency of Pylons), TurboKid? and ZSI.

Step 6: Install Security

For installation instructions for NDG Security Services see the  NDG Security Installation Guide. If security services are already configured but are running on a separate machine, install the security client software:

Download the special installation script:



python ./ -a

For troubleshooting see the  Security installation Guide.

Step 7: Set-up Config directories

Make a directories for configuration and items:

sudo mkdir /etc/ndg
sudo mkdir /etc/ndg/ows_server
sudo mkdir /etc/ndg/ows_server/conf /etc/ndg/ows_server/run /etc/ndg/ows_server/logs
sudo mkdir /etc/ndg/ows_server/conf/certs 
sudo chmod 700 /etc/ndg/ows_server/conf/certs

The last step is an additional precaution to protect files in certs/

Copy config files from the repository to /etc/ndg/ows_server/conf

sudo cd /etc/ndg/ows_server/conf
svn export 
svn export

Step 8: Edit local settings

You will need to configure which port you are using to serve the pylons applications. The default is 8080. To change it edit the file called development.ini (in the /etc/ndg/ows_server/conf directory) and change the port number in this section to the port you want to use (or leave it if you want 8080).

use = egg:Paste#http
host =
port = 8080

Now open the file in /etc/ndg/ows_server/conf called ndgDiscovery.config, and change the 'repository' and 'server' urls to match your server.

Now ensure you are in the NDG Services config directory:

cd /etc/ndg/ows_server/conf

Discovery Standalone Interface

Note that it's possible to run the Discovery/Browse? code stack as a Discovery only interface. In this case, no security is required. To set in this configuration set the standalone flag in the [DISCOVERY] section of ndgDiscovery.config to 'True':

standalone: True

Security Configuration

If the Browse interface is required, then security needs to be configured. The steps are:

  1. Single Sign On Service - this enables uses from other trusted sites to login at your Browse site with their home ID.
  2. Gatekeeper - MOLES and CSML records available from the Browse interface can be secured with role based access control using the Gatekeeper.
  3. WS-Security Settings - secures transactions between Browse and NDG security web services.
  4. Apache Virtual Hosts - enables Browse to be exposed outside the site firewall and serves Browse over http and https for the Single Sign On Service.

Security settings are organised under the [NDG_SECURITY.*] sections of the ndgDiscovery.config file.

1. Single Sign On Service

Settings are organised under the section [NDG_SECURITY.ssoService]. Only the most important settings are described here. The rest should be left as their default values.

  • Server Address settings - the single sign on service relies on the ability to serve the Browse interface over http and https. This can be configured with Apache - see later. The sslServer setting should be the same as the server setting in the with the exception that the protocol is https e.g.

  • Security web service addresses. - Put in here the addresses for the local Session Manager and Attribute Authority services e.g.
  • SSL Connections - the Browse interface includes a login facility as part of the Single Sign On service. If another site requests the user to login, the Single Sign On Service can check that site's SSL certificate. This is an anti-phishing measure. Include in this parameter a space separated list of all the CA certificates required to enable this site to verify trusted site login requests. For help getting these files contact Phil.
sslCACertFilePathList: certs/badc-ca.crt certs/bodc-ca.crt certs/nocs-ca.crt certs/neodaas-ca.crt

2. Gatekeeper Settings

These are set in the section [NDG_SECURITY.gatekeeper]. Settings starting with pdp should be left as their defaults.

The address of the local Attribute Authority is needed:


When a request is made for secured data an Attribute Certificate is submitted on behalf of the user. This contains a list of roles or attributes that they are entitled to. It is digitally signed by the Attribute Authority service that issued it.

The acIssuer and acCACertFilePathList fields enable the Gatekeeper to verify that your organisation's Attribute Authority signed the Attribute Certificate submitted to it.

Set the acIssuer field to the Distinguished Name of the Attribute Authority's X.509 Certificate. The Attribute Authority holds an X.509 certificate on its host machine. This is normally in /etc/ndg/security/conf/certs on the security web services host machine. To check the Distinguished Name:

openssl x509 -in aa.crt -subject

The acCACertFilePathList should be set to the CA certificate that issued the Attribute Authority's X.509 Certificate. This would be expected to be the one previously obtained in /etc/ndg/ows_server/conf/cacert.crt.

acIssuer: /CN=AttributeAuthority/O=NDG/OU=YourOrganisationName
acCACertFilePathList: certs/badc-ca.crt

For help with set-up contact Phil.

3. WS-Security Settings

Settings are contained in the section [NDG_SECURITY.wssecurity].

Create a certificate and private key for the Browse PDP (Policy Decision Point). For the private key:

cd /etc/ndg/ows_server/conf/certs
openssl genrsa -des3 -out browse.key 2048
chmod 400 browse.key

You will be prompted for a password to protect the file. If you don't want to password protect it, omit the -des3 argument.

Then, create a new certificate request:

openssl req -new -key browse.key -out browse.csr

You will be prompted for the fields that will make up the Distinguished Name of the certificate when it is issued. It is recommended that a Common Name is set to Browse. Organisation can be NDG and Organisation Unit, the name of your organisation. Other fields can be left blank.

E-mail the request file so that it can signed and sent back to you:

mail -s 'Certificate Request' < browse.csr

When you receive the signed certificate copy it into /etc/ndg/ows_server/conf/certs/browse.crt. Once you have the certificate, the certificate request file browse.csr can be removed. You should also install a copy of your CA certificate and the CA certificates of all the other NDG sites that you trust. If you don't know how to get this contact Phil for help. Copy the CA certificates into /etc/ndg/ows_server/conf/certs/

Certificate files can be checked with openssl e.g. the following command will print out the Distinguished Name for the CA certificate:

openssl x509 -in cacert.crt -subject

The new certificate and private key and CA certificate files should be referenced in the discovery config /etc/ndg/ows_server/conf/ndgDiscovery.config) as follows:


If the private key is password protected, enter the password here:

signingPriKeyPwd: opensesame

If no password was set leave this field blank.

Nb. As a security precaution, ndgDiscovery.config should be set with minimal file permissions required for the Browse running user ID to read and write the file e.g.

chmod 600 ndgDiscovery.config

Provide a list of the CA certificates used by NDG trusted sites

caCertFilePathList: certs/badc-ca.crt certs/bodc-ca.crt certs/nocs-ca.crt certs/neodaas-ca.crt

4. Virtual Hosting of the Discovery Service over http and https

Paste, the Discovery application server runs over http but pages for Single Sign On require https for the secure transfer of user credentials. One way to achieve this is to run paste on a port hidden inside the firewall exposing it to the outside using Virtual Hosting e.g. with Apache. The service running on a particular port is exposed outside on 80 (http) and 443 (https):

http://localhost:8080 -> http://your-site-discovery-url
http://localhost:8080 -> https://your-site-discovery-url

Note that the same your-site-discovery-url is used in both cases.

Example .conf file configurations for Apache2 are shown below for http and https proxies:

ServerName localhost
NameVirtualHost *:80

<VirtualHost *:80>
  DocumentRoot /var/www/html
  ServerName localhost

  # NDG Discovery
  ProxyPass / http://localhost:8080/
  ProxyPassReverse / http://localhost:8080/
  ProxyPreserveHost On
  <Proxy *>
      Order deny,allow
      Allow from all

https Virtual Host ...

ServerName localhost
NameVirtualHost *:443

<VirtualHost *:443>
  DocumentRoot /var/www/secure
  ServerName localhost
  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/crt/server.crt
  SSLCertificateKeyFile /etc/apache2/ssl/key/server.key
  SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

  # NDG LoginService
  ProxyPass / http://localhost:8080/
  ProxyPassReverse / http://localhost:8080/
  ProxyPreserveHost On
  <Proxy *>
      Order deny,allow
      Allow from all

SSLCertificateFile and SSLCertificateKeyFile set the certificate and private key used for SSL connections. If you don't have these, a certificate request can be made to the NDG CA. Follow the same steps as outlined in Secure Communication with Security Web Services making sure to set the certificate Common Name to the fully qualified domain name of the server host.

Details may vary according to the version of Apache you use. Please check the relevant Apache documentation for correct settings. The example uses a redirect to localhost. To expose outside, use your-site-discovery-url.

These changes should be reflected in the discovery config file, /etc/ndg/ows_server/conf/ndgDiscovery.config. The server field should be assigned http://your-site-discovery-url and sslServer to https://your-site-discovery-url:

# the following is the server on which this browse/discovery instance runs!
server: http://<your-site-discovery-url>
sslServer: https://<your-site-discovery-url>
server: http://<your-site-discovery-url>

Step 11: Start the services

Starting the server is a one line command:

paster serve --reload development.ini

If that all worked, then you should be able to navigate to your server eg  http://localhost:8080 and see the message:

Welcome to your Pylons Web Application

If that worked, try navigating to the discovery service: e.g.


If that worked try and view discovery and browse records!!

CSML services (WMS and WCS) are also available in this stack, but as they are still under development and nobody has any CSML they will be the subject of another wiki page.

Step 12: Add to boot

This script can be put in /etc/init.d and will start your service on boot. Give it a suitable name, such as 'ndgservices'.

#!/bin/sh -e
# chkconfig: 2345 99 01
# description: NERC Data Grid Discovery Service

export PYTHON_EGG_CACHE=/tmp

    local pid=
    # Get pid from PID file
    local pidFound=
    if [ -f $PID ] ; then
        pid=$(cat $PID)
        if [ -z "$pid" ]; then
            echo $"Can't get pid from pid file $PID"

    # look for pid in listing
    for i in `pidof -o $$ -o $PPID -o %PPID -x "${PROG}"`; do
        [[ $i = $pid ]] && pidFound=Yes && break;
    if [ -n "$pidFound" ]; then
        echo $"$prog (pid $pid) is running..."

    elif [ -f ${PID} ]; then
        echo $"$prog is dead but pid file $PID exists"
        echo $"$prog is dead"

case "$1" in
    ${PROG} serve --daemon --reload --pid-file=$PID --log-file=$LOG $INI
    ${PROG} serve --stop-daemon --pid-file=$PID
    ${PROG} serve --stop-daemon --pid-file=$PID
    ${PROG} serve --daemon --reload --pid-file=$PID --log-file=$LOG $INI
    echo $"Usage: $(basename $0) {start|stop|restart|status}"
    exit 1

you can then start/restart/stop/check status using:

sudo sh /etc/init.d/ndgservices start
sudo sh /etc/init.d/ndgservices restart
sudo sh /etc/init.d/ndgservices stop
sudo sh /etc/init.d/ndgservices status

(in this case 'ndgservices' is the name of the script)

If your Linux distribution has the chkconfig command you can register the service:

chkconfig --add ndgservices

and then administer with

sudo service ndgservices start
sudo service ndgservices restart
sudo service ndgservices stop
sudo service ndgservices status


Please note any problems encountered or issues here - along with the solution if you know it.

Issue 2. Routes not working properly.

If you try a URL such as this:


And get a "Not Found, The resource could not be found." error then that indicates a problem with the routes module.

This problem occurs with routes version 1.6.3. Upgrading to 1.7 should solve the problem. Use the -U flag in easy_install to upgrade:

easy_install -U routes

Issue 3. Zombies

When trying to set up step 12 (run at boot) I was getting lots of problems with zombie processes that I couldn't kill off. It turned out that the file was not getting written out. If this happens edit the init script and change the location of the file to somewhere writeable (or change the permissions of it's current location).