thr3ads.net - Puppet users - [Puppet Users] Deployed but unmanaged file [Jun 2011]

If this information is useful, please help other people find it:
Share via:

Craig White

2011-Jun-29 15:34 UTC

[Puppet Users] Deployed but unmanaged file

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?

-- 
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  craig.white@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com 

Need help communicating between generations at work to achieve your desired
success? Let us help!

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Daniel Piddock

2011-Jun-29 15:57 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

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''].

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

This class doesn''t restart the sql server. Is that handled elsewhere?

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''],
    }
}

HTH,
Dan

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Aaron Grewell

2011-Jun-29 16:00 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

I''d be tempted to write another file as well as part of the initial
config
(/var/lib/firebird/configured or something), then check for its
(non)existence before pushing the file out.

On Wed, Jun 29, 2011 at 8:34 AM, Craig White <craig.white@ttiltd.com>
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?
>
> --
> Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  craig.white@ttiltd.com
> 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com
>
> Need help communicating between generations at work to achieve your desired
> success? Let us help!
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Craig White

2011-Jun-29 16:03 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

That''s what I was thinking too but I worry that someone may feel
compelled to tidy things up     ;-)

I can see it now...

echo "Delete me and you will die" >
/root/firebird_security_file_deployed_do_not_delete

Craig

On Jun 29, 2011, at 9:00 AM, Aaron Grewell wrote:
> I''d be tempted to write another file as well as part of the
initial config (/var/lib/firebird/configured or something), then check for its
(non)existence before pushing the file out.
> 
> On Wed, Jun 29, 2011 at 8:34 AM, Craig White <craig.white@ttiltd.com>
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?
> 
> --
> Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  craig.white@ttiltd.com
> 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com
> 
> Need help communicating between generations at work to achieve your desired
success? Let us help!
> 
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
> 
> 
> -- 
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
-- 
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  craig.white@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com 

Need help communicating between generations at work to achieve your desired
success? Let us help!

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Nigel Kersten

2011-Jun-29 16:05 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

I''ve long wanted the equivalent of a "conffile" in Puppet.

e.g. "replace this file if it''s still the same as the one Puppet
put down,
but if it''s been modified from the default, don''t replace
it"

I''ve wanted this in the past for things like a user .rc file, where you
want
to be able to continually update the default, but not throw away any
customization the user may have done.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Brian Gallew

2011-Jun-29 16:14 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

On Jun 29, 2011, at 9:05 AM, Nigel Kersten wrote:
> I''ve long wanted the equivalent of a "conffile" in
Puppet.
> 
> e.g. "replace this file if it''s still the same as the one
Puppet put down, but if it''s been modified from the default,
don''t replace it"
> 
> I''ve wanted this in the past for things like a user .rc file,
where you want to be able to continually update the default, but not throw away
any customization the user may have done.
SInce I support developer who sometimes want to control the conf files, and
sometimes want Puppet to control them, I created a define:

