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?
* Add param `validcon_path` in `postgresql::client` (defaults to
previous hard coded value).
* Add tests for this new parameter.
All tests runs successfully on Scientific Linux 6.4
```
$ bundle exec rake spec SPEC_OPTS='--format documentation'
[...]
Finished in 2 minutes 10.5 seconds (files took 1.4 seconds to load)
201 examples, 0 failures
```
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.
Added $service_reload parameter to params.pp, in order to allow
a reload of the postgresql server on OpenBSD, which apparently doesn't
have a service binary.
Define a proper SELECT statement to feed into Postgresql_psql's
`unless` parameter that checks if there are any tables in the specified
schema for which the specified role *does not* have the specified
privilege. Only then allow the GRANT statement to be executed. For
details see comments.
Note that this, too, suffers from the problem that there is no feasible
way to check if a role has ALL PRIVILEGES on a table in plain SQL. By
terrible convention the INSERT privilege represents ALL PRIVILEGES here.
The PostgreSQL server's port is specified in `postgresql::server::port`, so use it in the `unless` clause of `Exec['set_postgres_postgrespw']`. Failing to do so results in repeated invocations of the exec resource during Puppet runs when the server's port is not set to the default of 5432.
On psql 8.1, `pg_catalog.shobj_description` does not exist. Also, if the
database to comment is not the current db then this warning will be
raised and the comment will not be applied: `WARNING: database comments
may only be applied to the current database`
This fix uses the pg_* databases to find the comment based on the
database oid rather than the shared object description function.
On psql 8.1, `pg_catalog.shobj_description` does not exist. Also, if the
database to comment is not the current db then this warning will be
raised and the comment will not be applied: `WARNING: database comments
may only be applied to the current database`
This fix uses the pg_* databases to find the comment based on the
database oid rather than the shared object description function.
The postgresql user is created by the server package, but this file
resource may be evaluated before the package is installed resulting in
permission failures.
It would be enabled, but it wouldn't work properly. This fixes that
issue the same way Puppet does itself; use the onestart/onestop and most
importantly in this case, the onestatus command.
By using this approach it means the Database server will actually start
whereas it would not before. It would enable, but not actually start.
onestatus means the service type gets the right response and behaves
properly.
The change introduced in b781849882 added
a complex operation that was not handled correctly for all operating
systems. This fix includes the following corrections:
- Change the systemd config and reload systemd for datadir changes in
RHEL 7, and move configuration for this into
postgresql::server::config since it is managing both the PGDATA and
PGPORT variables
- Make sure Debian systems stop the service before changing the datadir
- Recreate cert links after running initdb in Debian and early ubuntu
- Change the port in the port spec to avoid selinux issues
- Turn off selinux in pgdata spec to avoid selinux issues
- Correct syntax for describing presence of a directory in pgdata spec
- Move the pgdata spec to the end of the tests so that puppet doesn't
have to manager purging and recreating the original datadir
- Update README to describe all caveats of using this parameter
Ensure that data_directory is set in the config. per GitHub user tbd - PR#510 / PR#494 that was filed against wrong module branch"
Adds acceptance test for non default PGDATA, based on alternative_port_spec.rb
Fixes unit test for data directory
Since facter 2.2.0 'fixed' the lsbmajdistrelease fact for Ubuntu, we now have to regexp
for the value. The new value would be '10.04' whereas the old is '10'.
Signed-off-by: Ken Barber <ken@bob.sh>
