In the exec resource to reload postgres add path parameter and set it to
"/usr/bin:/usr/sbin:/bin:/sbin", so that the service command can be
called correctly on different platforms.
notify that exec after changes to pg_hba.conf. This avoids restarting
the whole postgresql cluster for configuration changes in pg_hba.conf
which only need a reload.
This commit provides a working implementation of a ruby
type/provider (`postgresql_psql` for handling the PSQL
commands. This is a little more flexible than doing it
via Exec resources, which is what the `postgresql::psql`
type was doing.
The old type is still present but now includes a
deprecation notification, and all of the other types
that were using the `::psql` type have been ported over
to use the `postgresql_psql` type instead.
This will allow characters such as '-' in database role
names. Additionally, escaping of '"' characters now applies to all '"'
characters, not just the first in a sql command.
One of the spec tests was creating a table to test
some user privileges. However, it wasn't dropping
the table afterwards, meaning that the same test
would fail on the next run because that table already
existed. This commit adds a command to drop the
table so that the tests can be run several times
in sequence.
Prior to this commit, Inkling Systems was responsible for improving
and maintaining this module. The maintainer has moved on and Inkling
wished for Puppet Labs to continue with this modules maintenance.
This commit adjusts the README and Modulefile for this change in
ownership.
I had some issues trying to connect to the server, managed with
defaults:
vagrant@precise32:~$ psql
psql: FATAL: role "vagrant" does not exist
vagrant@precise32:~$ psql -U postgres
psql: FATAL: Peer authentication failed for user "postgres"
vagrant@precise32:~$ psql -U postgres -h 127.0.0.1
psql: FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL on
FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL off
vagrant@precise32:~$ psql -U postgres -h /var/run/postgresql
psql: FATAL: Peer authentication failed for user "postgres"
After some trial and error I found out that the reasons for this was
restrictive permissions on the unix socket (which isn't bad at all):
vagrant@precise32:~$ ls -l /var/run/postgresql/
total 4
-rw------- 1 postgres postgres 5 Oct 16 20:16 9.1-main.pid
So I though I send some usage examples to help noops like myself to a
quicker start with your module :-)
The postgresql init script on debian/ubuntu returns 0 no matter whether postgresql is started or stopped, so puppet has no way of knowing whether to start postgresql when the service is set to 'ensure => running'. This commit adds a param to the params class called $service_status which is set to the status piped to an egrep on debian/ubuntu, which reliably returns 0 if there are clusters running and 1 if there are none. The output before and after this patch can be seen below. If the init script is fixed at some point, the logic would need to be revisited.
Before patch postgresql remains stopped after puppet run.
$ # service postgresql stop
$ # * Stopping PostgreSQL 9.1 database server
$ # puppet apply -e "class {'postgresql::server':}"
$ # notice: Finished catalog run in 0.15 seconds
$ # service postgresql status
$ # Running clusters:
After patch postgresql is started after puppet run.
$ # service postgresql stop
$ # * Stopping PostgreSQL 9.1 database server
$ # puppet apply -e "class {'postgresql::server':}"
$ # notice: /Stage[main]/Postgresql::Server/Service[postgresqld]/ensure: ensure changed 'stopped' to 'running'
$ # notice: Finished catalog run in 2.26 seconds
$ # service postgresql status
$ # Running clusters: 9.1/main
The title I'd used for the persist-firewall resource
was too generic, and fairly likely to collide with
resources in other modules. This commit simply
renames it to be a bit more explicit about belonging
to this module, to reduce the likelihood of a title
collision.
This commit adds a new resource type that can be used to validate
that a successful postgres connection can be established from a
puppet node to a (potentially remote) postgres database instance.
Ubuntu's precise ships with init scripts, not with upstart service definitions. Declaring the provider to be upstart will cause service management on postgres to fail. Leaving it undefined will allow puppet to select the correct (init) provider.
