MonALISA Grid Monitoring
Optical Switch Daemon
Menu mode: dynamic | fixed
  HOME       CLIENTS       REPOSITORIES       DOWNLOADS       LOOKING GLASS       FAST DATA TRANSFER  
Last update on:
Dec 03, 2015

Uptime: 237 days, 0h, 24m
Number of requests: 4041993
since 28 October 2005

Optical Switch Daemon (OSD)


Authentication Security for OSD:

This daemon runs on the same host where the ml_path command is installed. It's aim is to route messages from the commands to an appropriate Optical Switch Agent and also for authentication. Any agent that runs on MonALISA Service will accept only authenticated OSD(s). The authentication is done using certificates, so when an OSD starts, it must have a private key in it's keystore and also it's public pair imported into MonALISA's keystore. Next steps should be followed before starting an OSD. There are helper scripts that can be found under  OSD/Security directory. The scripts are using keytool, which is the key and certificate management tool which is shipped with any jdk.

   1) Create a private key  ( genKey script in OSD/Security can be used )
   2) Export it's public pair key into a certificate ( exportKey script in the same directory can be used )
   3) Import the public key stored in previously generated certificate into MonALISA's keystore. ( there is a script called importCert in Service/SSecurity )

The communication between OSD and ml_* commands is done using Unix named pipes. When it is started, the OSD will check first if the pipes already exists, and if it has the right R/W access on them. If they do not exist, the daemon will try to create them. The pipes can also be created using mkfifo command, but they must have the right permissions on it. The reason to use Unix named pipes instead of sockets was because it is easy to administrate the R/W access on them, while the overhead (e.g creating a SSL connection even if it is on the localhost) remains almost 0.

NOTE: The OSD requires Java 1.5! Please download the latest release from java.sun.com


Configuration parameters for OSD:

The following parameters must be specified in conf/OSDaemonConf.properties. In the current version the IP address and the port number of a listening agent must be specified in this file. 

lia.osdaemon.OSDaemon.useSSL=true
lia.osdaemon.OSDaemon.MLAgentAddress = <MonaLisa's Service hostname or IP address>
lia.osdaemon.OSDaemon.MLAgentPort = 25001

The MLAgentPort must be the same as the one specified in the ml.properties file of the service ( the lia.Monitor.Agents.OpticalPath.MLCopyAgent.xdrTCPPort  property ). The keystore used to hold the private key for the daemon and the keystore password must be also specified in the same configuration file.


lia.Monitor.KeyStore=/home/testuser/OSD/Security/OSD_keystore.ks

lia.Monitor.KeyStorePass=kpass

OSD uses Unix named pipes to communicate with ml_path command. By default the daemon will try to create the Unix pipes in $HOME/OSD/Security.

lia.osdaemon.OSDaemon.inputPipe=/home/testuser/OSD/Security/ML_OS_fifo_IN
lia.osdaemon.OSDaemon.outputPipe=/home/testuser/OSD/Security/ML_OS_fifo_OUT

ml_path command:

The ml_path command is used to establish and release an optical path between two end points. It has the following syntax:
ml_path [ --osi-config-file | -c OSI_config_file ] [-v] [-s] source destination "copyCMD"
-v, --verbose enable verbose
-h, --help help
-s, --simplex make a simplex end to end connection; if this parameter is not specified the connection will be full duplex
--osi-config-file, -c OSI_config_file
path to OSD configuration file. If this parameter is not specified it will try to read the configuration from ${HOME}/OSD/conf/OSDaemonConf.properties. This file is used to determine the Unix-pipes on which OSD listens for commands.
The source, destination and "copyCMD" are mandatory fields. They specify the endpoints that must be connected and a "copyCMD" used for transfer between and. The source and destination parameters must have the same name as the one specified in configuration file of the MLCopyAgent.

Examples

  • $./ml_path 10.10.10.1 10.10.10.2 "scp user1@10.10.10.1 user2@10.10.10.2"
  • The command will try to establish a full duplex optical path between two machines ( 10.10.10.1 and 10.10.10.2 ) and after that, if the optical path can be established, it will execute the command "scp user1@10.10.10.1 user2@10.10.10.2"
  • $./ml_path -s hostname1.example.edu honstname2.example.edu "sleep 5"
  • The command will try to establish a simplex optical path from hostname1.example.edu to hostname2.example.edu and after that, if the optical path can be established, it will "sleep" for 5 seconds. This kind of commands are good for testing if an optical path can be established between two end points.