postgresql_escape returned an invalid string if the password end in '$':
postgres=# alter role "postgres" password $$foo$$$;
ERROR: syntax error at or near "$"
LINE 1: alter role "postgres" password $$foo$$$;
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
When executing a command with environment variables, the withenv helper
under Puppet 2.7 is on Puppet::Util::Execution and on 3.0 to 3.3, it's
on Puppet::Util.
`Puppet::Util::SUIDManager.run_and_capture` (in puppet < 3.4) returns an
array of the output and the `Process::Status` object.
`Puppet::Util::Execution.execute` (in puppet >= 3.4) returns the output
and saves the `Process::Status` object to `$CHILD_STATUS`
This is handled in the provider, but the type was also trying to handle
it, and was not last updated when the provider was.
This allows you to use `postgres_pqsl` commands to be run against a specified host. The ultimate goal being that you can use `puppetlabs-postsgresql` to run against remote instances, especially things such as Amazons RDS service.
This PR will be further extended to do things like allow remote `table_grant` and the like.
Interactions between resource refreshes and the 'unless' parameter have been
fixed to follow the behaviour of the 'exec' type.
The 'unless' parameter is now always taken into account, whether in ordinary
operation, during a refresh, or when refreshonly is set to true. The resource
will not run the SQL command when the 'unless' clause matches a row.
Previously a refresh on a resource would ignore the 'unless' parameter if set
which could cause a failure re-running a command, such as attempting to create
a role that already exists.
The following examples have been fixed:
* should not run SQL when refreshed and the unless query returns rows
* with refreshonly should not run SQL when the unless query returns no rows
* with refreshonly should not run SQL when refreshed and the unless query
returns rows
This is done by moving the logic for refreshonly and whether to run the SQL
command from the provider into the type, and consolidating it in the
should_run_sql method which is called during 'command' property retrieval
(instead of sync) and during refresh.
Resolves this warning on puppet 3.4.2:
Warning: Puppet::Util::SUIDManager.run_and_capture is deprecated; please
use Puppet::Util::Execution.execute instead.
This patch also fixes the postgresql_psql provider's broken puppet "4"
support.
This allows you to set a schema search_path on postgresql_psql
resources, in case you have multiple schemas in your database and the
SQL you are trying to run requires a different path
This is a very very large change to the module. It started out as a fix to add
postgresl::server::config_entry, and quickly became a rewrite to fix a lot of
ordering issues inherent in the API.
Since this changes the Public API it is considered a backwards compatible
change.
See the upgrading guide in README.md for more details as to what has been
modified in this patch.
Signed-off-by: Ken Barber <ken@bob.sh>
This includes the following changes:
- Hooking up pgconf module to postgresql to manage postgresql.conf
- pgconf includes a type and provider for postgresql.conf the provider
is a simple parsed file following basic ini parsing.
- Add config_entry.pp which wraps the pgconf module.
- Replace file_line resources by postgresql::config_entry in beforeservice.pp
- Adding unit tests for the newly introduced functionality
Puppet::Type supports `:boolean => true` to create a
`resource.<property>?` method that is true or false based on the
`:true`, `:false`, `true`, or `false` value of the parameter.
This will allow accurate assesment of the refreshonly attribute for
testing.
This allows non-standard users (pe-postgres) to change passwords. Also
added a function to do escaping of the password, added system tests
and rspec tests for the function.
This has been discussed in issue #148. The postgresql_psql type doesn't
change the CWD to something safe when running psql as the postgres user.
During a regular puppet run the CWD remains "/root", to which the
postgres user usually does not have access, resulting in failed psql
calls and failed puppet runs. This simple change makes "/tmp" the
default CWD for postgresql_psql.
This patch provides a more advanced way of managing pg_hba rules, by providing a
defined resource to manage a pg_hba file, and a defined resource for managing
rules within such a file (pg_hba_rule).
These new resources are wrappers around ripinaar-concat, and utilise file
assemblies instead of a template to compose the pg_hba.conf file.
I've provided a function that interprets the old ip4|6acl arrays and converts
them to this new format for backwards compatibility as well.
I slightly reformatted our documentation to allow for better documentation of
defined resources in 'Usage' as well, and provided examples of how to use this
new resource.
This hopefully should go a long way to solving the PR's related to lack of full
functionality for pg_hba.conf.
Signed-off-by: Ken Barber <ken@bob.sh>
This patch includes some very basic and initial unit testing using rspec-puppet
and for the case of facts, just normal rspec.
I've taken a very light approach here as rspec-puppet can be quite combinatorial
when one gets carried away. For now I've just added basic compile failure
detection effectively for classes and defined resources. As we continue to work
on the code and find regressions this work can be expanded.
For facts and functions I've also taken a basic approach for now.
One little thing I did change, was the strange string that the fact returns
when the default version is undefined. Instead of an error message I've just
returned the string 'unknown' which is more in line with other facts I've seen
in the wild, and to be quite honest 'unknown' is fairly self-explantory. Since
a fact isn't an error reporting message this seemed more appropriate, and looked
nicer in the rspec test.
As far as travis-ci support, I've added the same configuration that @jmmcune
came up with for stdlib which is pretty light and reasonable standard now we
propogated that to 4 or so other modules in the puppetlabs/ namespace. It should
work out of the box.
Signed-off-by: Ken Barber <ken@bob.sh>
/etc/debian_version on Wheezy was updated to 7.0 with the release of the
base-files package on 2012-12-12, which means that wheezy could be
either 7.0 or wheezy depending on what version of base-files is
installed. To handle both cases we treat 'wheezy' and '7.*' as
synonymous.
A commit that I merged yesterday broke the default version fact
such that it would sometimes return nil and sometimes an error message
if your distro wasn't supported. This commit makes it consistent again.