2016-01-21 21:26:29 +01:00
# postgresql
2013-02-20 13:45:21 +01:00
2012-10-24 19:20:20 +02:00
2016-01-21 21:26:29 +01:00
#### Table of Contents
1. [Overview - What is the posgresql module? ](#overview )
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2. [Module Description - What does the module do? ](#module-description )
2016-01-21 21:26:29 +01:00
3. [Setup - The basics of getting started with posgresql module ](#setup )
* [PE Supported module ](#supported-module )
2014-12-09 23:48:45 +01:00
* [Configuring the server ](#configuring-the-server )
2016-01-21 21:26:29 +01:00
4. [Usage - Configuration options and additional functionality ](#usage )
5. [Reference - An under-the-hood peek at what the module is doing and how ](#reference )
* [Classes ](#classes )
* [Defined Types ](#defined-types )
* [Types ](#types )
* [Functions ](#functions )
2015-03-06 22:49:12 +01:00
6. [Limitations - OS compatibility, etc. ](#limitations )
7. [Development - Guide for contributing to the module ](#development )
2016-01-21 21:26:29 +01:00
* [Transfer Notice - Notice of authorship change ](#transfer-notice )
* [Contributors - List of module contributors ](#contributors )
8. [Tests ](#tests )
9. [Transfer Notice - Notice of authorship change ](#transfer-notice )
10. [Contributors - List of module contributors ](#contributors )
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
## Overview
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
The posgresql module allows you to easily manage PostgreSQL databases with Puppet.
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
## Module description
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
PostgreSQL is a high-performance, free, open-source relational database server. The posgresql module allows you to manage PostgreSQL packages and services on several operating systems, while also supporting basic management of PostgreSQL databases and users. The module offers support for basic management of common security settings.
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
## Setup
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
**What puppetlabs-PostgreSQL affects:**
* package/service/configuration files for PostgreSQL
* listened-to ports
2013-02-20 13:45:21 +01:00
* IP and mask (optional)
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
**Introductory Questions**
2016-01-21 21:26:29 +01:00
The posgresql module offers many security configuration settings. Before getting started, you will want to consider:
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
* Do you want or need to allow remote connections?
2013-02-20 13:45:21 +01:00
* If yes, what about TCP connections?
* How restrictive do you want the database superuser's permissions to be?
2012-10-16 23:24:17 +02:00
2013-01-23 00:16:21 +01:00
Your answers to these questions will determine which of the module's parameters you'll want to specify values for.
2012-10-16 23:24:17 +02:00
2016-01-21 21:26:29 +01:00
### Supported module
Puppet Enterprise 3.2 introduced Puppet Labs supported modules. The version of the posgresql module that ships with PE is supported via normal [Puppet Enterprise support ](http://puppetlabs.com/services/customer-support ) channels. If you would like to access the [supported module ](http://forge.puppetlabs.com/supported ) version, you will need to uninstall the shipped module and install the supported version from the Puppet Forge. You can do this by first running
2014-03-03 21:36:07 +01:00
2016-01-21 21:26:29 +01:00
puppet module uninstall puppetlabs-postgresql
2014-03-03 21:36:07 +01:00
and then running
2016-01-21 21:26:29 +01:00
puppet module install puppetlabs/postgresql
2014-03-03 21:36:07 +01:00
2016-01-21 21:26:29 +01:00
## Usage
2012-10-16 23:24:17 +02:00
2016-01-21 21:26:29 +01:00
### Configuring the server
The main configuration you'll need to do will be around the `postgresql::server` class. The default parameters are reasonable, but fairly restrictive regarding permissions for who can connect and from where. To manage a PostgreSQL server with defaults:
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-08-27 22:43:47 +02:00
class { 'postgresql::server': }
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-08-27 22:43:47 +02:00
For a more customized configuration:
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-02-20 13:45:21 +01:00
class { 'postgresql::server':
2013-08-27 22:43:47 +02:00
ip_mask_deny_postgres_user => '0.0.0.0/32',
ip_mask_allow_all_users => '0.0.0.0/0',
listen_addresses => '*',
ipv4acls => ['hostssl all johndoe 192.168.0.0/24 cert'],
postgres_password => 'TPSrep0rt!',
2013-02-20 13:45:21 +01:00
}
2016-01-21 21:26:29 +01:00
Once you've completed your configuration of `postgresql::server` , you can test your settings from the command line:
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
psql -h localhost -U postgres
psql -h my.postgres.server -U
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
If you get an error message from these commands, it means that your permissions are set in a way that restricts access from where you're trying to connect. That could be a good or bad thing, depending on your goals.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2015-02-06 13:34:47 +01:00
For more details about server configuration parameters consult the [PostgreSQL Runtime Configuration docs ](http://www.postgresql.org/docs/current/static/runtime-config.html ).
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
### Creating a database
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2015-12-08 00:12:36 +01:00
There are many ways to set up a postgres database using the `postgresql::server::db` defined type. For instance, to set up a database for PuppetDB:
2013-08-27 22:43:47 +02:00
class { 'postgresql::server': }
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-08-27 22:43:47 +02:00
postgresql::server::db { 'mydatabasename':
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
user => 'mydatabaseuser',
2013-10-07 18:39:30 +02:00
password => postgresql_password('mydatabaseuser', 'mypassword'),
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
}
2016-01-21 21:26:29 +01:00
### Managing users, roles and permissions
2013-02-20 13:45:21 +01:00
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
To manage users, roles and permissions:
2013-08-27 22:43:47 +02:00
class { 'postgresql::server': }
postgresql::server::role { 'marmot':
2013-10-07 18:39:30 +02:00
password_hash => postgresql_password('marmot', 'mypasswd'),
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
}
2013-08-27 22:43:47 +02:00
postgresql::server::database_grant { 'test1':
2013-07-16 21:50:44 +02:00
privilege => 'ALL',
db => 'test1',
2013-08-27 22:43:47 +02:00
role => 'marmot',
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
}
2013-02-20 13:45:21 +01:00
2013-08-27 22:43:47 +02:00
postgresql::server::table_grant { 'my_table of test2':
2013-07-16 21:50:44 +02:00
privilege => 'ALL',
table => 'my_table',
db => 'test2',
2013-08-27 22:43:47 +02:00
role => 'marmot',
2013-07-16 21:50:44 +02:00
}
In this example, you would grant ALL privileges on the test1 database and on the `my_table` table of the test2 database to the user or group specified by dan.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-02-20 13:45:21 +01:00
At this point, you would just need to plunk these database name/username/password values into your PuppetDB config files, and you are good to go.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
### Overriding defaults
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
The `postgresql::globals` class allows you to configure the main settings for this module in a global way, to be used by the other classes and defined resources. On its own it does nothing.
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
For example, if you wanted to overwrite the default `locale` and `encoding` for all classes you could use the following combination:
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
class { 'postgresql::globals':
encoding => 'UTF-8',
locale => 'en_US.UTF-8',
}->
class { 'postgresql::server':
}
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
If you want to use the upstream PostgreSQL packaging, and be specific about the version you wish to download, you could use something like this:
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
class { 'postgresql::globals':
manage_package_repo => true,
version => '9.2',
}->
class { 'postgresql::server': }
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
### Managing remote users, roles and permissions
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
Remote SQL objects are managed using the same Puppet resources as local SQL objects with the additional of a connect_settings hash. This provides control over how Puppet should connect to the remote Postgres instances and the version that should be used when generating SQL commands.
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
When provided the connect_settings hash can contain environment variables to control Postgres client connections, such as: PGHOST, PGPORT, PGPASSWORD PGSSLKEY (see http://www.postgresql.org/docs/9.4/static/libpq-envars.html) Additionally the special value of DBVERSION can be provided to specify the target database's version. If the connect_settings hash is omitted or empty then Puppet will connect to the local Postgres instance.
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
A connect_settings hash can be provided with each of the Puppet resources or a default connect_settings hash can be set in postgresql::globals. Per resource configuration of connect_settings allows for SQL object to be creating on multiple database by multiple users.
$connection_settings_super2 = {
'PGUSER' => "super2",
'PGPASSWORD' => "foobar2",
'PGHOST' => "127.0.0.1",
'PGPORT' => "5432",
'PGDATABASE' => "postgres",
}
include postgresql::server
# Connect with no special settings, i.e domain sockets, user postges
postgresql::server::role{'super2':
password_hash => "foobar2",
superuser => true,
connect_settings => {},
require => [
Class['postgresql::globals'],
Class['postgresql::server::service'],
],
}
# Now using this new user connect via TCP
postgresql::server::database { 'db1':
connect_settings => $connection_settings_super2,
require => Postgresql::Server::Role['super2'],
}
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
## Reference
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
The posgresql module comes with many options for configuring the server. While you are unlikely to use all of the settings below, they provide a decent amount of control over your security settings.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-02-20 13:45:21 +01:00
Classes:
2016-01-21 21:26:29 +01:00
* [postgresql::client ](#postgresqlclient )
* [postgresql::globals ](#postgresqlglobals )
* [postgresql::lib::devel ](#postgresqllibdevel )
* [postgresql::lib::java ](#postgresqllibjava )
* [postgresql::lib::perl ](#postgresqllibperl )
* [postgresql::lib::python ](#postgresqllibpython )
* [postgresql::server ](#postgresqlserver )
* [postgresql::server::plperl ](#postgresqlserverplperl )
* [postgresql::server::contrib ](#postgresqlservercontrib )
* [postgresql::server::postgis ](#postgresqlserverpostgis )
Defined Types:
* [postgresql::server::config_entry ](#postgresqlserverconfig_entry )
* [postgresql::server::database ](#postgresqlserverdatabase )
* [postgresql::server::database_grant ](#postgresqlserverdatabase_grant )
* [postgresql::server::db ](#postgresqlserverdb )
* [postgresql::server::extension ](#postgresqlserverextension )
* [postgresql::server::pg_hba_rule ](#postgresqlserverpg_hba_rule )
* [postgresql::server::pg_ident_rule ](#postgresqlserverpg_ident_rule )
* [postgresql::server::recovery ](#postgresqlserverrecovery )
* [postgresql::server::role ](#postgresqlserverrole )
* [postgresql::server::schema ](#postgresqlserverschema )
* [postgresql::server::table_grant ](#postgresqlservertable_grant )
* [postgresql::server::tablespace ](#postgresqlservertablespace )
* [postgresql::validate_db_connection ](#postgresqlvalidate_db_connection )
Types:
2015-03-25 16:19:09 +01:00
2015-10-07 10:36:32 +02:00
* [postgresql_psql ](#custom-resource-postgresql_psql )
* [postgresql_replication_slot ](#custom-resource-postgresql_replication_slot )
* [postgresql_conf ](#custom-resource-postgresql_conf )
2015-03-25 16:19:09 +01:00
2013-02-20 13:45:21 +01:00
Functions:
2015-10-07 10:36:32 +02:00
* [postgresql_password ](#function-postgresql_password )
* [postgresql_acls_to_resources_hash ](#function-postgresql_acls_to_resources_hashacl_array-id-order_offset )
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
### Classes
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql::client
Installs PostgreSQL client software. Alter the following parameters if you have a custom version you would like to install.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
>**Note:** Make sure to add any necessary yum or apt repositories if specifying a custom version.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Sets the ensure parameter passed on to PostgreSQL client package resource. Default: 'present'.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Sets the name of the PostgreSQL client package. Default: 'file'.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `validcon_script_path`
Specifies the path to validate the connection script. Default: '/usr/local/bin/validate_postgresql_connection.sh'.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql::lib::docs
Installs PostgreSQL bindings for Postgres-Docs. Alter the following parameters if you have a custom version you would like to install
2013-02-18 16:06:44 +01:00
2016-01-21 21:26:29 +01:00
>**Note:** Make sure to add any necessary yum or apt repositories if specifying a custom version.
2013-02-18 16:06:44 +01:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Specifies the name of the PostgreSQL docs package.
2013-02-18 16:06:44 +01:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
The ensure parameter passed on to postgresql docs package resource.
2013-02-18 16:06:44 +01:00
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql::globals
>**Note:** Most server specific defaults should be overriden in the `postgresql::server` class. This class should only be used if you are using a non-standard OS or if you are changing elements such as `version` or `manage_package_repo` that can only be changed here.
2014-04-02 23:52:07 +02:00
2016-01-21 21:26:29 +01:00
##### `bindir`
Overrides the default PostgreSQL binaries directory for the target platform. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `client_package_name`
Overrides the default PostgreSQL client package name. Default: OS dependent.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `confdir`
Overrides the default PostgreSQL configuration directory for the target platform. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `contrib_package_name`
Overrides the default PostgreSQL contrib package name. Default: OS dependent.
2014-05-08 22:43:22 +02:00
2016-01-21 21:26:29 +01:00
##### `createdb_path`
**Deprecated.**
Path to the `createdb` command. Default: "${bindir}/createdb".
2013-12-24 03:09:12 +01:00
2016-01-21 21:26:29 +01:00
##### `datadir`
Overrides the default PostgreSQL data directory for the target platform. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
>**Note:** Changing the datadir after installation will cause the server to come to a full stop before being able to make the change. For RedHat systems, the data directory must be labeled appropriately for SELinux. On Ubuntu, you need to explicitly set `needs_initdb = true` in order to allow Puppet to initialize the database in the new datadir (`needs_initdb` defaults to true on other systems).
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
**Warning:** If datadir is changed from the default, Puppet will not manage purging of the original data directory, which will cause it to fail if the data directory is changed back to the original.
2013-10-27 02:50:05 +02:00
2016-01-21 21:26:29 +01:00
##### `default_database`
Specifies the name of the default database to connect with. On most systems, this will be "postgres".
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `devel_package_name`
Overrides the default PostgreSQL devel package name. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `docs_package_name`
Overrides the default PostgreSQL docs package name. If not specified, the module will use the default for your OS distro.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `encoding`
Sets the default encoding for all databases created with this module. On certain operating systems, this will also be used during the `template1` initialization, so it becomes a default outside of the module as well. Defaults to the operating system's default encoding.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `group`
Overrides the default PostgreSQL user group to be used for related files in the file system. Default: 'postgres'.
2014-07-24 22:04:02 +02:00
2016-01-21 21:26:29 +01:00
##### `initdb_path`
Path to the `initdb` command.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `java_package_name`
Overrides the default PostgreSQL java package name. Default: OS dependent.
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
##### `locale`
Sets the default database locale for all databases created with this module. On certain operating systems, this will also be used during the `template1` initialization, so it becomes a default outside of the module as well. Default: undef, which is effectively `C` . **On Debian, you'll need to ensure that the 'locales-all' package is installed for full functionality of PostgreSQL.**
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `logdir`
Overrides the default PostgreSQL log directory. Default: initdb's default path.
2014-10-31 23:27:34 +01:00
2016-01-21 21:26:29 +01:00
##### `manage_package_repo`
Sets up official PostgreSQL repositories on your host if set to 'true'. Default: 'false'.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `needs_initdb`
This setting can be used to explicitly call the initdb operation after server package is installed and before the PostgreSQL service is started. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `perl_package_name`
Overrides the default PostgreSQL Perl package name. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `pg_hba_conf_defaults`
Disables the defaults supplied with the module for `pg_hba.conf` if set to 'false'. This is useful if you disagree with the defaults and wish to override them yourself. Be sure that your changes of course align with the rest of the module, as some access is required to perform basic `psql` operations for example. Default: 'true'.
2013-12-13 22:41:25 +01:00
2016-01-21 21:26:29 +01:00
##### `pg_hba_conf_path`
Specifies the path to your `pg_hba.conf` file. Default: "${confdir}/pg_hba.conf".
2014-12-09 23:48:45 +01:00
2016-01-21 21:26:29 +01:00
##### `pg_ident_conf_path`
Specifies the path to your `pg_ident.conf` file. Default: "${confdir}/pg_ident.conf".
2013-02-18 16:06:44 +01:00
2016-01-21 21:26:29 +01:00
##### `plperl_package_name`
Overrides the default PostgreSQL PL/perl package name. Default: OS dependent.
2013-02-18 16:06:44 +01:00
2016-01-21 21:26:29 +01:00
##### `plpython_package_name`
Overrides the default PostgreSQL PL/python package name. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `postgis_version`
Defines the version of PostGIS to install, if you install PostGIS. Defaults to the lowest available with the version of PostgreSQL to be installed.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `postgresql_conf_path`
Sets the path to your `postgresql.conf` file. Default: "${confdir}/postgresql.conf".
2013-10-16 21:46:50 +02:00
2016-01-21 21:26:29 +01:00
##### `psql_path`
Sets the path to the `psql` command.
2013-02-18 16:06:44 +01:00
2016-01-21 21:26:29 +01:00
##### `python_package_name`
Overrides the default PostgreSQL Python package name. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `recovery_conf_path`
Path to your `recovery.conf` file.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `repo_proxy`
Sets the proxy option for the official PostgreSQL yum-repositories only, Debian is currently not supported. This is useful if your server is behind a corporate firewall and needs to use proxyservers for outside connectivity.
2015-07-15 13:20:19 +02:00
2016-01-21 21:26:29 +01:00
##### `server_package_name`
Overrides the default PostgreSQL server package name. Default: OS dependent.
2015-07-15 13:20:19 +02:00
2016-01-21 21:26:29 +01:00
##### `service_name`
Overrides the default PostgreSQL service name. Default: OS dependent.
2014-02-28 23:32:13 +01:00
2016-01-21 21:26:29 +01:00
##### `service_provider`
Overrides the default PostgreSQL service provider. Default: OS dependent.
2014-02-28 23:32:13 +01:00
2016-01-21 21:26:29 +01:00
##### `service_status`
Overrides the default status check command for your PostgreSQL service. Default: OS dependent.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `user`
Overrides the default PostgreSQL super user and owner of PostgreSQL related files in the file system. Default: 'postgres'.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
##### `version`
The version of PostgreSQL to install/manage. This is a simple way of providing a specific version such as '9.2' or '8.4' for example. Default: OS system default.
2012-10-16 23:24:17 +02:00
2016-01-21 21:26:29 +01:00
##### `xlogdir`
Overrides the default PostgreSQL xlog directory. Default: initdb's default path.
2013-01-16 01:09:10 +01:00
2016-01-21 21:26:29 +01:00
####postgresql::lib::devel
Installs the packages containing the development libraries for PostgreSQL and symlinks pg_config into `/usr/bin` (if not in `/usr/bin` or `/usr/local/bin` ).
2013-09-19 17:30:15 +02:00
2016-01-21 21:26:29 +01:00
##### `link_pg_config`
By default on all but Debian systems, if the bin directory used by the PostgreSQL package is not `/usr/bin` or `/usr/local/bin` ,
this class will symlink `pg_config` from the package's bin dir into `/usr/bin` . Set `link_pg_config` to
false to disable this behavior.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Overrides the `ensure` parameter during package installation. Defaults to `present` .
2014-12-04 14:26:37 +01:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Overrides the default package name for the distribution you are installing to. Defaults to `postgresql-devel` or `postgresql<version>-devel` depending on your distro.
2013-07-03 16:11:54 +02:00
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
####postgresql::lib::java
Installs PostgreSQL bindings for Java (JDBC). Alter the following parameters if you have a custom version you would like to install
2015-03-06 23:10:27 +01:00
2016-01-21 21:26:29 +01:00
>**Note:** Make sure to add any necessary yum or apt repositories if specifying a custom version.
2015-10-07 16:24:41 +02:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Sets the ensure parameter passed on to PostgreSQL java package resource.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Specifies the name of the PostgreSQL java package.
2013-10-27 02:50:05 +02:00
2012-10-16 23:24:17 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::lib::perl
Installs the PostgreSQL Perl libraries. For customer requirements you can customize the following parameters:
2014-04-17 21:09:07 +02:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Sets the ensure parameter passed on to PostgreSQL perl package resource.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Specifies the name of the PostgreSQL perl package to install.
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::plpython
Installs the PL/Python procedural language for PostgreSQL.
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Specifies the name of the postgresql PL/Python package.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Specifies the ensure parameter passed on to PostgreSQL PL/Python package resource.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
####postgresql::lib::python
Installs PostgreSQL Python libraries. For customer requirements you can customize the following parameters:
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
The ensure parameter passed on to PostgreSQL python package resource.
2014-07-24 22:04:02 +02:00
2016-01-21 21:26:29 +01:00
##### `package_name`
The name of the PostgreSQL python package.
2013-08-27 22:43:47 +02:00
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
####postgresql::server
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `createdb_path`
**Deprecated.**
Specifies the path to the `createdb` command. Default: "${bindir}/createdb".
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `default_database`
Specifies the name of the default database to connect with. On most systems this will be "postgres".
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `encoding`
Sets the default encoding for all databases created with this module. On certain operating systems this will also be used during the `template1` initialization, so it becomes a default outside of the module as well. Default: undef.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `group`
Overrides the default PostgreSQL user group to be used for related files in the file system. Default: OS dependent default.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `initdb_path`
Specifies the path to the `initdb` command. Default: "${bindir}/initdb".
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `ipv4acls`
Lists strings for access control for connection method, users, databases, IPv4 addresses; see [postgresql documentation ](http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html ) about `pg_hba.conf` for information (**Note:** The link will take you to documentation for the most recent version of PostgreSQL, however links for earlier versions can be found there too).
2014-02-28 23:32:13 +01:00
2016-01-21 21:26:29 +01:00
##### `ipv6acls`
Lists strings for access control for connection method, users, databases, IPv6 addresses; see [postgresql documentation ](http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html ) about `pg_hba.conf` for information (**Note:** The link will take you to documentation for the most recent version of PostgreSQL, however links for earlier versions can be found there too).
2014-02-28 23:32:13 +01:00
2016-01-21 21:26:29 +01:00
##### `ip_mask_allow_all_users`
Overrides PostgreSQL defaults for remote connections. By default, PostgreSQL does not allow database user accounts to connect via TCP from remote machines. If you'd like to allow them to, you can override this setting. You can set it to `0.0.0.0/0` to allow database users to connect from any remote machine, or `192.168.0.0/16` to allow connections from any machine on your local 192.168 subnet. Default: `127.0.0.1/32` .
2013-10-02 14:43:21 +02:00
2016-01-21 21:26:29 +01:00
##### `ip_mask_deny_postgres_user`
Specifies an IP and mask to deny connections from specific users while also allowing remote users. Sometimes it can be useful to block the superuser account from remote connections if you are allowing other database users to connect remotely. For example, the default value `0.0.0.0/0` will match any remote IP and deny access, so the postgres user won't be able to connect remotely at all. Conversely, a value of `0.0.0.0/32` would not match any remote IP, and thus the deny rule will not be applied and the postgres user will be allowed to connect. Default: `0.0.0.0/0` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `listen_addresses`
This value defaults to `localhost` , meaning the postgres server will only accept connections from localhost. If you'd like to be able to connect to postgres from remote machines, you can override this setting. A value of `*` will tell postgres to accept connections from any remote machine. Alternately, you can specify a comma-separated list of hostnames or IP addresses. (For more info, have a look at the `postgresql.conf` file from your system's postgres package).
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
##### `locale`
Sets the default database locale for all databases created with this module. On certain operating systems this will be used during the `template1` initialization as well so it becomes a default outside of the module as well. Default: undef, which is effectively `C` . **On Debian, you'll need to ensure that the 'locales-all' package is installed for full functionality of PostgreSQL.**
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
##### `manage_pg_hba_conf`
This value defaults to `true` . Whether or not manage the pg_hba.conf. If set to `true` , puppet will overwrite this file. If set to `false` , puppet will not modify the file.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
##### `manage_pg_ident_conf`
Overwrites the pg_ident.conf file. If set to `true` , Puppet will overwrite the file. If set to `false` , Puppet will not modify the file. Default: `true` .
2014-04-30 14:30:03 +02:00
2016-01-21 21:26:29 +01:00
##### `manage_recovery_conf`
Specifies whether or not manage the recovery.conf. If set to `true` , Puppet will overwrite this file. If set to `false` , Puppet will not create the file. Default: `false` .
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
##### `needs_initdb`
Explicitly calls the `initdb` operation after server package is installed, and before the PostgreSQL service is started. Default: OS dependent.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Passes a value through to the `package` resource when creating the server instance. Default: undef.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Specifies the name of the package to use for installing the server software. Default: OS dependent.
2013-03-02 10:49:57 +01:00
2016-01-21 21:26:29 +01:00
##### `pg_hba_conf_defaults`
If false, disables the defaults supplied with the module for `pg_hba.conf` . This is useful if you disagree with the defaults and wish to override them yourself. Be sure that your changes of course align with the rest of the module, as some access is required to perform basic `psql` operations for example.
2013-03-02 10:49:57 +01:00
2016-01-21 21:26:29 +01:00
##### `pg_hba_conf_path`
Specifies the path to your `pg_hba.conf` file.
2013-03-02 10:49:57 +01:00
2016-01-21 21:26:29 +01:00
##### `pg_ident_conf_path`
Specifies the path to your `pg_ident.conf` file. Default: "${confdir}/pg_ident.conf".
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `plperl_package_name`
Sets the default package name for the PL/Perl extension. Default: OS dependent.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `plpython_package_name`
Sets the default package name for the PL/Python extension. Default: OS dependent.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `port`
Specifies the port for the PostgreSQL server to listen on. **Note:** The same port number is used for all IP addresses the server listens on. Also, for RedHat systems and early Debian systems, changing the port will cause the server to come to a full stop before being able to make the change. Default: `5432` , meaning the postgres server will listen on TCP port 5432.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
##### `postgres_password`
Sets the password for the `postgres` user to your specified value. Default: undef, meaning the superuser account in the postgres database is a user called `postgres` and this account does not have a password.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `postgresql_conf_path`
Specifies the path to your `postgresql.conf` file. Default: "${confdir}/postgresql.conf".
2013-01-21 21:52:23 +01:00
2016-01-21 21:26:29 +01:00
##### `psql_path`
Specifies the path to the `psql` command. Default: OS dependent.
2013-01-21 21:52:23 +01:00
2016-01-21 21:26:29 +01:00
##### `service_manage`
Defines whether or not Puppet should manage the service. Default: `true` .
2013-01-21 21:52:23 +01:00
2016-01-21 21:26:29 +01:00
##### `service_name`
Overrides the default PostgreSQL service name. Default: OS dependent.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `service_provider`
Overrides the default PostgreSQL service provider. Default: undef.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `service_reload`
Overrides the default reload command for your PostgreSQL service. Default: OS dependent.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `service_restart_on_change`
Overrides the default behavior to restart your PostgreSQL service when a config entry has been changed that requires a service restart to become active. Default: `true` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `service_status`
Overrides the default status check command for your PostgreSQL service. Default: OS dependent.
2014-04-02 23:52:07 +02:00
2016-01-21 21:26:29 +01:00
##### `user`
Overrides the default PostgreSQL super user and owner of PostgreSQL related files in the file system. Default: 'postgres'.
2014-04-02 23:52:07 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::contrib
Installs the PostgreSQL contrib package.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Sets the ensure parameter passed on to PostgreSQL contrib package resource.
2015-03-04 12:58:15 +01:00
2016-01-21 21:26:29 +01:00
##### `package_name`
The name of the PostgreSQL contrib package.
2014-04-02 23:52:07 +02:00
2013-04-26 18:21:37 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::plperl
Installs the PL/Perl procedural language for postgresql.
2013-04-26 18:21:37 +02:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
The ensure parameter passed on to PostgreSQL PL/Perl package resource.
2013-04-26 18:21:37 +02:00
2016-01-21 21:26:29 +01:00
##### `package_name`
The name of the PostgreSQL PL/Perl package.
2013-08-27 22:43:47 +02:00
2013-08-12 10:14:19 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::postgis
Installs the PostgreSQL postgis packages.
2013-08-12 10:14:19 +02:00
2016-01-21 21:26:29 +01:00
### Defined Types
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::config_entry
Modifies your `postgresql.conf` configuration file.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
Each resource maps to a line inside the file, for example:
2013-08-27 22:43:47 +02:00
postgresql::server::config_entry { 'check_function_bodies':
value => 'off',
}
2016-01-21 21:26:29 +01:00
##### `ensure`
Removes an entry if set to `absent` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies the name of the setting to change.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `value`
Defines the value for the setting.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::db
Creates a local database, user, and assigns necessary permissions, in one go.
2013-02-20 13:45:21 +01:00
For example, to create a database called `test1` with a corresponding user of the same name, you can use:
2013-08-27 22:43:47 +02:00
postgresql::server::db { 'test1':
2013-02-20 13:45:21 +01:00
user => 'test1',
password => 'test1',
}
2016-01-21 21:26:29 +01:00
##### `comment`
Defines a comment to be stored about the database using the PostgreSQL COMMENT command.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. Default: Connects to the local Postgres instance.
2015-01-09 04:08:23 +01:00
2016-01-21 21:26:29 +01:00
##### `dbname`
Sets the name of the database to be created. Default: `namevar` .
2014-03-26 15:05:17 +01:00
2016-01-21 21:26:29 +01:00
##### `encoding`
Overrides the character set during creation of the database. Defaults to the default defined during installation.
2014-09-25 15:11:07 +02:00
2016-01-21 21:26:29 +01:00
##### `grant`
Specifies the permissions to grant during creation. Default: `ALL` .
##### `istemplate`
Specifies that the database is a template, if set to `true` . Default: `false` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `locale`
Overrides the locale during creation of the database. Defaults to the default defined during installation.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Designates the name of the database.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `owner`
Sets a user as the owner of the database. Default: $user variable set in `postgresql::server` or `postgresql::globals` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `password`
Sets the password for the created user. Mandatory.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `tablespace`
Defines the name of the tablespace to allocate the created database to. Default: PostgreSQL default.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `template`
Specifies the name of the template database from which to build this database. Defaults to `template0` .
2014-09-25 15:11:07 +02:00
2016-01-21 21:26:29 +01:00
##### `user`
User to create and assign access to the database upon creation. Mandatory.
2013-07-16 08:49:03 +02:00
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::database
Used to create a database with no users and no permissions, which is a rare use case.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
##### `dbname`
Sets the name of the database, defaults to the `namevar` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `encoding`
Overrides the character set during creation of the database. Default: The default defined during installation.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `istemplate`
Defines the database as a template if set to true. Default: `false` .
2013-06-06 23:50:15 +02:00
2016-01-21 21:26:29 +01:00
##### `locale`
Overrides the locale during creation of the database. DefaultThe default defined during installation.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies the name of the database to create.
2014-09-25 15:11:07 +02:00
2016-01-21 21:26:29 +01:00
##### `owner`
Sets name of the database user who will be set as the owner of the database. Default: The $user variable set in `postgresql::server` or `postgresql::globals` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `tablespace`
Sets tablespace for where to create this database. Default: The defaults defined during PostgreSQL installation.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `template`
Specifies the name of the template database from which to build this database. Default: `template0` .
2013-07-16 08:49:03 +02:00
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::database_grant
2013-08-27 22:43:47 +02:00
This defined type manages grant based access privileges for users, wrapping the `postgresql::server::database_grant` for database specific permissions. Consult the PostgreSQL documentation for `grant` for more information.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
#### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. Default: Connects to the local Postgres instance.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `db`
Specifies the database to grant access to.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies a way to uniquely identify this resource, but functionality not used during grant.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `privilege`
Specifies which privileges to grant. Valid options: `SELECT` , `TEMPORARY` , `TEMP` , `CONNECT` . `ALL` is used as a synonym for `CREATE` , so if you need to add multiple privileges, a space delimited string can be used.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `psql_db`
Defines the database to execute the grant against. _This should not ordinarily be changed from the default_ , which is `postgres` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `psql_user`
Specifies the OS user for running `psql` . Default: The default user for the module, usually `postgres` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `role`
Specifies the role or user whom you are granting access to.
2013-08-27 22:43:47 +02:00
2015-09-02 02:33:46 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::extension
Manages a PostgreSQL extension.
2014-11-04 15:58:26 +01:00
2016-01-21 21:26:29 +01:00
##### `database`
Specifies the database on which to activate the extension.
2014-11-04 15:58:26 +01:00
2016-01-21 21:26:29 +01:00
##### `ensure`
Specifies whether to activate (`present`) or deactivate (`absent`) the extension.
2014-11-04 15:58:26 +01:00
2016-01-21 21:26:29 +01:00
#### `extension`
Specifies the extension to activate. If left blank, it will use the name of the resource.
2014-11-04 15:58:26 +01:00
2016-01-21 21:26:29 +01:00
##### `package_name`
Specifies a package to install prior to activating the extension.
2014-11-04 15:58:26 +01:00
2016-01-21 21:26:29 +01:00
##### `package_ensure`
Overrides default package deletion behavior. By default, the package specified with `package_name` will be installed when the extension is activated, and removed when the extension is deactivated. You can override this behavior by setting the `ensure` value for the package.
#### postgresql::server::grant
2015-05-08 16:33:26 +02:00
This defined type manages grant based access privileges for roles. Consult the PostgreSQL documentation for `grant` for more information.
2016-01-21 21:26:29 +01:00
##### `db`
Specifies the database which you are granting access on.
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Sets a unique identifier for this resource, but functionality not used during grant.
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `object_type`
Specifies the type of object you are granting privileges on. Valid options: `DATABASE` , `SCHEMA` , `SEQUENCE` , `ALL SEQUENCES IN SCHEMA` , `TABLE` or `ALL TABLES IN SCHEMA` .
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `object_name`
Specifies name of `object_type` on which to grant access.
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `port`
Port to use when connecting. Default: undef, which generally defaults to port 5432 depending on your PostgreSQL packaging.
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `privilege`
Specifies the privilege you are granting. Valid options: `ALL` , `ALL PRIVILEGES` or `object_type` dependent string.
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `psql_db`
Specifies the database to execute the grant against. _This should not ordinarily be changed from the default_ , which is `postgres` .
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `psql_user`
Sets the OS user to run `psql` . Default: the default user for the module, usually `postgres` .
2015-05-08 16:33:26 +02:00
2016-01-21 21:26:29 +01:00
##### `role`
Specifies the role or user whom you are granting access to.
2015-05-08 16:33:26 +02:00
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::pg_hba_rule
Allows you to create an access rule for `pg_hba.conf` . For more details see the [PostgreSQL documentation ](http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html ).
2013-08-27 22:43:47 +02:00
For example:
postgresql::server::pg_hba_rule { 'allow application network to access app database':
2016-01-21 21:26:29 +01:00
description => "Open up PostgreSQL for access from 200.1.2.0/24",
2013-08-27 22:43:47 +02:00
type => 'host',
database => 'app',
user => 'app',
address => '200.1.2.0/24',
auth_method => 'md5',
}
This would create a ruleset in `pg_hba.conf` similar to:
# Rule Name: allow application network to access app database
2016-01-21 21:26:29 +01:00
# Description: Open up PostgreSQL for access from 200.1.2.0/24
2013-08-27 22:43:47 +02:00
# Order: 150
host app app 200.1.2.0/24 md5
2013-07-16 21:50:44 +02:00
2015-08-04 17:57:26 +02:00
By default, `pg_hba_rule` requires that you include `postgresql::server` , however, you can override that behavior by setting target and postgresql_version when declaring your rule. That might look like the following.
postgresql::server::pg_hba_rule { 'allow application network to access app database':
description => "Open up postgresql for access from 200.1.2.0/24",
type => 'host',
database => 'app',
user => 'app',
address => '200.1.2.0/24',
auth_method => 'md5',
target => '/path/to/pg_hba.conf',
postgresql_version => '9.4',
}
2016-01-21 21:26:29 +01:00
##### `address`
Sets a CIDR based address for this rule matching when the type is not 'local'.
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
##### `auth_method`
Provides the method that is used for authentication for the connection that this rule matches. Described further in the `pg_hba.conf` documentation.
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
##### `auth_option`
For certain `auth_method` settings there are extra options that can be passed. Consult the PostgreSQL `pg_hba.conf` documentation for further details.
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
##### `database`
Sets a comma separated list of databases that this rule matches.
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
##### `description`
Defines a longer description for this rule if required. This description is placed in the comments above the rule in `pg_hba.conf` . Defaults: `none` .
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Defines a unique identifier or short description for this rule. The namevar doesn't provide any functional usage, but it is stored in the comments of the produced `pg_hba.conf` , so the originating resource can be identified.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `order`
Sets an order for placing the rule in `pg_hba.conf` . Default: `150` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
#### `postgresql_version`
Manages `pg_hba.conf` without managing the entire PostgreSQL instance. Default: The version set in `postgresql::server` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `target`
Provides the target for the rule, and is generally an internal only property. **Use with caution.**
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `type`
Sets the type of rule. Valid options: `local` , `host` , `hostssl` or `hostnossl` .
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
##### `user`
Sets a comma separated list of users that this rule matches.
2013-07-16 21:50:44 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::pg_ident_rule
Allows you to create user name maps for `pg_ident.conf` . For more details see the [PostgreSQL documentation ](http://www.postgresql.org/docs/current/static/auth-username-maps.html ).
2014-07-28 22:10:27 +02:00
For example:
postgresql::server::pg_ident_rule{ 'Map the SSL certificate of the backup server as a replication user':
map_name => 'sslrepli',
system_username => 'repli1.example.com',
database_username => 'replication',
}
This would create a user name map in `pg_ident.conf` similar to:
# Rule Name: Map the SSL certificate of the backup server as a replication user
# Description: none
# Order: 150
2016-01-21 21:26:29 +01:00
sslrepli repli1.example.com replication
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `database_username`
Specifies the user name of the the database user. The `system_username` will be mapped to this user name.
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `description`
Sets a longer description for this rule if required. This description is placed in the comments above the rule in `pg_ident.conf` . Default: `none` .
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `map_name`
Sets the name of the user map that is used to refer to this mapping in `pg_hba.conf` .
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Sets a unique identifier or short description for this rule. The namevar doesn't provide any functional usage, but it is stored in the comments of the produced `pg_ident.conf` , so the originating resource can be identified.
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `order`
Defines an order for placing the mapping in `pg_ident.conf` . Default: 150.
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `system_username`
Specifies the operating system user name, the user name used to connect to the database.
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
##### `target`
Provides the target for the rule, and is generally an internal only property. **Use with caution.**
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::recovery
Allows you to create the content for `recovery.conf` . For more details see the [PostgreSQL documentation ](http://www.postgresql.org/docs/current/static/recovery-config.html ).
2015-02-07 07:28:54 +01:00
For example:
2015-07-03 16:55:15 +02:00
postgresql::server::recovery{ 'Create a recovery.conf file with the following defined parameters':
2015-02-07 07:28:54 +01:00
restore_command => 'cp /mnt/server/archivedir/%f %p',
archive_cleanup_command => undef,
recovery_end_command => undef,
recovery_target_name => 'daily backup 2015-01-26',
recovery_target_time => '2015-02-08 22:39:00 EST',
recovery_target_xid => undef,
recovery_target_inclusive => true,
recovery_target => 'immediate',
recovery_target_timeline => 'latest',
pause_at_recovery_target => true,
standby_mode => 'on',
primary_conninfo => 'host=localhost port=5432',
primary_slot_name => undef,
trigger_file => undef,
recovery_min_apply_delay => 0,
}
This would create a `recovery.conf` config file, similar to this:
restore_command = 'cp /mnt/server/archivedir/%f %p'
recovery_target_name = 'daily backup 2015-01-26'
recovery_target_time = '2015-02-08 22:39:00 EST'
recovery_target_inclusive = true
recovery_target = 'immediate'
recovery_target_timeline = 'latest'
pause_at_recovery_target = true
2016-01-21 21:26:29 +01:00
standby_mode = 'on'
2015-02-07 07:28:54 +01:00
primary_conninfo = 'host=localhost port=5432'
recovery_min_apply_delay = 0
2016-01-21 21:26:29 +01:00
Only the specified parameters will be recognized in the template! The `recovery.conf` will only be created if at least one parameter is set and [manage_recovery_conf ](#manage_recovery_conf ) is set to `true` .
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
Every param value is a string set in the template except `recovery_target_inclusive` , `pause_at_recovery_target` , `standby_mode` and `recovery_min_apply_delay` .
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
`standby_mode` can be specified with the string ('on'/'off'), or by using a boolean value (true/false).
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
A detailed description of all above listed parameters can be found in the [PostgreSQL documentation ](http://www.postgresql.org/docs/current/static/recovery-config.html ).
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
The parameters are grouped into these three sections:
2015-02-07 07:28:54 +01:00
2016-01-21 21:26:29 +01:00
##### [`Archive Recovery Parameters`](http://www.postgresql.org/docs/current/static/archive-recovery-settings.html)
2015-02-07 07:28:54 +01:00
In this section the `restore_command` , `archive_cleanup_command` and `recovery_end_command` parameters are listed.
2016-01-21 21:26:29 +01:00
##### [`Recovery Target Settings`](http://www.postgresql.org/docs/current/static/recovery-target-settings.html)
2015-02-07 07:28:54 +01:00
In this section the `recovery_target_name` , `recovery_target_time` , `recovery_target_xid` , `recovery_target_inclusive` , `recovery_target` , `recovery_target_timeline` and `pause_at_recovery_target` parameters are listed.
2016-01-21 21:26:29 +01:00
##### [`Standby Server Settings`](http://www.postgresql.org/docs/current/static/standby-settings.html)
2015-02-07 07:28:54 +01:00
In this section the `standby_mode` , `primary_conninfo` , `primary_slot_name` , `trigger_file` and `recovery_min_apply_delay` parameters are listed.
2016-01-21 21:26:29 +01:00
##### `target`
Provides the target for the rule, and is generally an internal only property. **Use with caution.**
2015-02-07 07:28:54 +01:00
2014-07-28 22:10:27 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::role
Creates a role or user in PostgreSQL.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `connection_limit`
Specifies how many concurrent connections the role can make. Default: `-1` , meaning no limit.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. Default: Connects to the local Postgres instance.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `createdb`
Specifies whether to grant the ability to create new databases with this role. Default: `false` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `createrole`
Specifies whether to grant the ability to create new roles with this role. Default: `false` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `inherit`
Specifies whether to grant inherit capability for the new role. Default: `true` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `login`
Specifies whether to grant login capability for the new role. Default: `true` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies the role name to create.
2014-03-24 16:22:41 +01:00
2016-01-21 21:26:29 +01:00
##### `password_hash`
Sets the hash to use during password creation. If the password is not already pre-encrypted in a format that PostgreSQL supports, use the `postgresql_password` function to provide an MD5 hash here, for example:
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
postgresql::server::role { "myusername":
password_hash => postgresql_password('myusername', 'mypassword'),
}
##### `replication`
Provides provides replication capabilities for this role if set to `true` . Default: `false` .
2013-02-25 19:46:31 +01:00
2016-01-21 21:26:29 +01:00
##### `superuser`
Specifies whether to grant super user capability for the new role. Default: `false` .
2013-02-28 00:43:24 +01:00
2016-01-21 21:26:29 +01:00
##### `username`
Defines the username of the role to create, Default: `namevar` .
2013-08-27 22:43:47 +02:00
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::schema
Used to create a schema. For example:
2014-07-04 14:35:32 +02:00
postgresql::server::schema { 'isolated':
owner => 'jane',
db => 'janedb',
}
2014-09-16 15:43:12 +02:00
It will create the schema `isolated` in the database `janedb` if neccessary,
2014-07-04 14:35:32 +02:00
assigning the user `jane` ownership permissions.
2016-01-21 21:26:29 +01:00
##### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. Default: Connects to the local Postgres instance.
2014-07-04 14:35:32 +02:00
2016-01-21 21:26:29 +01:00
##### `db`
**Mandatory**. Sets the name of the database in which to create this schema. This must be passed.
2014-07-04 14:35:32 +02:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies the name of the schema being created.
2014-07-04 14:35:32 +02:00
2016-01-21 21:26:29 +01:00
##### `owner`
Sets the default owner of the schema.
2014-07-04 14:35:32 +02:00
2016-01-21 21:26:29 +01:00
##### `schema`
Sets the name of the schema. Default: `namevar` .
2015-03-05 01:34:52 +01:00
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
#### postgresql::server::table_grant
Manages grant based access privileges for users. Consult the PostgreSQL documentation for `grant` for more information.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. Default: Connects to the local Postgres instance.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `db`
Specifies which database the table is in.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Used to uniquely identify this resource, but functionality not used during grant.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `privilege`
Valid options: `SELECT` , `INSERT` , `UPDATE` , `REFERENCES` . `ALL` is used as a synonym for `CREATE` , so if you need to add multiple privileges, use a space delimited string.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `psql_db`
2013-08-27 22:43:47 +02:00
Database to execute the grant against. This should not ordinarily be changed from the default, which is `postgres` .
2016-01-21 21:26:29 +01:00
##### `psql_user`
Specifies the OS user for running `psql` . Defaults to the default user for the module, usually `postgres` .
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `role`
Specifies the role or user whom you are granting access for.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `table`
Specifies the table to grant access on.
#### postgresql::server::tablespace
Creates a tablespace. For example:
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2014-07-04 14:47:36 +02:00
postgresql::server::tablespace { 'tablespace1':
2013-02-20 13:45:21 +01:00
location => '/srv/space1',
}
It will create the location if necessary, assigning it the same permissions as your
PostgreSQL server.
2016-01-21 21:26:29 +01:00
##### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. Default: Connects to the local Postgres instance.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `location`
Specifies the path to locate this tablespace.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies the tablespace name to create.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `owner`
Specifies the default owner of the tablespace.
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
##### `spcname`
Specifies the name of the tablespace. Default: `namevar` .
2013-08-27 22:43:47 +02:00
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql::validate_db_connection
This resource can be utilized inside composite manifests to validate a client has a valid connection with a remote PostgreSQL database. It can be run from any node where the PostgreSQL client software is installed to validate connectivity before commencing other dependent tasks in your Puppet manifests. It is often used when chained to other tasks such as starting an application server, or performing a database migration.
2013-02-20 13:45:21 +01:00
Example usage:
postgresql::validate_db_connection { 'validate my postgres connection':
database_host => 'my.postgres.host',
database_username => 'mydbuser',
database_password => 'mydbpassword',
database_name => 'mydbname',
}->
exec { 'rake db:migrate':
cwd => '/opt/myrubyapp',
}
2016-01-21 21:26:29 +01:00
##### `connect_settings`
Specifies a hash of environment variables used when connecting to a remote server. This is an alternative to providing individual parameters (database_host, etc.). If provided, the individual parameters take precedence.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `create_db_first`
This will ensure the database is created before running the test. This only really works if your test is local. Default: `true` .
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `database_host`
Sets the hostname of the database you wish to test. Default: undef, which generally uses the designated local unix socket.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `database_name`
Specifies the name of the database you wish to test. Default: 'postgres'.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `database_port`
Defines the port to use when connecting. Default: undef, which generally defaults to port 5432 depending on your PostgreSQL packaging.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `database_password`
Specifies the password to connect with. Can be left blank, not recommended.
2013-02-20 13:45:21 +01:00
2016-01-21 21:26:29 +01:00
##### `database_username`
Specifies the username to connect with. Default: 'undef', which when using a unix socket and ident auth will be the user you are running as. **If the host is remote you must provide a username.**
2015-03-05 01:34:52 +01:00
2016-01-21 21:26:29 +01:00
##### `namevar`
Specifies a way to uniquely identify this resource, but functionally does nothing.
2013-10-23 23:49:16 +02:00
2016-01-21 21:26:29 +01:00
##### `run_as`
Specifies the user to run the `psql` command with for authenticiation as. This is important when trying to connect to a database locally using Unix sockets and `ident` authentication. Not needed for remote testing.
2013-10-23 23:49:16 +02:00
2016-01-21 21:26:29 +01:00
##### `sleep`
Sets the number of seconds to sleep for before trying again upon failure.
2013-10-23 23:49:16 +02:00
2016-01-21 21:26:29 +01:00
##### `tries`
Sets the number of attempts before giving up and failing the resource upon failure.
2013-10-23 23:49:16 +02:00
2016-01-21 21:26:29 +01:00
### Types
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql_psql
Enables Puppet to run psql statements.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `command`
**Required.** Specifies the SQL command to execute via psql.
##### `cwd`
Specifies the working directory under which the psql command should be executed. Default: '/tmp'.
##### `db`
Specifies the name of the database to execute the SQL command against.
##### `environment`
Specifies any additional environment variables you want to set for a SQL command. Multiple environment variables should be specified as an array.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `name`
Sets an arbitrary tag for your own reference; the name of the message. This is the
namevar.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `port`
Specifies the port of the database server to execute the SQL command against.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `psql_group`
Specifies the system user group account under which the psql command should be executed. Default: 'postgres'.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `psql_path`
Specifies the path to psql executable. Default: 'psql'.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `psql_user`
Specifies the system user account under which the psql command should be executed. Default: "postgres".
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `refreshonly`
Specifies that the SQL will only be executed via a notify/subscribe event if `true` . Default: `false` .
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `search_path`
Defines the schema search path to use when executing the SQL command.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `unless`
Sets an optional SQL command to execute prior to the main command. This is generally intended to be used for idempotency, to check for the existence of an object in the database to determine whether or not the main SQL command needs to be executed at all.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql_conf
Allows Puppet to manage `postgresql.conf` parameters.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `name`
Specifies the PostgreSQL parameter name to manage. This is the `namevar` .
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `target`
Specifies the path to `postgresql.conf` . Default: '/etc/postgresql.conf'.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `value`
Specifies the value to set for this parameter.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql_replication_slot
Allows you to create and destroy replication slots to register warm standby replication on a PostgreSQL master server.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
##### `name`
Specifies the name of the slot to create. Must be a valid replication slot name. This is the namevar.
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
### Functions
2015-03-25 16:19:09 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql_password
2013-02-20 13:45:21 +01:00
If you need to generate a postgres encrypted password, use `postgresql_password` . You can call it from your production manifests if you don't mind them containing the clear text versions of your passwords, or you can call it from the command line and then copy and paste the encrypted password into your manifest:
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
puppet apply --execute 'notify { "test": message => postgresql_password("username", "password") }'
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
#### postgresql_acls_to_resources_hash(acl_array, id, order_offset)
This internal function converts a list of `pg_hba.conf` based ACLs (passed in as an array of strings) to a format compatible with the `postgresql::pg_hba_rule` resource.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-02-10 01:36:12 +01:00
**This function should only be used internally by the module**.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
## Limitations
Works with versions of PostgreSQL from 8.1 through 9.4.
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
Currently it is only actively tested with the following operating systems:
2013-08-27 22:43:47 +02:00
2016-01-21 21:26:29 +01:00
* Debian 6.x and 7.x.
2014-05-08 22:43:22 +02:00
* Centos 5.x, 6.x, and 7.x.
2016-01-21 21:26:29 +01:00
* Ubuntu 10.04 and 12.04, 14.04.
Several other distros are compatible, but are not being actively tested.
2013-08-27 22:43:47 +02:00
2015-06-12 23:40:23 +02:00
### Apt module support
While this module supports both 1.x and 2.x versions of the puppetlabs-apt module, it does not support puppetlabs-apt 2.0.0 or 2.0.1.
2014-07-25 15:31:00 +02:00
### Postgis support
2016-01-21 21:26:29 +01:00
Postgis is currently considered an unsupported feature, as it doesn't work on all platforms correctly.
2014-07-25 15:31:00 +02:00
2014-06-24 17:11:03 +02:00
### All versions of RHEL/Centos
2016-01-21 21:26:29 +01:00
If you have SELinux enabled you must add any custom ports you use to the `postgresql_port_t` context. You can do this as follows:
2014-06-24 17:11:03 +02:00
2012-04-20 00:37:18 +02:00
2016-01-21 21:26:29 +01:00
semanage port -a -t postgresql_port_t -p tcp $customport
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
## Development
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’ module contribution guide ](https://docs.puppetlabs.com/forge/contributing.html ).
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2013-02-10 01:36:12 +01:00
### Tests
2016-01-21 21:26:29 +01:00
There are two types of tests distributed with this module. Unit tests with `rspec-puppet` and system tests using `rspec-system` .
2013-04-26 17:35:09 +02:00
For unit testing, make sure you have:
2013-02-10 01:36:12 +01:00
2013-04-26 17:35:09 +02:00
* rake
* bundler
2013-02-10 01:36:12 +01:00
2013-04-26 17:35:09 +02:00
Install the necessary gems:
2013-02-10 01:36:12 +01:00
2013-04-26 17:35:09 +02:00
bundle install --path=vendor
2013-02-10 01:36:12 +01:00
2013-04-26 17:35:09 +02:00
And then run the unit tests:
2013-02-10 01:36:12 +01:00
2013-04-26 17:35:09 +02:00
bundle exec rake spec
2013-05-06 19:50:03 +02:00
2016-01-21 21:26:29 +01:00
The unit tests are run in Travis-CI as well, if you want to see the results of your own tests, register the service hook through Travis-CI via the accounts section for your Github clone of this project.
2013-02-20 13:45:21 +01:00
2013-04-26 17:35:09 +02:00
If you want to run the system tests, make sure you also have:
2013-02-10 01:36:12 +01:00
2013-04-26 17:35:09 +02:00
* vagrant > 1.2.x
* Virtualbox > 4.2.10
2013-05-06 19:50:03 +02:00
2013-04-26 17:35:09 +02:00
Then run the tests using:
2013-05-06 19:50:03 +02:00
2014-04-24 22:10:18 +02:00
bundle exec rspec spec/acceptance
2013-02-10 01:36:12 +01:00
2016-01-21 21:26:29 +01:00
To run the tests on different operating systems, see the sets available in `.nodeset.yml` and run the specific set with the following syntax:
2013-02-10 01:36:12 +01:00
2014-04-24 22:10:18 +02:00
RSPEC_SET=debian-607-x64 bundle exec rspec spec/acceptance
2013-02-10 01:36:12 +01:00
2016-01-21 21:26:29 +01:00
### Transfer Notice
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
This Puppet module was originally authored by Inkling Systems. The maintainer preferred that Puppet Labs take ownership of the module for future improvement and maintenance as Puppet Labs is using it in the PuppetDB module. Existing pull requests and issues were transferred over, please fork and continue to contribute here instead of Inkling.
2013-02-20 13:45:21 +01:00
Previously: [https://github.com/inkling/puppet-postgresql ](https://github.com/inkling/puppet-postgresql )
Updated content to conform to README best practices template
Before alterations, this content was the module author-determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub and the Module
of the Week blog post. A table of contents was added for navigability,
standard headings were added (Overview, Module Description, Setup,
Usage, Implementation, etc.) to organize content, existent and
pulled-in content was moved under its appropriate heading and edited
for tone/flow/clarity, links to outside documentation were updated, and
basic formatting was done to adhere to template standards.
2013-01-19 01:17:08 +01:00
2016-01-21 21:26:29 +01:00
### Contributors
View the full list of contributors on [https://github.com/puppetlabs/puppetlabs-postgresql/graphs/contributors ](GitHub ).
