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
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.
This commit adds a postgresql::db type for convenience;
it mirrors the 'db' type from the mysql module, which
allows you to create a database instance and user plus
grant privileges to that user all in one succint
resource.
This commit also improves security in the following ways:
* Revoke "CONNECT" privilege from the 'public' role for
newly created databases; without this, any database
created via this module will allow connections from
any database user, and will allow them to do things
like create tables.
* Change to a 'reject'-based policy for dealing with
remote connections by the postgres user in pg_hba.conf.
Prior to this commit, if you tried to restrict access
to the postgres user by IP, the rule would simply not
match for disallowed IPs; then it would fall through
to the rule for "all" users, which could still match
and thus allow the postgres user to connect remotely.
Renamed a few files and made some tweaks to try to get
database_grant, database_user, and database types into
a state where they work very similarly to the ones in
the mysql module. Also introduced a "postgresql_password"
function that can be used to generate an md5 password
hash for a postgres user.
This commit adds some configuration management for
postgres, to allow users to get a more complete
setup from their initial install. Prior to this
commit, we were basically only ensuring that the
package was installed and the service was running.
Now, we support limited configuration for the
pg_hba.conf file to enable md5 authentication for
remote hosts, and for the postgresql.conf file
to specify the listener addresses where TCP
connections should be accepted. Without these
two changes the initial postgres configuration
doesn't allow *any* connections from outside of the
local host.
This commit also adds an option for opening up the
postgres port in the firewall on redhat-based systems,
and an option to allow setting the password for the
'postgres' database user.
As of this commit, this module now has dependencies
on puppetlabs-stdlib (version > 2.3.4, which includes
the new 'match' parameter for the 'file_line' resource
type), and on puppetlabs-firewall.
This is a first working version of postgresql::server.
It includes a very simple test manifest, which has
been tried out on CentOS6 and Ubuntu 10.04; initial
tests were successful both from a clean state and
for subsequent runs.
Includes a new fact called 'postgres_default_version',
which detects what the default version of postgres is
for a given OS. This is needed because some of the
commands and directory names include this version string.
Current implementation *only* supports managing the
system default version; in the future it would be nice
to allow the user to explicitly specify a postgres version,
but that isn't yet supported.
The "postgresql::server" class includes a call to postgres's
initdb command on redhat systems, because they don't do
this automatically when the package is installed.
