Forge Home


Manage DB2 server and client installation and instances


15,237 latest version

4.6 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 1.3.1 (latest)
  • 1.3.0
  • 1.2.1
  • 1.2.0
  • 1.1.1
  • 1.1.0
  • 1.0.1
  • 1.0.0
  • 0.3.1
  • 0.3.0
  • 0.2.0
  • 0.1.2
  • 0.1.1
  • 0.1.0
released Apr 28th 2017
This version is compatible with:
  • , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'crayfishx-db2', '1.3.1'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add crayfishx-db2
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install crayfishx-db2 --version 1.3.1

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



crayfishx/db2 — version 1.3.1 Apr 28th 2017

Build Status

Puppet DB2 module


  1. Introduction
  2. Prerequisites
  3. Usage
  1. Types and providers
  1. Testing


This module configures DB2 server and runtime client installations and configures instances.


The DB2 software package ships as an tarball and should be placed either in a Puppet file location, HTTP server or other source location compatible with the archive type from puppet/archive. For testing, the 90 day trial of DB2 server can be downloaded from The IBM DB2 download center

Numerous packages and other settings are required in order to support DB2 server, it is recommended that you run the pre-check script from DB2 on the system that you intend to deploy this module to and update your roles/profiles with the relevant pre-reqs for your system. The script can be found in the source tarball and can be run as

# ./db2prereqcheck -l

Some warnings can be ignored, please see the IBM documentation for more information


This module includes two defined resource types, db2::install and db2::instance. db2::install is a defined resource type, and not a class, because it's possible to install multiple versions of DB2 server side by side on the same server, so this module allows for that. Note that the db2 baseclass must be included before declaring db2::instance types in your manifests in order for certain variables and dependencies to be set.

This module has only been tested for DB2 10.5, but should work for earlier versions


Usage example for DB2 Server

