These are instructions on how to install old versions of the SSM (before 0.7). They are only here for posterity - you shouldn't really be following them.
Please follow the instructions at APEL/SSMInstallation instead.
- As well as the following the instructions in the 'Certificates' section below, you will need to send us the DN of the certificate you are using, so that we add it to the list of trusted certificates.
- we use 2.4.3, the standard version with SL5
- stomppy: the python STOMP library
- the version in the epel repository (3.0.3) conflicts with python 2.4 - don't use this!
- We have been using 2.0.2 (the version in the EGEE SA1 repository is 2.0.4 and this seems to work as well)
- this is how we install stomppy 2.0.2 (as root):
$ wget http://stomppy.googlecode.com/files/stomp.py-2.0.2.tar.gz $ tar -xvzf stomp.py-2.0.2.tar.gz $ chown -hR root:root stomp.py-2.0.2 $ cd stomp.py-2.0.2 $ python setup.py build $ python setup.py install
- we use 0.9.8, the standard version with SL5
You can't currently download a version of the code, but if you would like a zip file please email firstname.lastname@example.org and we will send you a version.
- Unzip the file into a directory, which is denoted as $SSM_HOME below.
The environment variable SSM_HOME must be set appropriately (the one containing bin/, src/, and conf/):
There are two other configuration files.
Note that the variable SSM_HOME can be used in ssm.cfg but not ssm.log.cfg.
The default values should suffice to send messages to the APEL test system, but there are notes about the file below.
This SSM will be a producer, so the consumer section can be left out or given dummy values - it doesn't hurt. The file is well commented, it should be straightforward. In this file configure:
- the broker to use (host: dev.msg.cern.ch port: 6163 for testing purposes)
- the message store (suggest: $SSM_HOME/messages)
- the certificate/key settings and CA directory (you can't use $SSM_HOME in these fields. This will be fixed in version 0.6).
- the topic to send to (/topic/grid.accounting.cpuTest.CENTRAL is being used for testing)
- The DN of the consumer that messages are sent to(
- The acknowledgment topic; a sensible default is already used.
The default values should suffice, but you must do one of two things:
- Create the directory
/var/log/apel/and give the user running the SSM access to this directory.
- In the section [handler_fileHander], specify the path to a log file. The directory must exist and the user running the SSM must have permission to write to it. You need a full path - you can't use $SSM_HOME. Example:
Your SSM encrypts using our certificate. Before it does this, it tries to verify it against the CA certificates in
/etc/grid-security/certificates. To ensure this works fine, install the lcg-CA package using yum.
Your SSM uses your host key to sign the messages it sends. When our version of the SSM receives a message, it retrieves your certificate and attempts to verify it against the CA certificates in the lcg-CA rpm. It also checks the DN to see if it is from a certificate that we trust. This is why we need the certificate's DN from you to add to the 'trusted' list. (In practice, when a message is rejected because the DN isn't trusted, the SSM will store the DN in the log file, so we can find it and add it if necessary.)
If your host certificate is not signed by one of these CAs, discuss this with email@example.com.
In order to encrypt and sign successfully, the user running the SSM needs read access to both the host certificate and private key.
Running the SSM
If the SSM's messages directory does not exist, it will be created when the SSM starts. It contains sub-directories accept/, ack/, incoming/, outgoing/, reject/. For sending purposes you only need the outgoing/ directory.
Once the SSM is running, it will send messages from the directory
$SSM_HOME/messages/outgoing automatically. All you need to do is to put the messages in this directory. If they don't disappear, check the log file to see what it says, check your configuration, then send us an email.
Stopping the SSM
The easiest way to do this currently is to kill it using its pid. You can do this something like as follows:
[apelssm@apel-test messages]$ ps ax | grep python 25402 pts/0 Sl+ 0:00 python /opt/apelssm/ssm-0.3/src/ssm/ssm_master.py /opt/apelssm/ssm-0.3/conf/ssm.cfg 25459 pts/1 S+ 0:00 grep python [apelssm@apel-test messages]$ kill 25402 [apelssm@apel-test messages]$