When the psql command runs from a directory it does not have permission to
access, it outputs an error. This error trips up the unless SQL command,
causing the other SQL commands to run even if not needed. Rather than ignore
stderr (which might hide something else), or use an arbitrary directory like
/tmp, this code sets the cwd to the data directory, which will exist and be
owned by the postgres user. If someone uses the postgres_psql type and
customises the psql_user parameter, they should also set an appropriate cwd.
The GPG key for yum.postgresql.org was in the wrong directory,
and as written, would have only supported postgres 9.2 anyway.
I looked at the yum rpms for a few other versions besides 9.2,
and they appear to be using the same GPG key. So this commit
assumes that they all are doing so, and it sets things up
accordingly. Hopefully this will make the yumrepo support
compatible with other versions of postgres besides 9.2, but I
haven't added that to the actual test matrix yet.
This commit fixes up the `postgres_default_version` fact so that
it doesn't use apt/yum (slow), and instead just has a hard-coded
list of default postgres versions for various OS versions. We
will need to add new OS versions to this fact over time, but that
seems preferable to the previous implementation which was causing
slower puppet runs on all nodes (regardless of whether they were
actually using postgres or not).
Thanks to some tricks I learned from Nan Liu and Dan Bode, I was
able to figure out a way to move all of the new version-related stuff
back into the params class, and clean up some of the if/_real stuff.
Basic tests for centos6 + pg 9.2 are passing.
Nan showed me a trick that will let us keep all of that param stuff
inside of params.pp, make it a parameterized class, and still support
the ability for users to specify a custom (non-system-default) pg
version. This commit takes the first step towards that pattern by
consolidating platform.pp and params.pp. (Everything old is new again!)
This commit creates a new class called `package_source_info`,
which has some initial framework for managing the postgresql.org
yumrepo. It also serves as a container for the 'version'
variable that is needed by the 'platform' class in order to
use other versions of postgres besides the system default.
The service provider / status stuff got a little broken during
the refactors. This should mostly fix it but there is still
one spec failing, and I will probably also refactor the
paths.pp and packages.pp into a single file together eventually.
This commit does a fairly major refactor of how the spec tests
are laid out. The main goal was to make it easier to run
a subset of the tests--e.g., the ability to only run tests
on a single OS via a simple rspec command.
The test logic is now defined in some shared examples in the
`support` directory. There are now spec folders for each
distro, which contain some stubs to include the shared examples
as well as a Vagrantfile for the particular distro.
Also, the system-default postgres package tests now run
successfully against the CentOS6 VM that is defined by the
Vagrantfile.
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.
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.
