The Plug-in Skeleton

The federation distribution includes a functional skeleton that illustrates handling the interface calls though it does not manipulate any external testbed. It does illustrate most of the support for creating plug-ins, including reading configuration files, creating access control databases that map to local permission structures, storing persistent state and allocating local resources. The skeleton merely assigns an non-negative integer to each request. The range of integers is set from a configuration file.

This page describes how to set-up and run the skeleton plug-in, as well as what it does. First, install the fedd software and its dependencies. Then configure it as below.

Configuration

These are the steps to configure the skeleton:

• Create a configuration directory that's readable by the user that the plugin will run as (probably your uid)
• make subdirectories in it called certs and userconf. The certs directory must be writeable.
• Copy skel.conf​ into thie configuration directory.
• Copy skel_access​ into the configuration directory
• Create a certificate representing a fedid in this directory.
• Copy guest.pem​ to your local machine. It need not be in the configuration directory.
• Follow the steps below to edit skel.conf​ for your installation.

If you put the certificate you created above into fedd.pem all you need to do is change the first line to include the full pathname to your configuration directory. Something like:

base: /my/config/directory

If you named the certificate something other than fedd.pem, you need to change the line that starts with cert_file: to point to your file. This means changing the pathname. For example if the certificate was called mycert.pem the line would change to:

cert_file: %(base)s/mycert.pem

If the certificate you created has a password, that password must be included as the cert_pwd parameter. For example:

cert_pwd: mypwd

In a real installation, including such passwords in the configuration file implies that the configuration file must be secured.

The next sections explains the contents of the configuration files in more detail, but you can skip ahead to running the plug-in if you perfer.

Configuration File Contents

The skel.conf​ file contains three sections, each set off by a section name in braces, e.g., [access]. We will explain this file section by section.

[DEFAULT]

The first section, [DEFAULT] contains parameters that will be expanded in later sections. The base parameter will be used in other pathnames, to avoid having to hard code each full pathname. In later sections,the %(base)s construction will expand to the contents of the base} parameter. This is a standard construction in a configuration file parsed by python's ​ConfigParser module. The value inside the %() is the variable to expand, which is followed by a single character for formatting. More information about these conventions is ​available.

[access]

The [access] section contains most of the plug-in configuration information. Field by field:

project_priority: false

This means that if two three level names match for the current request, give priority to the user match rather than the project match. Practically this has little effect on the skeleton.

log_level: debug

Log messages at or above log.DEBUG level will be printed to stderr or a log file.

access_state: %(base)s/skel_access.state

The persistent state of the plug-in will be stored in this file (skel_access.state in the base directory). The plug-in will create this file if it is not there and state needs to be stored.

accessdb: %(base)s/skel_access

The access database is in skel_access in the base directory. We will discuss the contents of that file below.

certdir: %(base)s/certs

This directory is used to store transient certificates. It should be readable only by the federation user.

userconfdir: %(base)s/userconf

Used to store information about exported user configurations. Again, it should be readable only by the federation user.

maxint: 3

The maximum integer that the skeleton will allocate is 3. This is not inclusive, so the skeleton will actually allocate from {0,1,2,}.

A line of the form create_debug: true is commented out. When true, that parameter generally means that the plug-in will not make allocations when requests come in. Because the skeleton only manipulates its internal state, the parameter is not used.

There are other common attributes in this section that are left as defaults in the example file, and defined elsewhere.

[globals]

The two or three parameters in this section control overall operation of the plug-in, specifically what prinicpal ID (that is which fedid) it uses and what TCP port it provides services on. cert_file and cert_pwd select the X.509 certificate and encyrption password, if any, used to identify the plug-in. The services parameter controls which ports and transports are used. The sample file serves SOAP traffic on port 13230. Other choices are possible.

The access_type parameter chooses the type of access controller to run, in this case skel for the skeleton controller.

The Access Database

The access database​ has only one entry in it, which allows access from a user guest in the testing project project when asserted by fedid b55205ac843c40ce9c9feb3b358bff782ed337fd. That fedid is the one asserted by the fedd experiment controller running at DETER.

For testing plug-ins the DETER experiment controller will permit anyone connecting with the fedid encoded in the guest.pem​ file to request operations with that three-level name. Once your plug-in does something interesting, you should reduce or eliminate the access rights of that user.

The rest of the line gives that user access permissions and the local permission state Local_attr. This is more to show how to assign such allocations, which will be meaningful in real installations. For example, see the configurations of other plug-ins.

Running the Skeleton

To start the plug-in, assuming that the configuration files are in /usr/local/etc/skel run the command:

$ fedd.py --config=/usr/local/etc/skel.conf --debug

This assumes you have properly installed fedd and that fedd.py is in your path. You will see a few log messages indicating that the access and state databases have been read or are not yet created.

To see the skeleton do something