You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
8.[Transfer Notice - Notice of authorship change](#transfer-notice)
13
+
9.[Contributors - List of module contributors](#contributors)
14
+
10.[Release Notes - Notes on the most recent updates to the module](#release-notes)
16
15
17
16
18
17
Overview
@@ -105,7 +104,10 @@ Usage
105
104
106
105
The postgresql module comes with many options for configuring the server. While you are unlikely to use all of the below settings, they allow you a decent amount of control over your security settings.
107
106
108
-
###postgresql::server
107
+
###Class: postgresql
108
+
This class is used to configure the cross-domain settings for this module.
109
+
110
+
###Class: postgresql::server
109
111
Here are the options that you can set in the `config_hash` parameter of `postgresql::server`:
110
112
111
113
####`postgres_password`
@@ -140,7 +142,7 @@ List of strings for access control for connection method, users, databases, IPv4
140
142
List of strings for access control for connection method, users, databases, IPv6
141
143
addresses; see [postgresql documentation](http://www.postgresql.org/docs/9.2/static/auth-pg-hba-conf.html) about pg_hba.conf for information (please note that the link will take you to documentation for the most recent version of Postgres, however links for earlier versions can be found on that page).
142
144
143
-
###postgresql::client
145
+
###Class: postgresql::client
144
146
145
147
This class installs postgresql client software. Alter the following parameters if you have a custom version you would like to install (Note: don't forget to make sure to add any necessary yum or apt repositories if specifying a custom version):
146
148
@@ -150,7 +152,7 @@ The name of the postgresql client package.
150
152
####`package_ensure`
151
153
The ensure parameter passed on to postgresql client package resource.
152
154
153
-
###postgresql::java
155
+
###Class: postgresql::java
154
156
This class installs postgresql bindings for Java (JDBC). Alter the following parameters if you have a custom version you would like to install (Note: don't forget to make sure to add any necessary yum or apt repositories if specifying a custom version):
155
157
156
158
####`package_name`
@@ -159,63 +161,80 @@ The name of the postgresql java package.
159
161
####`package_ensure`
160
162
The ensure parameter passed on to postgresql java package resource.
161
163
162
-
### Custom Functions
164
+
###Resource: postgresql::database
165
+
This defined type can be used to create a database with no users and no permissions, which is a rare use case.
163
166
164
-
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:
167
+
###Resource: postgresql::tablespace
168
+
This defined type can be used to create a tablespace.
This defined type allows you to create an access rule for pg_hba.conf. For more details see the [PostgreSQL documentation](http://www.postgresql.org/docs/8.2/static/auth-pg-hba-conf.html).
167
172
168
-
### Tests
173
+
For example:
169
174
170
-
There are two types of tests distributed with the module. The first set is the “traditional” Puppet manifest-style smoke tests. You can use these to experiment with the module on a virtual machine or other test environment, via `puppet apply`. You should see the following files in the `tests` directory.
175
+
postgresql::pg_hba_rule { 'allow application network to access app database':
176
+
description => "Open up postgresql for access from 200.1.2.0/24",
177
+
type => 'host',
178
+
database => 'app',
179
+
user => 'app',
180
+
address => '200.1.2.0/24',
181
+
auth_method => 'md5',
182
+
}
171
183
172
-
In addition to these manifest-based smoke tests, there are some ruby rspec tests in the spec directory. These tests run against a VirtualBox VM, so they are actually testing the live application of the module on a real, running system. To do this, you must install and setup an [RVM](http://beginrescueend.com/) with [vagrant](http://vagrantup.com/), [sahara](https://github.com/jedi4ever/sahara), and [rspec](http://rspec.info/):
184
+
This would create a ruleset in `pg_hba.conf` similar to:
173
185
174
-
$ curl -L get.rvm.io | bash -s stable
175
-
$ rvm install 1.9.3
176
-
$ rvm use --create 1.9.3@puppet-postgresql
177
-
$ bundle install
186
+
# Rule Name: allow application network to access app database
187
+
# Description: Open up postgresql for access from 200.1.2.0/24
188
+
# Order: 150
189
+
host app app 200.1.2.0/24 md5
178
190
179
-
Run the system tests:
191
+
####`namevar`
192
+
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.
180
193
181
-
$ rake spec:system
194
+
####`description`
195
+
A longer description for this rule if required. Defaults to `none`. This description is placed in the comments above the rule in `pg_hba.conf`.
182
196
183
-
The system test suite will snapshot the VM and rollback between each test.
184
-
185
-
We also have some unit tests that utilize rspec-puppet for faster iteration if required:
197
+
####`type`
198
+
The type of rule, this is usually one of: local, host, hostssl or hostnossl.
186
199
187
-
$ rake spec
200
+
####`database`
201
+
A comma separated list of databases that this rule matches.
188
202
189
-
The unit tests are ran in Travis-CI as well, if you want to see the results of your own tests regsiter the service hook through Travis-CI via the accounts section for your Github clone of this project.
203
+
####`user`
204
+
A comma separated list of database users that this rule matches.
190
205
191
-
Implementation
192
-
---------------
206
+
####`address`
207
+
If the type is not 'local' you can provide a CIDR based address here for rule matching.
193
208
194
-
### Resource Overview
209
+
####`auth_method`
210
+
The auth_method is described further in the pg_hba.conf documentation, but it provides the method that is used for authentication for the connection that this rule matches.
195
211
196
-
**postgresql**
212
+
####`auth_option`
213
+
For certain auth_methods there are extra options that can be passed. Consult the PostgreSQL `pg_hba.conf` documentation for further details.
197
214
198
-
This class is used to manage the basic postgresql client packages (which include the psql command line tool and other utilities).
215
+
####`order`
216
+
An order for placing the rule in pg_hba.conf. Defaults to `150`.
199
217
200
-
**postgresql::database**
218
+
####`target`
219
+
This provides the target for the rule, and is generally an internal only property. Use with caution.
201
220
202
-
This defined type can be used to create a database with no users and no permissions, which is a rare use case.
221
+
###Resource: postgresql_psql**
203
222
204
-
**postgresql::tablespace**
223
+
This type manages the command line tool for the postgresql module.
205
224
206
-
This defined type can be used to create a tablespace.
207
-
208
-
**postgresql_psql**
225
+
###Function: postgresql_password
226
+
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:
209
227
210
-
This defined type manages the command line tool for the postgresql module.
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.
214
232
215
-
**postgres\_default\_version**
233
+
**This function should only be used internally by the module**.
216
234
235
+
###Fact: postgres_default_version
217
236
The module provides a Facter fact that can be used to determine what the default version of postgres is for your operating system/distribution. Depending on the distribution, it might be 8.1, 8.4, 9.1, or possibly another version. This can be useful in a few cases, like when building path strings for the postgres directories.
218
-
237
+
219
238
Limitations
220
239
------------
221
240
@@ -230,6 +249,29 @@ We want to keep it as easy as possible to contribute changes so that our modules
230
249
231
250
You can read the complete module contribution guide [on the Puppet Labs wiki.](http://projects.puppetlabs.com/projects/module-site/wiki/Module_contributing)
232
251
252
+
### Tests
253
+
254
+
There are two types of tests distributed with the module. The first set is the “traditional” Puppet manifest-style smoke tests. You can use these to experiment with the module on a virtual machine or other test environment, via `puppet apply`. You should see the following files in the `tests` directory.
255
+
256
+
In addition to these manifest-based smoke tests, there are some ruby rspec tests in the spec directory. These tests run against a VirtualBox VM, so they are actually testing the live application of the module on a real, running system. To do this, you must install and setup an [RVM](http://beginrescueend.com/) with [vagrant](http://vagrantup.com/), [sahara](https://github.com/jedi4ever/sahara), and [rspec](http://rspec.info/):
257
+
258
+
$ curl -L get.rvm.io | bash -s stable
259
+
$ rvm install 1.9.3
260
+
$ rvm use --create 1.9.3@puppet-postgresql
261
+
$ bundle install
262
+
263
+
Run the system tests:
264
+
265
+
$ rake spec:system
266
+
267
+
The system test suite will snapshot the VM and rollback between each test.
268
+
269
+
We also have some unit tests that utilize rspec-puppet for faster iteration if required:
270
+
271
+
$ rake spec
272
+
273
+
The unit tests are ran in Travis-CI as well, if you want to see the results of your own tests regsiter the service hook through Travis-CI via the accounts section for your Github clone of this project.
0 commit comments