- Overview
- Usage - Configuration examples and options
- Reference - Parameter and detailed reference to all options
- Limitations - OS compatibility, etc.
- Development - Guide for testing and contributing to the module
The OSG module manages the various components that make up the Open Science Grid software stack.
Currently this module supports OSG 3.5.
The current version support matrix is as follows:
| OSG Versions | 3.3 | 3.4 | 3.5 |
|---|---|---|---|
| puppet-osg 1.x | yes | no | no |
| puppet-osg 2.x | yes | yes | no |
| puppet-osg 3.x | yes | yes | no |
| puppet-osg 4.x | no | yes | no |
| puppet-osg 5.x | no | no | yes |
The public classes of this module are split into "roles". For example a CE would use the class osg::ce.
The OSG class is required by all the other classes. This class sets parameters that are used by multiple "roles" and is the class responsible for configuring the OSG repos.
class { 'osg': }If all systems pull their grid-certificates from a shared filesystem then you instruct this module to install the empty-ca-certs package and symlink /home/osg/grid-certificates to /etc/grid-security/certificates. If this method is used some script must be executed on a regular basis to sync one system's certificates into the shared location. Such a script is currently outside the scope of this module.
class { 'osg':
shared_certs_path => '/home/osg/grid-certificates',
cacerts_package_name => 'empty-ca-certs',
}The cacerts_package_ensure parameter can be used to ensure the latest CA certs package is installed. This is basically the same functionality as provided by the resources managed under the osg::cacerts::updater class.
class { 'osg':
cacerts_package_name => 'osg-ca-certs',
cacerts_package_ensure => 'latest',
}The osg::cacerts::updater class by default will perform the following actions
- Install
osg-ca-certs-updaterandfetch-crlpackages - Configure
/etc/cron.d/osg-ca-certs-updater - Start the
osg-ca-certs-updater-cronservice - Start the
fetch-crl-cronservice - Stop the
fetch-crl-bootservice
Example usage:
class { 'osg':
cacerts_package_name => 'osg-ca-certs',
}
class { 'osg::cacerts::updater': }This class essentially performs the same role as setting osg::cacerts_package_ensure and osg::cacerts_other_packages_ensure to latest.
This class by default configures a HTCondor CE. The following example is to configure using HTCondor-CE that uses the SLURM batch system. This example also shows how to setup a host as the system that keeps the shared grid-certificates up-to-date.
class { 'osg':
site_info_resource => 'SITE_CE',
site_info_resource_group => 'SITE',
site_info_sponsor => 'vo-name-here',
site_info_site_policy => '',
site_info_contact => 'Full Name'
site_info_email => '[email protected]'
site_info_city => 'Somewhere'
site_info_country => 'USA'
site_info_longitude => '-0.000000'
site_info_latitude => '0.000000'
}
class { 'osg::ce':
batch_system => 'slurm',
hostcert_source => 'file:///home/admin/osg/certs/ce/hostcert.pem',
hostkey_source => 'file:///home/admin/osg/certs/ce/hostkey.pem',
}The osg::client class is intended to configure client systems, such as login nodes, to interact with the OSG software. The example below is a rough idea of how one would configure a client system to send both condor and condor-ce requests to a remote HTCondor-CE instance.
class { 'osg::client'
condor_schedd_host => 'ce.example.tld',
condor_collector_host => 'ce.example.tld:9619',
}The default behavior is to ensure both condor and htcondor-ce are installed but the services for each are disabled.
The osg::cvmfs class will install and configure a system to access the CVMFS wide-area filesystem. The default parameter values should be enough to allow access to the filesystem.
class { 'osg::cvmfs': }Any host that needs to access /cvmfs should have this class assigned.
The osg::gridftp class by default will configure a system as a standalone OSG GridFTP server. Note that the osg::ce classes declares this class with standalone set to false, so do not include this class if the osg::ce class is assigned.
class { 'osg':
site_info_resource => 'SITE_GRIDFTP',
site_info_resource_group => 'SITE',
site_info_sponsor => 'vo-name-here',
site_info_site_policy => '',
site_info_contact => 'Full Name'
site_info_email => '[email protected]'
site_info_city => 'Somewhere'
site_info_country => 'USA'
site_info_longitude => '-0.000000'
site_info_latitude => '0.000000'
}
class { 'osg::gridftp':
hostcert_source => 'file:///home/admin/osg/certs/gridftp/hostcert.pem',
hostkey_source => 'file:///home/admin/osg/certs/gridftp/hostkey.pem',
}The following example will setup LCMAPS VOMS to authenticate the GLOW VO and ban CMS production. The vo parameter will create osg::lcmaps_voms::vo resources and the users parameter will create osg::lcmaps_voms::user resources.
class { 'osg::lcmaps_voms':
ban_voms => ['/cms/Role=production/*'],
ban_users => ['/foo/baz'],
vos => {
'glow' => '/GLOW/*',
'glow1 => '['/GLOW/chtc/*', '/GLOW/Role=htpc/*'],
},
users => {
'foo' => '/fooDN',
'foobar => ['/foo', '/bar'],
}
}This defined type populates /etc/grid-security/voms-mapfile. The dn value can be an Array or a String.
osg::lcmaps_voms::vo { 'nova':
dn => '/fermilab/nova/Role=pilot',
}This defined type populates /etc/grid-security/grid-mapfile. The dn value can be an Array or a String.
osg::lcmaps_voms::user { 'rsv':
dn => '/DC=org/DC=opensciencegrid/O=Open Science Grid/OU=Services/CN=rsv/ce.example.com',
}The osg::squid class will configure a system to run the Frontier Squid service. The example below installs squid and configures the firewall to allow access to squid on the host's eth0 private interface and allows squid monitoring on the eth1 public interface.
class { 'osg::squid':
private_interface => 'eth0',
public_interface => 'eth1',
}Be sure to define squid_location that points to the location of the squid server
class { 'osg':
squid_location => 'squid.site.com',
}The customize_template can be used to pass a site-specific template used to customize squid. The template provided by this module is very basic. The value in the example below will look in the site_osg Puppet module under templates/squid for the file customize.sh.erb. The value of customize_template is passed directly to the Puppet template function.
class { 'osg::squid':
customize_template => 'site_osg/squid/customize.sh.erb',
}The osg::utils class will install utility packages from OSG.
Example:
class { 'osg::utils':}The osg::wn class will configure a worker node to work with the OSG software. This class currently has no parameters and performs the following actions:
- Ensures the osg class is included (repo)
- Ensures the osg::cacerts class is included
- Installs osg-wn-client package
- Installs xrootd-client
Example:
class { 'osg::wn': }The osg_local_site_settings custom type will configure values in /etc/osg/config.d/99-local-site-settings.ini. Some of the values are set in this module's classes. One example of a value not currently managed (though may be in the future):
osg_local_site_settings { 'Storage/se_available':
value => true,
}Note that boolean values of true and false are converted to the Python bool values of True and False.
The osg_gip_config custom type will configure values in /etc/osg/config.d/30-gip.ini. Example of setting your batch system to SLURM.
osg_gip_config { 'GIP/batch':
value => 'slurm',
}You can also remove the settings defined in 30-gip.ini and use the osg_local_site_settings type to define all configs in /etc/osg/config.d/99-local-site-settings.ini
resources { 'osg_gip_config': purge => true }
osg_local_site_settings { 'GIP/batch':
value => 'slurm',
}This can be useful as the 99-local-site-settings.ini does not take precedence in GIP like it does with osg-configure (ref).
http://treydock.github.io/puppet-osg/
Tested operating systems:
- RedHat/CentOS 7
This module has only been thoroughly tested using OSG 3.5.
Testing requires the following dependencies:
- rake
- bundler
Install gem dependencies
bundle install
Run unit tests
bundle exec rake spec
If you have Docker installed you can run system tests.
bundle exec rake beaker