module-postgresql/manifests/server/initdb.pp

127 lines
4.3 KiB
ObjectPascal
Raw Normal View History

# PRIVATE CLASS: do not call directly
class postgresql::server::initdb {
$needs_initdb = $postgresql::server::needs_initdb
$initdb_path = $postgresql::server::initdb_path
$datadir = $postgresql::server::datadir
$xlogdir = $postgresql::server::xlogdir
$logdir = $postgresql::server::logdir
$encoding = $postgresql::server::encoding
$locale = $postgresql::server::locale
$group = $postgresql::server::group
$user = $postgresql::server::user
$psql_path = $postgresql::server::psql_path
$port = $postgresql::server::port
# Set the defaults for the postgresql_psql resource
Postgresql_psql {
psql_user => $user,
psql_group => $group,
psql_path => $psql_path,
port => $port,
}
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
# Make sure the data directory exists, and has the correct permissions.
file { $datadir:
ensure => directory,
owner => $user,
group => $group,
mode => '0700',
}
if($xlogdir) {
# Make sure the xlog directory exists, and has the correct permissions.
file { $xlogdir:
ensure => directory,
owner => $user,
group => $group,
2013-09-21 19:45:35 +02:00
mode => '0700',
}
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($logdir) {
# Make sure the log directory exists, and has the correct permissions.
file { $logdir:
ensure => directory,
owner => $user,
group => $group,
}
}
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($needs_initdb) {
# Build up the initdb command.
#
# We optionally add the locale switch if specified. Older versions of the
# initdb command don't accept this switch. So if the user didn't pass the
# parameter, lets not pass the switch at all.
$ic_base = "${initdb_path} --encoding '${encoding}' --pgdata '${datadir}'"
$ic_xlog = $xlogdir ? {
undef => $ic_base,
default => "${ic_base} --xlogdir '${xlogdir}'"
}
# The xlogdir need to be present before initdb runs.
# If xlogdir is default it's created by package installer
if($xlogdir) {
$require_before_initdb = [$datadir, $xlogdir]
} else {
$require_before_initdb = [$datadir]
}
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
$initdb_command = $locale ? {
undef => $ic_xlog,
default => "${ic_xlog} --locale '${locale}'"
}
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
# This runs the initdb command, we use the existance of the PG_VERSION
# file to ensure we don't keep running this command.
exec { 'postgresql_initdb':
command => $initdb_command,
creates => "${datadir}/PG_VERSION",
user => $user,
group => $group,
logoutput => on_failure,
require => File[$require_before_initdb],
}
# The package will take care of this for us the first time, but if we
# ever need to init a new db we need to copy these files explicitly
if $::operatingsystem == 'Debian' or $::operatingsystem == 'Ubuntu' {
if $::operatingsystemrelease =~ /^6/ or $::operatingsystemrelease =~ /^7/ or $::operatingsystemrelease =~ /^10\.04/ or $::operatingsystemrelease =~ /^12\.04/ {
file { 'server.crt':
ensure => file,
2015-01-11 05:27:57 +01:00
path => "${datadir}/server.crt",
source => 'file:///etc/ssl/certs/ssl-cert-snakeoil.pem',
owner => $::postgresql::server::user,
group => $::postgresql::server::group,
mode => '0644',
2015-01-11 05:27:57 +01:00
require => Exec['postgresql_initdb'],
}
file { 'server.key':
ensure => file,
2015-01-11 05:27:57 +01:00
path => "${datadir}/server.key",
source => 'file:///etc/ssl/private/ssl-cert-snakeoil.key',
owner => $::postgresql::server::user,
group => $::postgresql::server::group,
mode => '0600',
2015-01-11 05:27:57 +01:00
require => Exec['postgresql_initdb'],
}
}
}
2014-12-05 10:24:32 +01:00
} elsif $encoding != undef {
# [workaround]
# by default pg_createcluster encoding derived from locale
# but it do does not work by installing postgresql via puppet because puppet
# always override LANG to 'C'
postgresql_psql { "Set template1 encoding to ${encoding}":
command => "UPDATE pg_database
SET datistemplate = FALSE
WHERE datname = 'template1'
;
UPDATE pg_database
SET encoding = pg_char_to_encoding('${encoding}'), datistemplate = TRUE
WHERE datname = 'template1'",
unless => "SELECT datname FROM pg_database WHERE
datname = 'template1' AND encoding = pg_char_to_encoding('${encoding}')",
2014-12-05 10:24:32 +01:00
}
}
}