This information is kept for reference. Please install a new version of the SSM, following the instructions on the page APEL/SSMInstallation.
- 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
- we now recommend that you use the version in the epel repository (3.0.3). Version 2.0.2 should still work.
- if you have the EPEL repository enabled:
yum install stomppy.
- To remove an old manual installation of stomppy, see the bottom of this page.
- we use 0.9.8, the standard version with SL5
- if you want to check CRLs when verifying certificates, you need to install fetch-crl. It is available in the EPEL repository:
yum install fetch-crl
service fetch-crl-cron start
chkconfig fetch-crl-cron on
- fetch-crl must have run once for the certificates to be verified successfully. You can choose to skip this check - see below.
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
- 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(
- To skip certificate CRL checks, set
- 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 host's (raptest's) 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 apel-admins [at] stfc.ac.uk.
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.7/src/ssm/ssm_master.py /opt/apelssm/ssm-0.7/conf/ssm.cfg 25459 pts/1 S+ 0:00 grep python [apelssm@apel-test messages]$ kill 25402 [apelssm@apel-test messages]$
We will add a start-up / shut-down script in a version before production.