db2::install { '10.5':
  source     => '',
  components => [
  license_content => template('db2/license/trial.lic'),

Usage example for DB2 Runtime client

db2::install { '11.1':
  source     => '',
  product    => 'RUNTIME_CLIENT',
  components => [
  configure_license => false,


  • version: set the version of DB2 to be installed (defaults to the resource title)
  • extract: Whether or not to download and extract the source file (default: true)
  • source: Source location of the tar.gz file, supports http,ftp,puppet and file URI's (see archive)
  • filename: Filename of the destination tarball, defaults to filename derived from source
  • installer_root: The root directory of where the tarballs and extracted archives are stored. (default: /var/puppet_db2)
  • installer_folder: The sub-folder relative to installer_root where the installer executables are stored.
  • install_dest: The target installation folder (default: /opt/ibm/db2/V)
  • product: The DB2 product ID (default: DB2_SERVER_EDITION)
  • components: An array of components to install
  • languages: An array of languages to install (default: [ 'EN' ])
  • configure_license: Whether or not to configure the license
  • license_content: The license content as a string (cannot use with license_source)
  • license_source: The source of the license as a file source parameter (cannot use with license_content)


Usage example for a DB2 server instance

  db2::instance { 'db2inst1':
    fence_user        => 'db2fenc1',
    installation_root => '/opt/ibm/db2/V10.5',
    require           => Db2::Install['10.5'],

Usage example for a DB2 Runtime Client instance

  db2::instance { 'db2inst1':
    installation_root => '/opt/ibm/db2/V11.1',
    type              => 'client',
    require           => Db2::Install['11.1'],


  • instance_user: The username for the instance (defaults to resource title)
  • fence_user: The username of the fence user (optional, must be specified for a non-client instance)
  • installation_root: The root of the DB2 installation for this instance
  • manage_fence_user: Whether or not to manage the fence user resource (default: true)
  • fence_user_uid: UID of the fence user
  • fence_user_gid: GID of the fence user
  • fence_user_home: Home directory of the fence user
  • manage_instance_user: Whether or not to manage the instance user resource (default: true)
  • instance_user_uid: UID of the instance user
  • instance_user_gid: GID of the instance user
  • instance_user_home: Home directory of the instance user
  • type: Type of product this instance is for (default: ese)
  • auth: Type of auth for this instance (default: server)
  • users_forcelocal: Force the creation of instance and fence users to be local, true or false. (default: undef)
  • port: Optionally specify a port name for the instance (default: undef)
  • catalog_databases: A hash of db2_catalog_database resources to pass to create_resources
  • catalog_nodes: A hash of db2_catalog_node resources to pass to create_resources
  • catalog_dcs: A hash of db2_catalog_dcs resources to pass to create_resources


The db2 base class takes installations and instances as parameters and farms these to create_reosurces to dynamically create DB2 installs and instances from Hiera data.

Usage sample

include db2

Hiera example for DB2 Server Installations

    source:  ''
      - ACS

    license_content: |
      VendorName=IBM Toronto Lab
    fence_user: db2fenc1
    installation_root: /opt/ibm/db2/V10.5

Hiera example for DB2 Runtime Client installations

    product: RUNTIME_CLIENT
    configure_license: false
    type: client
    instance_user_uid: 10111
    installation_root: /opt/ibm/db2/V11.1

Types and Providers

Numerous native types and providers exist to manage aspects of DB2 instances, these are documented below


Configures a DB2 instance. The instance user must already exist (the db2::instance defined type does this for you).

Example usage

db2_instance { 'db2inst1':
  install_root => '/opt/ibm/db2/V11.1',
  type         => client,
  fence_user   => 'db2fence1',
  auth         => 'server',


  • install_root: Path to the root of the DB2 installation (required)
  • auth: Authentication type (eg: server) (required)
  • type: Type of instance (eg: ese, client) (required)
  • fence_user: The name of the fence user (must already exist with a valid homedir)
  • port: The port name of the instance

The instance user and fence user will be autorequired by this type, but they must exist already or be in the catalog if calling this type directly.


The db2_catalog_node resource type manages the catalog entries for nodes on DB2 instances

Example usage

db2_catalog_node { 'db2node1':
  instance     => 'db2inst1',
  install_root => '/opt/ibm/db2/V11.1',
  type         => 'tcpip',
  remote       => '',
  server       => 'db2srv',
  security     => 'ssl',

Would run the following



  • install_root: Path to the root of the DB2 installation (required)
  • instance: The name of the instance to configure (required)
  • type: The type of node, currently supported are tcpip and local
  • to_instance: Name of the instance referred to in the catalog command, not the instance that we are configuring
  • admin: When set to true specifies an administration server (tcpip only)
  • remote: The hostname or IP address where the database resides (tcpip only)
  • server: The service name or port number of the database manager instance (tcpip only)
  • remote_instance: Specifies the name of the server instance where the database resides (tcpip only)
  • security: Specifies the node will be security enabled, valid values are socks and ssl (tcpip only)
  • system: Specifies the DB2 system name that is used to identify the server machine
  • ostype: Specifies the OS type of the server machine (AIX, WIN, HPUX, SUN, OS390, OS400, VM, VSE, SNI, SCO, LINUX and DYNIX.)
  • comment: A description of the catalog entry

The db2_catalog_node resource type will automatically require the corresponding db2_instance resource if it is in the catalog


The db2_catalog_database resource type manages catalog entries for databases on DB2 instances.

Usage example

db2_catalog_database { 'DB2DBXX':
  instance       => 'db2inst1',
  install_root   => '/opt/ibm/db2/V11.1',
  node           => 'MYNODE2',
  authentication => 'dcs',

Would run the following



  • install_root: Path to the root of the DB2 installation (required)
  • instance: The name of the instance to configure (required)
  • as_alias: The alias of the database entry. This attribute is also the namevar, so if ommited, the resource title will be used as the alias name, this is the unique identifier for the resource
  • db_name: The database name to catalog, if this option is ommited then the as_alias (or the resource title) will be used as the database name
  • path: Specify the path where the database resides (cannot use with node)
  • node: Specify the name of the database partition server where the database resides (cannot use with path)
  • authentication: Specify an authentication type (SERVER, CLIENT, SERVER_ENCRYPT..etc)
  • comment: A description of the catalog entry

Title patterns

The as_alias attribute is the resource type's namevar, a short hand notation also exists to map both the as_alias and db_name attributes from the title of the resource using a comma delimited string as the title. Therefore, this example;

db2_catalog_database { 'DB2 Database X':
  instance       => 'db2inst1',
  install_root   => '/opt/ibm/db2/V11.1',
  as_alias       => 'DB2X',
  db_name        => 'DB2DBFOO',
  node           => 'MYNODE2',
  authentication => 'dcs',

... can be written as...

db2_catalog_database { 'DB2X:DB2DBFOO'
  instance => 'db2inst1',
  install_root => '/opt/ibm/db2/V11.1',
  node    => 'MYNODE2',
  authentication => 'dcs',


The db2_catalog_dcs resource type manages catalog entries for database connection services (DCS) within a DB2 instance.

Usage example

db2_catalog_dcs { 'DB2DB1':
  instance     => 'db2inst1',
  install_root => '/opt/ibm/db2/V11.1',
  target       => 'dsn_db_1',

Would run



  • install_root: Path to the root of the DB2 installation (required)
  • instance: The name of the instance to configure (required)
  • target: The name of the target system to catalog
  • ar_library: The name of the AR library to load. Do not specify if using DB2 Connect
  • params: Parameters to pass to the application requestor (AR) library
  • comment: A description of the catalog entry



In order to use the boot the vagrant box and set up a DB2 instance to test with, you should first obtain the 90 day trial from IBM's website and place the v10.5_linuxx64_server_t.tar.gz in the root directory of this repo. Then run vagrant up. The provisioner will set up some pre-reqs and run the code from tests/vagrant.pp. It should install DB2, configure an instance, add a sample database using the SAMPLE_DATABASE component and connect to it.