On current amazon linux ami (details below), and open puppet (details below), the postgres module (installed as part of puppetlabs/puppetdb) currently, tries to start postgressql server with /etc/init.d/postgresql9.4 , while the init script doesn't have the dot in the version number, so it needs to use /etc/init.d/postgresql94
From what I see in all available postgresql server rpms, currently on amazon linux ami, seems all the init scripts of postgresql doesn't have a dot in the suffix version number.
Supporting info:
[root@puppet ~]# yum list postgres* | grep 'server\.';
postgresql94-server.x86_64 9.4.5-1.63.amzn1 @amzn-updates
postgresql8-server.x86_64 8.4.20-4.51.amzn1 amzn-updates
postgresql92-server.x86_64 9.2.14-1.56.amzn1 amzn-updates
postgresql93-server.x86_64 9.3.10-1.60.amzn1 amzn-updates
for i in postgresql8-server.x86_64 postgresql92-server.x86_64 postgresql93-server.x86_64 postgresql94-server.x86_64; do echo $i; repoquery -l $i | grep init.d; done
postgresql8-server.x86_64
/etc/rc.d/init.d/postgresql
postgresql92-server.x86_64
/etc/rc.d/init.d/postgresql92
postgresql93-server.x86_64
/etc/rc.d/init.d/postgresql93
postgresql94-server.x86_64
[root@puppet ~]# puppet --version
4.3.2
[root@puppet ~]# rpm -qa | grep puppet | grep server
puppetserver-2.2.1-1.el6.noarch
[root@puppet ~]#
[root@puppet ~]# cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2015.09"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2015.09"
PRETTY_NAME="Amazon Linux AMI 2015.09"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2015.09:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"
[root@puppet ~]#
[root@puppet ~]# cat /etc/system-release
Amazon Linux AMI release 2015.09
The `$service_provider` variable in params.pp is user-definable via `postgresql::globals::service_provider`. Thus params.pp should reference that variable correctly, like other variables from globals.pp.
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
The /5/ regex on $::operatingsystemrelease would match any distro release
with a 5 in it, including for example Centos "7.1.1503". Given the commit
message for this regex, it was meant to match RedHat / Centos 5.x.
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
* 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
```
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.
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.
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 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.
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.
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'.
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.
