module-postgresql/manifests/server/config.pp

182 lines
6.5 KiB
ObjectPascal
Raw Normal View History

# PRIVATE CLASS: do not call directly
class postgresql::server::config {
$ip_mask_deny_postgres_user = $postgresql::server::ip_mask_deny_postgres_user
$ip_mask_allow_all_users = $postgresql::server::ip_mask_allow_all_users
$listen_addresses = $postgresql::server::listen_addresses
$port = $postgresql::server::port
$ipv4acls = $postgresql::server::ipv4acls
$ipv6acls = $postgresql::server::ipv6acls
$pg_hba_conf_path = $postgresql::server::pg_hba_conf_path
$pg_ident_conf_path = $postgresql::server::pg_ident_conf_path
$postgresql_conf_path = $postgresql::server::postgresql_conf_path
$recovery_conf_path = $postgresql::server::recovery_conf_path
$pg_hba_conf_defaults = $postgresql::server::pg_hba_conf_defaults
$user = $postgresql::server::user
$group = $postgresql::server::group
$version = $postgresql::server::_version
$manage_package_repo = $postgresql::server::manage_package_repo
$manage_pg_hba_conf = $postgresql::server::manage_pg_hba_conf
$manage_pg_ident_conf = $postgresql::server::manage_pg_ident_conf
$manage_recovery_conf = $postgresql::server::manage_recovery_conf
$datadir = $postgresql::server::datadir
$logdir = $postgresql::server::logdir
$service_name = $postgresql::server::service_name
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
if ($manage_pg_hba_conf == true) {
# Prepare the main pg_hba file
concat { $pg_hba_conf_path:
owner => $user,
group => $group,
mode => '0640',
warn => true,
notify => Class['postgresql::server::reload'],
}
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
if $pg_hba_conf_defaults {
Postgresql::Server::Pg_hba_rule {
database => 'all',
user => 'all',
}
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
# Lets setup the base rules
$local_auth_option = $version ? {
'8.1' => 'sameuser',
default => undef,
}
postgresql::server::pg_hba_rule { 'local access as postgres user':
type => 'local',
user => $user,
auth_method => 'ident',
auth_option => $local_auth_option,
order => '001',
}
postgresql::server::pg_hba_rule { 'local access to database with same name':
type => 'local',
auth_method => 'ident',
auth_option => $local_auth_option,
order => '002',
}
postgresql::server::pg_hba_rule { 'allow localhost TCP access to postgresql user':
type => 'host',
user => $user,
address => '127.0.0.1/32',
auth_method => 'md5',
order => '003',
}
postgresql::server::pg_hba_rule { 'deny access to postgresql user':
type => 'host',
user => $user,
address => $ip_mask_deny_postgres_user,
auth_method => 'reject',
order => '004',
}
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
postgresql::server::pg_hba_rule { 'allow access to all users':
type => 'host',
address => $ip_mask_allow_all_users,
auth_method => 'md5',
order => '100',
}
postgresql::server::pg_hba_rule { 'allow access to ipv6 localhost':
type => 'host',
address => '::1/128',
auth_method => 'md5',
order => '101',
}
}
# ipv4acls are passed as an array of rule strings, here we transform
# them into a resources hash, and pass the result to create_resources
$ipv4acl_resources = postgresql_acls_to_resources_hash($ipv4acls,
'ipv4acls', 10)
create_resources('postgresql::server::pg_hba_rule', $ipv4acl_resources)
# ipv6acls are passed as an array of rule strings, here we transform
# them into a resources hash, and pass the result to create_resources
$ipv6acl_resources = postgresql_acls_to_resources_hash($ipv6acls,
'ipv6acls', 102)
create_resources('postgresql::server::pg_hba_rule', $ipv6acl_resources)
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
}
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
# We must set a "listen_addresses" line in the postgresql.conf if we
# want to allow any connections from remote hosts.
postgresql::server::config_entry { 'listen_addresses':
value => $listen_addresses,
}
postgresql::server::config_entry { 'port':
value => $port,
}
postgresql::server::config_entry { 'data_directory':
value => $datadir,
}
if $logdir {
postgresql::server::config_entry { 'log_directory':
value => $logdir,
}
}
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
# RedHat-based systems hardcode some PG* variables in the init script, and need to be overriden
# in /etc/sysconfig/pgsql/postgresql. Create a blank file so we can manage it with augeas later.
if ($::osfamily == 'RedHat') and ($::operatingsystemrelease !~ /^7/) and ($::operatingsystem != 'Fedora') {
Remove the ensure => absent uninstall code. 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.
2014-07-02 16:45:07 +02:00
file { '/etc/sysconfig/pgsql/postgresql':
ensure => present,
replace => false,
}
# The init script from the packages of the postgresql.org repository
# sources an alternate sysconfig file.
# I. e. /etc/sysconfig/pgsql/postgresql-9.3 for PostgreSQL 9.3
# Link to the sysconfig file set by this puppet module
file { "/etc/sysconfig/pgsql/postgresql-${version}":
ensure => link,
target => '/etc/sysconfig/pgsql/postgresql',
require => File[ '/etc/sysconfig/pgsql/postgresql' ],
}
}
if ($manage_pg_ident_conf == true) {
concat { $pg_ident_conf_path:
owner => $user,
group => $group,
force => true, # do not crash if there is no pg_ident_rules
mode => '0640',
warn => true,
notify => Class['postgresql::server::reload'],
}
}
if ($manage_recovery_conf == true) {
concat { $recovery_conf_path:
owner => $user,
group => $group,
force => true, # do not crash if there is no recovery conf file
mode => '0640',
warn => true,
notify => Class['postgresql::server::reload'],
}
}
if $::osfamily == 'RedHat' {
if $::operatingsystemrelease =~ /^7/ or $::operatingsystem == 'Fedora' {
file { 'systemd-override':
ensure => present,
path => "/etc/systemd/system/${service_name}.service",
owner => root,
group => root,
content => template('postgresql/systemd-override.erb'),
notify => [ Exec['restart-systemd'], Class['postgresql::server::service'] ],
before => Class['postgresql::server::reload'],
}
2015-01-11 05:27:57 +01:00
exec { 'restart-systemd':
command => 'systemctl daemon-reload',
refreshonly => true,
path => '/bin:/usr/bin:/usr/local/bin'
}
}
}
}