define managed_file($source = undef, $content = undef) {
  $pdir = inline_template("<%=
name.reverse().split(''/'',2)[1].reverse() %>")
  $basename = inline_template("<%= name.split(''/'')[-1]
%>")
  
  file {
    "${name}-puppet":
      source => $source, content => $content, ensure => present;
    "${pdir}/README-${basename}":
      ensure => present,
      content => "${name} is managed by Puppet.\n\nIf you need to
edit\n${name}\nand have your changes persist, touch\n${name}.noupdate\nand
Puppet will ignore that file.  When you are done with your\ntesting, please have
your changes put in Puppet and delete the\n${name}.noupdate\nfile. 
Thanks.\n\n";
  }

  exec {
    "${name}-sync":
      unless => "test -f ${name}.noupdate || cmp -s ${name}
${name}-puppet",
      command => "/usr/local/bin/rsync -a ${name}-puppet ${name}",
      require => File["${name}-puppet"];
  }
}


And you use it like so:
managed_file {
  "${muledir}/lib/user/system-config.properties":
    content => template("jboss/system-config.properties.erb"),
    require => File["${muledir}/lib/user"],
    notify => Service["/site/mule"];
}

That will create three files in ${muledir}/lib/user:
README-system-config.properties, system-config.properties-puppet, and
system-config.properties.  If one of the developers on a managed system needs to
hand-edit that file, they red the instructions in the README-* and simply touch
system-config.properties.noupdate.  Removing that file re-enables Puppet
management.  As a further benefit, they can trivially see what''s going
to change when they remove the .noupdate file because the -puppet version will
always be Puppet-managed.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Aaron Grewell

2011-Jun-29 16:14 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

That would be sweet.  For system-level files I want to overwrite and keep a
known state, but at the user level I would love to be able to push a default
and then let them customize.  You can get something similar with concat by
including a local file with additions but since modifications to the core
file won''t be retained it''s not the same.

On Wed, Jun 29, 2011 at 9:05 AM, Nigel Kersten <nigel@puppetlabs.com>
wrote:
> I''ve long wanted the equivalent of a "conffile" in
Puppet.
>
> e.g. "replace this file if it''s still the same as the one
Puppet put down,
> but if it''s been modified from the default, don''t replace
it"
>
> I''ve wanted this in the past for things like a user .rc file,
where you
> want to be able to continually update the default, but not throw away any
> customization the user may have done.
>
>
>  --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Craig White

2011-Jun-29 16:25 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Craig White

2011-Jun-29 16:54 UTC

head link

Re: [Puppet Users] Deployed but unmanaged file

On Jun 29, 2011, at 9:14 AM, Brian Gallew wrote:
> On Jun 29, 2011, at 9:05 AM, Nigel Kersten wrote:
> 
>> I''ve long wanted the equivalent of a "conffile" in
Puppet.
>> 
>> e.g. "replace this file if it''s still the same as the one
Puppet put down, but if it''s been modified from the default,
don''t replace it"
>> 
>> I''ve wanted this in the past for things like a user .rc file,
where you want to be able to continually update the default, but not throw away
any customization the user may have done.
> 
> SInce I support developer who sometimes want to control the conf files, and
sometimes want Puppet to control them, I created a define:
> 
> define managed_file($source = undef, $content = undef) {
>  $pdir = inline_template("<%=
name.reverse().split(''/'',2)[1].reverse() %>")
>  $basename = inline_template("<%=
name.split(''/'')[-1] %>")
> 
>  file {
>    "${name}-puppet":
>      source => $source, content => $content, ensure => present;
>    "${pdir}/README-${basename}":
>      ensure => present,
>      content => "${name} is managed by Puppet.\n\nIf you need to
edit\n${name}\nand have your changes persist, touch\n${name}.noupdate\nand
Puppet will ignore that file.  When you are done with your\ntesting, please have
your changes put in Puppet and delete the\n${name}.noupdate\nfile. 
Thanks.\n\n";
>  }
> 
>  exec {
>    "${name}-sync":
>      unless => "test -f ${name}.noupdate || cmp -s ${name}
${name}-puppet",
>      command => "/usr/local/bin/rsync -a ${name}-puppet
${name}",
>      require => File["${name}-puppet"];
>  }
> }
> 
> 
> And you use it like so:
> managed_file {
>  "${muledir}/lib/user/system-config.properties":
>    content => template("jboss/system-config.properties.erb"),
>    require => File["${muledir}/lib/user"],
>    notify => Service["/site/mule"];
> }
> 
> That will create three files in ${muledir}/lib/user:
README-system-config.properties, system-config.properties-puppet, and
system-config.properties.  If one of the developers on a managed system needs to
hand-edit that file, they red the instructions in the README-* and simply touch
system-config.properties.noupdate.  Removing that file re-enables Puppet
management.  As a further benefit, they can trivially see what''s going
to change when they remove the .noupdate file because the -puppet version will
always be Puppet-managed.----
wow, this is a keeper for sure.

In my case, I have an encrypted binary file but I think you have given me the
idea for instructing puppet to keep hands off

Thanks

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Puppet users - Jun 2011 - Deployed but unmanaged file

[Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file

Re: [Puppet Users] Deployed but unmanaged file