Package (postfix) is not reconfigured if the preseed file is changed
44 views
Skip to first unread message
na...@hu.inter.net
Dec 29, 2014, 8:58:28 AM12/29/14
to puppet...@googlegroups.com
I've implemented a similar solution to generate a preseed file for postfix as describe in http://projects.puppetlabs.com/projects/1/wiki/debian_preseed_patterns.
The basic difference is that I created a puppet template for the pressed file with some parameters. But it seems that the solution suggested in the wiki page above is working only on the first installation. If the package is already installed and something is changed, than the new preseed file is installed on the puppet agent, but after that nothing happens. I have to run manually "dpkg-reconfigure -f noninteractive postfix".
Any idea?
Thanks
Tibor
jcbollinger
Jan 5, 2015, 10:28:40 AM1/5/15
to puppet...@googlegroups.com
On Monday, December 29, 2014 7:58:28 AM UTC-6, na...@hu.inter.net wrote:
I've implemented a similar solution to generate a preseed file for postfix as describe in http://projects.puppetlabs.com/projects/1/wiki/debian_preseed_patterns.The basic difference is that I created a puppet template for the pressed file with some parameters. But it seems that the solution suggested in the wiki page above is working only on the first installation. If the package is already installed and something is changed, than the new preseed file is installed on the puppet agent, but after that nothing happens. I have to run manually "dpkg-reconfigure -f noninteractive postfix".
That is the nature of a preseed file: it provides installation-time information for the package. More specifically, it configures apt with respect to how to install the named package; it does not configure the package itself.
That approach is fine if you are using Puppet strictly for provisioning (at least with respect to the preseeded packages), and especially if you are migrating from a provisioning approach that relies on preseed files. The article you linked asks "Why bother clobbering a config file that is automatically generated out of debconf anyway?" as if there were no good answer. If you intend to have ongoing Puppet management of the configuration of the installed services, however, then the preseed file approach isn't a very good fit, as you discovered. In that case, you would be better off with the standard model described at the top of the article, under "Normally you would just do something like the following."
If you insist on continuing with the preseed file, then you need to add something like this to your preseed_package type:
Note, too, that the above provides a complete solution only if dpkg-reconfigure can be relied upon to restart the service when it reconfigures it, but in that case you have the service's run status managed in two different places. Otherwise, you need to add appropriate relationships to the Service['postfix'] resource, which cannot be done cleanly because the resources that need to be related are declared in different scopes (the relationships can nevertheless be declared, though). This all makes the preseed approach a bit messy for continuing management. It's in any case not any easier than the normal approach, and it's probably harder unless you start with preseed files already in hand.
John
That approach is fine if you are using Puppet strictly for provisioning (at least with respect to the preseeded packages), and especially if you are migrating from a provisioning approach that relies on preseed files. The article you linked asks "Why bother clobbering a config file that is automatically generated out of debconf anyway?" as if there were no good answer. If you intend to have ongoing Puppet management of the configuration of the installed services, however, then the preseed file approach isn't a very good fit, as you discovered. In that case, you would be better off with the standard model described at the top of the article, under "Normally you would just do something like the following."
If you insist on continuing with the preseed file, then you need to add something like this to your preseed_package type:
exec { "${name}_preseed_update":
command => "dpkg-reconfigure -f noninteractive ${name}",
path => "/sbin:/bin:/usr/sbin:/usr/bin",
refreshonly => true,
subscribe => File["/var/local/preseed/${name}.preseed"]
}
Note, too, that the above provides a complete solution only if dpkg-reconfigure can be relied upon to restart the service when it reconfigures it, but in that case you have the service's run status managed in two different places. Otherwise, you need to add appropriate relationships to the Service['postfix'] resource, which cannot be done cleanly because the resources that need to be related are declared in different scopes (the relationships can nevertheless be declared, though). This all makes the preseed approach a bit messy for continuing management. It's in any case not any easier than the normal approach, and it's probably harder unless you start with preseed files already in hand.
John
Reply all
Reply to author
Forward
0 new messages