Version 25 (modified by pjkersha, 13 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 distrobution. You may or may not want to use the system python for this. However we are recommending python 2.4 for this install so if you system python is different you will want to create a separate python.

On Glue a fresh python 2.4 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.4 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 Paste

sudo python -m easy_install paste

Step 4: Install Pylons

sudo python -m easy_install pylons==0.9.5

If easy_install can't find this version, try:

sudo python -m easy_install -f Pylons==0.9.5

Step 5: Install Kid templating plugin

sudo python -m easy_install TurboKid

Step 6: Install CSML

This stage will install the CSML, Cdat_lite and Numeric eggs. The Numeric install was not straightforward on Glue, perhaps because I wasn't using the system python.

Anyway, try this:

sudo python -m easy_install -f csml

If that worked go straight to Step 7.

However if you got a message about not being able to find Numeric/arrayobject.h then then try and follow these instructions to make those headers available (there's probably a better way to do this but this is what worked for me). I think this is due to trying to install into a non-system python.

Step 6.1: Download and unpack the Numeric source code

sudo gunzip  -c Numeric-24.2.tar.gz
sudo tar -xvf  Numeric-24.2.tar     

cd Numeric-24.2

Step 6.2: Copy header files into your local includes

I'd installed python into /usr/local, so I had to move the headers to /usr/local/include/python2.4

There is a subdirectory called Numeric which contains the header files, copy this into your python includes eg:

sudo cp -rf Numeric /usr/local/include/python2.4/

And there are some more that need moving:

sudo cp -rf Packages/FFT/Include /usr/local/include/python2.4
sudo cp -rf Packages/RNG/Include /usr/local/include/python2.4

Right, now you can get rid of this source directory.

cd ..
sudo rm -rf Numeric-24.2

Step 6.3: Install Numeric

sudo python -m easy_install

Step 6.4: Install Cdat_Lite

sudo python -m  easy_install

Step 6.5: Install CSML

sudo python -m easy_install -f csml

Step 7: 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.4.4 (#6, Jul 10 2007, 09:11:51) 
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylons
>>> import paste
>>> import Numeric
>>> import cdms
>>> import csml
could not import Image

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 CSML services code...

Step 8: Install the OWS Framework Eggs

Install ows_server egg:

sudo python -m  easy_install -f ows_server

Install ows_common egg:

sudo python -m  easy_install -f ows_common

Step 9: 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 10: 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

Security Configuration

Security settings are organised under the [NDG_SECURITY] section of the config file. Set-up includes the following steps:

  • certificates are created to secure communication with security web services (WS-Security and SSL Settings)
  • the Discovery service is set up to run over http and https Virtual Hosts and
  • parameters are configured to enable the Gatekeeper to make access control decisions for secure data requests.

For help contact Phil.

Secure Communication with Security Web Services

Create a Discovery Service certificate and private key. For the private key:

cd /etc/ndg/ows_server/conf/certs
openssl genrsa -des3 -out discovery.key 2048
chmod 400 discovery.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 discovery.key -out discovery.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 DiscoveryService. 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' < discovery.csr

When you receive the signed certificate copy it into /etc/ndg/ows_server/conf/certs/discovery.crt. Once you have the certificate, the certificate request file discovery.csr can be removed. You should also receive a copy of the CA certificate. If not request it. Copy the CA certificate to /etc/ndg/ows_server/conf/certs/cacert.crt

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 discovery certificate and private key and CA certificate files should be referenced in the discovery config /etc/ndg/ows_server/conf/ndgDiscovery.config) as follows:

# WS-Security signature handler
# This is an application certificate ... (which may be a machine certificate)
# X.509 certificate sent with outbound signed messages
wssCertFilePath: /etc/ndg/ows_server/conf/certs/discovery.crt

# Private key used to sign messages
# This is an application certificate ... (which may be a machine certificate)
wssKeyFilePath: /etc/ndg/ows_server/conf/certs/discovery.key

# Password for private key - comment out if the file is not password protected
wssKeyPwd: password

# Space separated list of CA cert. files to validate certs against when
# verifying responses
wssCACertFilePathList: /etc/ndg/ows_server/conf/certs/cacert.crt

In the above, replace password with the password you set to protect the private key. If no password was set leave this field blank.

Finally, the field sslCACertFilePathList can be used to authenticate peers for SSL connections to security web services. In the current implementation this applies to the Session Manager web service. This runs over https. On a request to the Session Manager, the Discovery service can verify the Session Manager's X.509 certificate against a list of acceptable CA certificates. If the Session Manager's X.509 certificate is not issued by any of the CA certificates in the list the connection is rejected.

# SSL Connections
# Space separated list of CA cert. files.  The peer cert.
# must verify against at least one of these otherwise the connection is
# dropped.
sslCACertFilePathList: /etc/ndg/ows_server/conf/certs/cacert.crt

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>

Gatekeeper Settings

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. To check the Distinguished Name:

openssl x509 -in aa.pem -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.

# Gatekeeper Attribute Certificate check
# Issuer - should match with the issuer element of the users Attribute
# Certificate submitted in order to gain access
acIssuer: /CN=AttributeAuthority/O=NDG/OU=YourOrganisationName

# verification of X.509 cert back to CA
acCACertFilePathList: /etc/ndg/ows_server/conf/cacert.crt

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 1. Numeric Install

The Numeric install doesn't always go smoothly, see step 6 for possible solution.

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).