Skip to content

CBAS_clearinghouse

Jump to bottom
Umar Toseef edited this page Sep 21, 2015 · 10 revisions

Home > Experimenting > CH > CBAS clearinghouse

Preparing the OMNI user and its project

The user configured in omni_config file (default is 'bob') must be registered with CBAS through AdminTool. For this purpose, follow these steps:

  1. Run the java admin tool of CBAS in a X11-enabled environment:
java -jar <path_to_cbas>/javaadmintool/bin/admintool.jar
  1. Goto 'Members' tab and register a new member with desired username (e.g., bob). When it's prompted, save the certificate and private key on local machine. NOTE: Certificate key is not stored on the server and therefore can be saved only once.
  2. Place saved certificate (e.g., bob-cert.pem) and certificate key (e.g., bob-key.pem) under ~/.gcf/ folder.
  3. If desired you may provide Public SSH key for new user with button 'Edit SSH Key'
  4. In AdminTool goto 'Projects' tab and create a new project called 'default'
  5. Add the new user (e.g., bob) to the project
  6. Change the role of the new user (or any other) to 'ADMIN' to allow him create slices

Adding CBAS to trusted roots

  1. Add the certificates of CA, MA, and SA to the RMs (CRM, SDNRM)

  • Add it as a new .gid file (you pick the name) to the trusted_roots folder of vt_manager:

    # CRM
cp -p <path_to_cbas>/deploy/trusted/certs/ca-cert.pem <path_to_ocf>/vt_manager/src/python/vt_manager/communication/geni/v3/trusted_roots/felix-<organisation>-cbas-ca.gid
cp -p <path_to_cbas>/deploy/trusted/certs/ma-cert.pem <path_to_ocf>/vt_manager/src/python/vt_manager/communication/geni/v3/trusted_roots/felix-<organisation>-cbas-ma.gid
cp -p <path_to_cbas>/deploy/trusted/certs/sa-cert.pem <path_to_ocf>/vt_manager/src/python/vt_manager/communication/geni/v3/trusted_roots/felix-<organisation>-cbas-sa.gid
# SDNRM
cp -p <path_to_cbas>/deploy/trusted/certs/ca-cert.pem <path_to_ocf>/optin_manager/src/python/openflow/optin_manager/geni/v3/trusted_roots/felix-<organisation>-cbas-ca.gid
cp -p <path_to_cbas>/deploy/trusted/certs/ma-cert.pem <path_to_ocf>/optin_manager/src/python/openflow/optin_manager/geni/v3/trusted_roots/felix-<organisation>-cbas-ma.gid
cp -p <path_to_cbas>/deploy/trusted/certs/sa-cert.pem <path_to_ocf>/optin_manager/src/python/openflow/optin_manager/geni/v3/trusted_roots/felix-<organisation>-cbas-sa.gid

  • Note: ensure that this file is unique, i.e. not previously saved under other name or coincident

  1. Add the certificates of CA, MA, and SA to the GCF folder

  • Copy those to ~/.gcf/trusted_roots:

    cp -p <path_to_cbas>/deploy/trusted/certs/ca-cert.pem ~/.gcf/trusted_roots/felix-<organisation>-cbas-ca.gid
cp -p <path_to_cbas>/deploy/trusted/certs/ma-cert.pem ~/.gcf/trusted_roots/felix-<organisation>-cbas-ma.gid
cp -p <path_to_cbas>/deploy/trusted/certs/sa-cert.pem ~/.gcf/trusted_roots/felix-<organisation>-cbas-sa.gid

  • Note: ensure that this file is unique, i.e. not previously saved under other name or coincident

  1. Append the MA certificates to the Apache SSL file
  • Take certificate from <path_to_cbas>/deploy/trusted/certs/ma-cert.pem
  • Append the contents to the end of the /etc/apache2/ssl.crt/ca_clients.crt file
  • Restart Apache

Retrieving credentials for OMNI user

  • Use getusercred command to retrieve user credentials and place them under ~/.gcf/ folder
  • python src/omni.py -f my_cbas --usercredfile ~/.gcf/bob-cred.xml -o getusercred
  • NOTE By using -f my_cbas option we are telling omni to use my_cbas framework configuration from ~/.gcf/omni_config file

OMNI commands

After your environment is properly set up and configured, you will be able to send requests against the GENI APIs of the FELIX RMs using OMNI as described in this section.

