Version 14 (modified by ibaldin, 5 years ago)



Setting up $ORCA_CONTROLLER_HOME generally follows the same philosophy as $ORCA_HOME. The difference is that the controller is not an ORCA actor, but rather a remote policy that connects to the SM actor (only to the SM actor!). Therefore, the controller must be configured to connect to an SM actor.

Note that the file has been replaced with The structure of the file is largely the same as before with a few additional properties related to running the controller as a standalone application.

The xmlrpc.user.whitelist file remains the same.


$ export ORCA_CONTROLLER_HOME=/opt/orca-controller

Create a default configuration

It is easiest to check out the sample configuration from SVN and then customize it:



  • orca.manage.url points to the URL of the Jetty container running the SM with which this controller associates
  • orca.manage.[user, password] are the login and password of the admin user on the SM container configured in orca.manage.url
  • is the GUID of the SM actor to which this controller connects (defined in $ORCA_HOME/config/config.xml)
  • logging properties should be left unmodified
  • the controller now requires two .jks files:
    • geni-trusted.jks truststore which contains the trust roots for this controller to authenticate users - this affects which users are allowed to connect
    • xmlrpc.jks keystore which contains the private key and certificate of the controller when it acts as SSL server - this should be generated for each new installation

Generating xmlrpc.jks

The password for the key as well as the keystore should be the same and should be specified as xmlrpc.controller.keystore.pass property in file

$ keytool -keystore xmlrpc.jks -storetype jks -alias jetty -genkey -validity 3650 -keyalg RSA

Make sure that keystore and key passwords are identical:

Enter keystore password:  
Keystore password is too short - must be at least 6 characters
Enter keystore password:  
Re-enter new password: 
What is your first and last name?
  [Unknown]:  <FQDN of the host>
What is the name of your organizational unit?
  [Unknown]:  ExoGENI
What is the name of your organization?
  [Unknown]:  RENCI
What is the name of your City or Locality?
  [Unknown]:  Chapel Hill
What is the name of your State or Province?
  [Unknown]:  NC
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=<FQDN of the host>, OU=ExoGENI, O=RENCI, L=Chapel Hill, ST=NC, C=US correct?
  [no]:  yes

Enter key password for <jetty>
	(RETURN if same as keystore password):  
Re-enter new password: 

Getting the geni-trusted.jks

In general you can create your own truststore with whatever trust roots you wish. To be part of GENI federation you should use the attached geni-trusted.jks. The name of this jks file and the password to it should be saved in as credential.truststore.location (as related to ORCA_CONTROLLER_HOME) and credential.truststore.password.

Publishing slice manifests to XMPP

ORCA XMLRPC controller has a feature that allows it to publish manifests of all slices (and their evolution) to a pre-configured XMPP server. This is a scalable notification mechanism that can be used in a number of ways. Currently it is used to both send information about slices to GMOC, as well as save information about slices into a database for meta-analysis.

# This is the xmpp user id (JID), which has to be same as the CN in the certificate, which is a guid


The whitelist controls the users that are allowed to access this controller. In addition to having a certificate signed by one of the trusted roots (configured via geni-trusted.jks), user's DN must match a string patter defined in this file. The file can be modified at runtime. More information on the structure of the file is here.