= The Plug-in Skeleton = The federation distribution includes a functional skeletion that illustrates handling the [FeddPluginCalls 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. == 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 [attachment:skel.conf] into thie configuration directory. * Copy [attachment:skel_access] into the configuration directory * [FeddConfig#MakingaFedidCertificate Create a certificate representing a fedid] in this directory. * Copy [attachment:guest.pem] to your local machine. It need not be in the configuration directory. * Follow the steps below to edit [attachment: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 section 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 [attachment: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 [http://docs.python.org/library/configparser.html 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 [http://docs.python.org/library/configparser.html available]. === [access] === The {{{[access]}}} section contains most of the plug-in configuration information. Field by field: '''project_priority: false''':: This means that if two [FeddAbout#GlobalIdentifiers:Three-levelNames 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 [FeddConfig#AccessOptions 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 [FeddAbout#GlobalIdentifiers:Fedids 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. [FeddConfig#GlobalOptions Other choices] are possible. == The Access Database == The [attachment:skel_access access database] has only one entry in it, which allows access from a user '''guest''' in the '''testing''' project project when asserted by [FeddAbout#GlobalIdentifiers:Fedids 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 [attachment:guest.pem 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.