Thanks - answers inline...
On Jun 29, 2011, at 8:57 AM, Daniel Piddock wrote:
> On 29/06/11 16:34, Craig White wrote:
>> This seems to work but it does seem perilous and ugly. A meta description of
>> what I am trying to do is:
>> - install firebird sql server
>> - replace the 'security' file with a known file
>> - restart the firebird service
>>
>> I'm not going to include firebird::install class because the part that
>> worries me is that I can't work on /var/lib/firebird/2.1/system/security.fdb
>> directly because we will want to maintain it locally after installation. I
>> only want a single shot deploy. So I am linking to /root/security.fdb and
>> then copying it from there to it's home. I suppose there is a much better
>> way to do this but I haven't found it.
>>
>> My worry is that I never actually overwrite
>> /var/lib/firebird/2.1/system/security.fdb after the initial
>> install/configure phase is completed.
>>
>> class firebird::configure {
>> file {"/root/security.fdb":
>> source => "puppet:///modules/firebird/security.fdb",
>> owner => root,
>> group => root,
>> mode => 640,
>> replace => false,
>> }
>> exec { "Copy KNOWN security.fdb into position":
>> path => "/usr/local/bin:/usr/local/sbin:/bin:/usr/bin",
>> environment => "HOME=/root",
>> command => "/bin/cp /root/security.fdb /var/lib/firebird/2.1/system",
>> user => "root",
>> group => "root",
>> logoutput => on_failure,
>> require => Class["firebird::install"],
>> }
>> }
>>
>> Is there a better way?
>
> Looking at this you'll be overwriting the security file every puppet
> run, rather than never at all. The first run *may* fail as the copy has
> no dependency on File['/root/security.fdb'].
----
it doesn't... I have checked, rechecked, cleaned up and rechecked
----
>
> Maintaining local configs on the servers is fighting the Puppet
> mentality. You'd be better off using an array of source files so that
> puppet will fall through the list until hitting a positive. Have a read
> through the Source part of
> http://docs.puppetlabs.com/references/stable/type.html#file
----
that page has become my bible ;-) after you get stung by 'unless', 'mode'
and various parameters that are accepted by 'file' but not 'exec' and vice
versa, this information is exceedingly valuable
----
>
> This class doesn't restart the sql server. Is that handled elsewhere?
----
yes, I clipped out the last section of firebird::configure class because it
wasn't useful to the question/discussion but the firebird service itself is
mostly unused because it runs via xinetd and so I had to create a
prerequisite::xinetd_install and prerequisite::xinetd_service class and
firebird ultimately notifies the prerequisite::xinetd_service class ;-)
Way afield from my question
----
> An example:
> class firebird::configure {
> file { '/var/lib/firebird/2.1/system/security.fdb':
> source => [ "puppet:///modules/firebird/custom/security.$host",
> 'puppet:///modules/firebird/security.fdb'],
> owner => root,
> group => root,
> mode => 640,
> require => Class['firebird::install'],
> # notify => Service['firebird'],
> }
> }
----
perhaps my head is cloudy from dealing with Phoenix desert summer but I don't
see how an array of choices for the source of this file isn't inherently more
dangerous than my effort thus far than to create 'one time' deploy.
As for 'Maintaining local configs on the servers is fighting the Puppet
mentality.' - I definitely understand and concur but I have a boss and this is
his overtly expressed desire. It makes total sense to me to just maintain one
file and use puppet to deploy this file to every database server so there is
complete alignment of users/passwords regardless of which database server but
until / unless he agrees, I have to work on plan B which is to try to do a
single deploy, forever unmanaged puppet script for this file.
Craig
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
