Geni Registry Wrapper This wrapper implements the Geni Registry. There are several items that need to be done before starting the registry. 1) Update util/config.py to match the parameters of your PLC installation. 2) Import the existing planetlab database, creating the appropriate geni records. This is done by running the "import.py" tool. 3) Create a "trusted_roots" directory and place the certificate of the root authority in that directory. Given the defaults in import.py, this certificate would be named "planetlab.gid". For example, mkdir trusted_roots; cp authorities/planetlab.gid trusted_roots/
Convert geni fields to PLC fields for use when registering up updating registry record in the PLC database
Registry is a GeniServer that serves registry requests.
For more information about this class, see The Registry Class.
Registry is a GeniServer that serves registry requests. It also serves component and slice operations that are implemented on the registry due to SFA engineering decisions
Connect to a local shell via local API functions
Connect to a remote shell via XMLRPC
GENI_API: Create_gid Create a new GID. For MAs and SAs that are physically located on the registry, this allows a owner/operator/PI to create a new GID and have it signed by his respective authority.
Determine tje rights that an object should have. The rights are entirely dependent on the type of the object. For example, users automatically get "refresh", "resolve", and "info".
Fill in the geni-specific fields of the record. Note: It is assumed the fill_record_pl_info() has already been performed on the record.
Given a Geni record, fill in the PLC-specific and Geni-specific fields in the record.
Fill in the planetlab-specific fields of a Geni record. This involves calling the appropriate PLC methods to retrieve the database record for the object. PLC data is filled into the pl_info field of the record.
Given an authority name, return the information for that authority. This is basically a stub that calls the hierarchy module.
Given an authority name, return the database table for that authority. If the database table does not exist, then one will be automatically created.
GENI API: Get_credential Retrieve a credential for an object. If cred==None, then the behavior reverts to get_self_credential()
GENI API: get_gid Retrieve the GID for an object. This function looks up a record in the registry and returns the GID of the record if it exists. TODO: Is this function needed? It's a shortcut for Resolve()
GENI API: Get_self_credential Get_self_credential a degenerate version of get_credential used by a client to get his initial credential when he doesn't have one. This is the same as get_credential(..., cred=None,...). The registry ensures that the client is the principal that is named by (type, name) by comparing the public key in the record's GID to the private key used to encrypt the client-side of the HTTPS connection. Thus it is impossible for one principal to retrieve another principal's credential without having the appropriate private key.
GENI API: get_ticket Retrieve a ticket. This operation is currently implemented on the registry (see SFA, engineering decisions), and is not implemented on components. The ticket is filled in with information from the PLC database. This information includes resources, and attributes such as user keys and initscripts.
List the records in an authority. The objectGID in the supplied credential should name the authority that will be listed. TODO: List doesn't take an hrn and uses the hrn contained in the objectGid of the credential. Does this mean the only way to list an authority is by having a credential for that authority?
Look up user records given PLC user-ids. This is used as part of the process for reverse-mapping PLC records into Geni records.
Convert a PLC record into the slice information that will be stored in a ticket. There are two parts to this information: attributes and rspec. Attributes are non-resource items, such as keys and the initscript RSpec is a set of resource specifications
GENI API: register Register an object with the registry. In addition to being stored in the Geni database, the appropriate records will also be created in the PLC databases
Register the server RPCs for the registry
GENI API: remove Remove an object from the registry. If the object represents a PLC object, then the PLC records will also be removed.
GENI API: Resolve This is a wrapper around resolve_raw that converts records objects into dictionaries before returning them to the user.
Resolve a record. This is an internal version of the Resolve API call and returns records in record object format rather than dictionaries that may be sent over XMLRPC.
GENI API: Register Update an object in the registry. Currently, this only updates the PLC information associated with the record. The Geni fields (name, type, GID) are fixed. The record is expected to have the pl_info field filled in with the data that should be updated. TODO: The geni_info member of the record should be parsed and the pl_info adjusted as necessary (add/remove users from a slice, etc)
Verify that an authority belongs to this registry. This is basically left up to the implementation of the hierarchy module. If the specified name does not belong to this registry, an exception is thrown indicating the caller should contact someone else.
Verify that an object belongs to this registry. By extension, this implies that the authority that owns the object belongs to this registry. If the object does not belong to this registry, then an exception is thrown.
Verify that the object_gid that was specified in the credential allows permission to the object 'name'. This is done by a simple prefix test. For example, an object_gid for planetlab.us.arizona would match the objects planetlab.us.arizona.slice1 and planetlab.us.arizona.