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:
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
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/daedd60d-ba9c-4911-b2dc-557996196851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