Also, take care to change $am_address/$endpoint by:

  1. $am_address: the URI of each FELIX RM. This information is known to each Island Administrator
  2. $endpoint: path where the RM's GENIv3 server runs:
  • RO, CRM, SDNRM, SERM: /xmlrpc/geni/3/
  • TNRM: / (eiSoil-based RMs)

See OMNI help for a list of supported commands. The following are few typical calls using the GENIv3 API to contact RO, CRM, SDNRM or SERM:

# Create a slice and save its credentials under `~/.gcf/mySliceCred.json`
python src/omni.py -f my_cbas -V3 createslice "testslice" \ 
      "2015-12-31T15:00:00+01:00" --cred ~/.gcf/bob-cred.xml  \ 
      --debug -o --slicecredfile ~/.gcf/mySliceCred.json

# Retrieve version and meta information of the RM
python src/omni.py -f my_cbas -o -a $am_address/xmlrpc/geni/3/ -V 3 --debug \
                   getversion 

# Retrieve list of resources provided by the RM
# (e.g. servers for CRM/VTAM, switches for SDNRM/OFAM)
python src/omni.py -f my_cbas -o -a $am_address/xmlrpc/geni/3/ -V 3 --debug \
                   --no-compress listresources

# Retrieve contents (slivers) belonging to a given slice
python src/omni.py -f my_cbas -V3 -o -a $am_address/xmlrpc/geni/3/ -V 3 --debug \
                   describe "testslice" --cred ~/.gcf/bob-cred.xml

# Reserve/Allocate resources within a slice.
# (Parameter "--end-time" optional)
python src/omni.py -f my_cbas -o -a $am_address/xmlrpc/geni/3/ -V 3 --debug \
                   allocate "testslice" rspec-req.xml \
                   --end-time=2014-04-12T23:20:50.52Z \
                   --slicecredfile ~/.gcf/mySliceCred.json

NOTE:

  • Use --cred ~/.gcf/bob-cred.xml option where ever user credentials needed to be passed. User credentials can be obtained any time using getusercred command as explained above. In general user credentials are required for clearinghouse related operations, e.g., to create a slice etc.
  • Use --slicecredfile ~/.gcf/mySliceCred.json option to pass slice credentials when calling AM API functions. Slice credentials can be obtained any time using getslicecred command, e.g.,
python src/omni.py -a $am_address/xmlrpc/geni/3/ -V3 -f my_cbas getslicecred "testXP" -o --slicecredfile ~/.gcf/mySliceCred.json

OMNI does not overwrite existing files, therefore it is recommended to delete the slice credential file if it already exists before running the above command.

Delegating slice credential

Slice members may bestow their privileges on other members through credential delegation. Both OMNI and C-BAS support delegated credentials. Let's assume Bob has a slice named testslice and he wants to delegate his credentials for this slice to Alice. This require following steps

  1. Use getusercred command to retrieve user credentials of Bob
  • python src/omni.py -f my_cbas --usercredfile ~/.gcf/bob-cred.xml -o getusercred
  1. Fetch slice credentials
  • python src/omni.py getslicecred testslice --cred ~/.gcf/bob-cred.xml -o --slicecredfile sliceCredBob.xml
  1. Use OMNI's script to delegate credentials to Alice. This step assumes that Bob's certificate and key are placed under ~/.gcf/ folder and Alice's certificate is placed under ./alice-cert.pem
  • src/delegateSliceCred.py --cert ~/.gcf/bob-cert.pem --key ~/.gcf/bob-key.pem --slicecred sliceCredBob.xml --delegeegid ./alice-cert.pem

The last command will generate delegated credentials with name similar to cbas--eict--de-alice-delegated-sliceCredBob.xml. These delegated credentials can be used by Alice, for example, to renew slice at C-BAS or reserve resources at RMs as explained in above section.

Troubleshooting

Cannot create slice credential

If you cannot obtain a credential after using the createslice command and you see a message similar to "INFO : Slice Authority is urn:publicid:IDN+cbas.i2cat.net+authority+sa https://localhost:8008/sa/1", then the CBAS database may have old entries that shall be removed. For that, write the following:

# Access MongoDB
mongo
# Set into proper database
>>> use ohouse
# Delete conflicting collection
>>> db.endpoint.drop()
Clone this wiki locally