U-Bolt currently consists of NSS and PAM modules, summarized as follows.
See doc/*.txt for deeper details.

A presentation to the OSG CIC group was given on 22 Feb 2013 covering much
of the motivation, behavior, and implementation of the U-Bolt tools.  You
can find the slide deck here:



  nss_identity provides a means of fabricating POSIX nameservice entries
  based upon information present in the request and (perhaps) elsewhere
  within the nsswitch framework, but without reference to an external
  source of authority.  This is primarily useful for fabricating
  identities: a 1:1 mapping of numeric IDs to predictably corresponding
  text representations.


  nss_filter is a preliminary effort at an NSS library that authoritatively
  sources nothing, but can filter results from other libraries.  It is
  currently quite limited: it is capable of filtering only passwd, and it
  can only perform one type of filtering: replacing a '&' token with the
  user login ID (``pw_name``).  This is sufficient proof of concept and
  adequate to our current need, but it should be extended:

  * because it can be, and it is not complete;
  * because it only offers one type of filter that is hardcoded.


  pam_provision.so is a PAM module to assist in automatic account
  provisioning.  It assumes that some kind of functioning POSIX account
  information is available through the name service switch: nss_files,
  nss_ldap, whatever.  If you can provide the account information,
  pam_provision can do whatever is necessary on the local system to
  make the account function.  This could be as minor as creating a home
  directory, or it could involve other elements of session management.
  Pam_provision's only job is to call the program you tell it to.  This
  provisioner program can be a shell script or a program in any other
  language.  An example provisioner written in Python is included with
  this distribution.

  pam_provision.so was developed on and for Solaris, and has been
  ported to Linux.  It should work for other PAM platforms as well.

  Astute readers will wonder what's wrong with pam_exec, and why we
  think we need something that does basically the same thing.  There
  are two reasons: (a) pam_exec was not available when pam_provision
  was developed, and was not portable to Solaris when it did arrive;
  (2) many releases of pam_exec, including all those through RHEL 5,
  did not support passing context information to the executed program
  in any fashion, as with pam_provision's %u, %s, etc variables.  Later
  versions of pam_exec do this via the environment, and pam_provision
  now supports this too.

  pam_provision is not really necessary as of RHEL 6, but is included
  here for historical reasons, and because some of its internals will
  prove useful for future PAM modules.