Prior to this commit, Inkling Systems was responsible for improving
and maintaining this module. The maintainer has moved on and Inkling
wished for Puppet Labs to continue with this modules maintenance.
This commit adjusts the README and Modulefile for this change in
ownership.
I had some issues trying to connect to the server, managed with
defaults:
vagrant@precise32:~$ psql
psql: FATAL: role "vagrant" does not exist
vagrant@precise32:~$ psql -U postgres
psql: FATAL: Peer authentication failed for user "postgres"
vagrant@precise32:~$ psql -U postgres -h 127.0.0.1
psql: FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL on
FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user
"postgres", database "postgres", SSL off
vagrant@precise32:~$ psql -U postgres -h /var/run/postgresql
psql: FATAL: Peer authentication failed for user "postgres"
After some trial and error I found out that the reasons for this was
restrictive permissions on the unix socket (which isn't bad at all):
vagrant@precise32:~$ ls -l /var/run/postgresql/
total 4
-rw------- 1 postgres postgres 5 Oct 16 20:16 9.1-main.pid
So I though I send some usage examples to help noops like myself to a
quicker start with your module :-)
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.
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.
