Re: [Puppet Users] Deployed but unmanaged file

Craig White
Wed, 29 Jun 2011 16:25:31 -0000

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