Currently postgresql::server::schema, postgresql::server::db and
postgresql::server::database allow creating new schemas and
databases if they don't already exist and assigning owners to
them. This patch enables changing the owner of a schema or database
that already exists if the change_ownership variable is set to true.
Empty require/before relationships in the server extension package
resource are changed from undef to empty arrays to work around PUP-6385
in Puppet 4.5.x. Previously undef was passed literally through
create_resources() causing Puppet to fail to find the resource named
`undef`.
Prior to this commit, when creating databases with a name or owner that has
characters which must be quoted (e.g., "pe-postgres"), the postgresql::server::database define
fails due to a SQL syntax error.
When using a database name that contains dashes or underscores, the
CREATE DATABASE statement fails with a syntax error. Use double quotes
around the database name to solve this.
This adds the ability to define the extension name separately from the
"title" of the resource, which allows you to add the extension to more
than one database.
As per the original ticket, extensions in postgresql can be defined on
a per database basis. By using the same name for both the extension and
the instance of postgresql::server::extension, you're getting duplicates
errors if you try to assign an extension to more than one database
Adds connection-settings (for remote DB support) when creating DB resources.
Connection-settings allows a hash of options that can be used
when connecting the a remote DB (such as PGHOST, PGPORT, PGPASSWORD
PGSSLKEY) and a special option DBVERSION indicating the version
of the remote database.
Including
- Puppet updates
- Documentation updates
- RSpec unit test updates
- RSpec acceptance test updates
- Some test coverage for connection-settings
- Working acceptance test...
Basic vagrant setup:
* Two boxes, server and client
* Runs puppet code to on server to setup a postgres server that allows all connections and md5 connections, creates db puppet to look at
* Runs puppet code on client to make a server that a psql command can be run against puppet db on other server
* Does some fancy stuff to get the fact of the IP from the first server to connect to
- Backwards compatible, with deprecation warnings around old parameters
This change allows the pg_hba_rule defined type to be used
even if you have not included postgresql::server.
By default it will continue with the same behavior as before,
however, you can now specify some extra parameters that were
previously coming directly from postgresql::server
$manage_package_repo wasn't in scope for the template systemd-override.erb
This was causing all RHEL7 systems with manage_package_repo on to fail on
startup using systemctl, as the proper path to the original service file
is set incorrectly.
This patch adds the manage_package_repo to the top of the ::config class,
and adds some basic tests in config_spec.rb to ensure we don't regress on
this.
Signed-off-by: Ken Barber <ken@bob.sh>
Since postgresql-9.1_9.1.16-0+deb7u1 on wheezy, postgresql can't read
snakeoil certificate as symlink anymore, so server does not restart.
This patch copies cert and key instead of symlinking so that it works
again.
Currently there is no resource to use for creating the recovery.conf
This resource can create a recovery.conf for replication with all
currently supported parameters
on OpenBSD puppet 3.7.4, with future parser, and ruby 2.1.5.
Without the change, ran into error:
Info: Loading facts
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: I
nvalid parameter environment on Postgresql_psql[CREATE ROLE puppetdb ENCRYPTED P
ASSWORD ****] at /etc/puppet/environments/production/modules/postgresql/manifest
s/server/role.pp:46 on node puppetdb.srv.intern
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
I guess the future parser requires adhering to the order?
Discussed in https://tickets.puppetlabs.com/browse/MODULES-1869
It seems env variables passed via `exec`'s `environment` parameter must
not be single-quoted, otherwise the single-quotes are interpreted
literally in the command strings in `command` and `unless`. For a
postgres password of `foobar` this leads to the `unless` code trying to
use literally `'foobar'` as password, and the `psql` line in `command`
setting literally `'$$foobar$$'` as password.
