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>
I'd like to see this patch included ASAP -- the desirable default could
be manage_pg_ident_conf => true, but one could already manage this file
manually : we don't want to wipe it.
Please switch the default from false to true at the next major release
and write a line about this in the release notes.
This defined type helps create database schemas, and assign them to an
`owner`. It is closely modeled after Postgresql::Server::Tablespace.
It uses PostgreSQL's builtin IF NOT EXISTS to guarantee idempotency.
(>= 9.3, else it checks pg_namespace).
n.b.: This defined type *requires* that a `db` is passed. This is a
concious design decision, since we find it rather useless to create such
schemas in the default `postgres` database, and if *were* useful, one
can always "over-specify".
This addresses MODULES-1098.
This is likely to be a controversial change so I wanted to put some
explanation of our reasoning into the commit message. This gets
kind of complex so I'll start with the problem and then the reasoning.
Problem:
We rely heavily on the ability to uninstall and reinstall postgres
throughout our testing code, testing features like "can I move from the
distribution packages to the upstream packages through the module" and
over time we've learnt that the uninstall code simply doesn't work a lot
of the time. It leaves traces of postgres behind or fails to remove
certain packages on Ubuntu, and generally causes bits to be left on your
system that you didn't expect.
When we then reinstall things fail because it's not a true clean slate,
and this causes us enormous problems during test. We've spent weeks and
months working on these tests and they simply don't hold up well across
the full range of PE platforms.
Reasoning:
Due to all these problems we've decided to take a stance on uninstalling
in general. We feel that in 2014 it's completely reasonable and normal
to have a good provisioning pipeline combined with your configuration
management and the "correct" way to uninstall a fully installed service
like postgresql is to simply reprovision the server without it in the
first place. As a general rule this is how I personally like to work
and I think is a good practice.
WAIT A MINUTE:
We understand that there are environments and situations in which it's
not easy to do that. What if you accidently deployed Postgres on
100,000 nodes? When this work is finished I'm going to take a look at
building some example 'profiles' to be found under examples/ within this
module that can uninstall postgres on popular platforms. These can be
modified and used in your specific case to uninstall postgresql. They
will be much more brute force and reliant on deleting entire directories
and require you to do more work up front in specifying where things are
installed but we think it'll prove to be a much cleaner mechanism for
this kind of thing rather than trying to weave it into the main module
logic itself.
This doesn't fix the root cause of the issue, such as the fact that
dpkg can't do wildcard removals, and the uninstall fails when you're
passing in a version number like this, but THIS test doesn't care, it
just wants to make sure the deprecation warning appears in the first
place.
This does however make the tests pass on 14.04.
The validate_db_connection class takes a user to connect as, but if we're
using the progresql::server::db defined type then the user might not be
created yet, and might not have any permissions granted yet. This patch
users a collector to ensure that the that the user and grants are active
before validating.
We now test if service_ensure is 'running' or 'stopped' but it was
actually picking up the default value of ensure in params.pp which
was true, not present.
Fix this and thereby fix the failing test.
Adjusting the version is explicitly done though the postgresql::globals
class, as this affects many parts of the module. This parameter did not
function correctly on systems that did not have a default, as described
in the ticket.
On FreeBSD systems the $user variable is not 'postgres' so does not
match the default database correctly. These changes use the existing
default_database parameter to replace instances where $user is passed as
the database to be connected to.
These changes are in server::database, server::role and
server::grant.
FreeBSD needs /usr/local/bin in PATH in order to find bash. This does
require that the node has the bash port installed. It might be desired
that a separate script was provided for FreeBSD which used its /bin/sh,
this could be done by changing the for loop in the script to use
for c in $(jot $TRIES)
in place of
for (( c=1; c<=$TRIES; c++ ))
Allows for OS specific $user and $group value specification. For most of
the target operating systems these will both be 'postgres'. For FreeBSD
however these values are 'pgsql'.
At present, the ownership of pg_hba.conf is hardwired to be uid 0. It should have the same ownership as all of the other postgressql configuration files in the same cluster so that they can be managed/edited by the postgres role user (system) account.
The warnings are as follows:
Warning: Scope(Concat::Fragment[pg_hba_rule_deny access to postgresql user]): The $mode parameter to concat::fragment is deprecated and has no effect
Warning: Scope(Concat::Fragment[pg_hba_rule_deny access to postgresql user]): The $owner parameter to concat::fragment is deprecated and has no effect
This commit modifies postgresql::validate_db_connection to use the
default_database parameter from postgresql::params rather than
hard-coding a local default value of "postgres".
This makes the variable consistent with the manner in which most/all of
the rest of the postgresql module currently works.
Commit also adds the new param to the README file.
E.g. pe-postgresql does NOT use postgres as the default database name.
It uses pe-postgres. So if there is no way to specify a default database
name, the postgesql::validate_db_connection resource in
postgresql::server::service will ALWAYS fail. This commit exposes the
parameter in order to avoid that situation.
Since the class is now throwing an error when you use the class directly,
I'm just removing it.
We left this in from the last rewrite as someone reported an issue a long
time ago, but alas we have been unable to prove its a problem.
Signed-off-by: Ken Barber <ken@bob.sh>
This patch is a fix for the race condition that keeps occuring during
postgresql setup. Its very rare on its own, but when you are using this
module in a CI environment it happens quite frequently.
Basically what happens is that sometimes the service will announce the
database has started, but really it is still working in the background.
Sometimes the unix socket may not be listening, and sometimes the
system is still loading and you get a weird client error.
The fix itself is a modification to postgresql::validate_db_connection
so that it is able to connect on the local unix socket, plus retry
until the database is available.
This new and improved validate_db_connection can then be put into the
build pipeline (in the service class in particular) to ensure the
database is started before continuing on with the remaining steps.
This in effect blocks the puppet module from continuing until the
postgresql database is fully started and able to receive connections
which is perfect.
Tests and documentation provided.
Signed-off-by: Ken Barber <ken@bob.sh>
