FAQ
Despite no change in file (actually, template) content, with each catalog
run I get such log output as:

Aug 19 20:49:50 app-dev puppet-agent[30132]:
(/Stage[main]/Apache-httpd/File[/etc/httpd/conf/httpd.conf]/content)
content changed '{md5}b8a5c22154e45771bc09ef5c34
[root@chimps-dev puppet]# service puppet restart
                              │603e7f' to
'{md5}14699f9c769a61cbc6cc5e2c2a7465ff'

Which indicates that the file changed on the puppet master and so will be
updated on the agent.

This happens consistently and results in a service restart when the files
are config files like httpd.conf.

this is with puppet 2.6.18 on RHEL 6 (puppet master) and RHEL 5 (puppet
agent)

Here is my init.pp in my apache module. Note that I'm using templates only
(nothing in my files directory)

class apache-httpd {

   $moduleName = "apache-httpd"

   file { '/etc/httpd/conf/httpd.conf':
        owner => "root",
        group => "root",
        mode => 0644,
        ensure => 'file',
# source =>
'puppet:///modules/apache-httpd/etc/httpd/conf/httpd.conf',
        content => template('apache-httpd/etc/httpd/conf/httpd.conf.erb'),
   }

file { '/etc/httpd/conf.d/proxy_ajp.conf':
        owner => "root",
        group => "root",
        mode => 0644,
        ensure => 'file',
# source =>
'puppet:///modules/apache-httpd/etc/httpd/conf.d/proxy_ajp.conf',
        content =>
template('apache-httpd/etc/httpd/conf.d/proxy_ajp.conf.erb'),
   }

   file { '/etc/httpd/conf.d/ssl.conf':
        owner => "root",
        group => "root",
        mode => 0644,
        ensure => 'file',
## source =>
'puppet:///modules/apache-httpd/etc/httpd/conf.d/ssl.conf',
        content => template('apache-httpd/etc/httpd/conf.d/ssl.conf.erb'),
   }

}

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rahul Khengare at Aug 21, 2013 at 1:14 pm
    Hi Ed,
        Puppet execute their file resource only if contents of target file get
    changed at the before execution of puppet run.
    I checked your problem on RHEL-6.2 using puppet version 2.7.12, httpd.conf
    file not transferred each time if there is not change in the contents.
    You may have to check the contents of httpd.conf file before and running
    the puppet(use vimdiff command). There may possibility that httpd.conf file
    is edited by another service,

    Thanks and Regards,
    Rahul Khengare,
    NTT DATA OSS Center, Pune, India.

    On Tuesday, August 20, 2013 6:33:03 AM UTC+5:30, Ed Young wrote:


    Despite no change in file (actually, template) content, with each catalog
    run I get such log output as:

    Aug 19 20:49:50 app-dev puppet-agent[30132]:
    (/Stage[main]/Apache-httpd/File[/etc/httpd/conf/httpd.conf]/content)
    content changed '{md5}b8a5c22154e45771bc09ef5c34
    [root@chimps-dev puppet]# service puppet restart
    │603e7f' to
    '{md5}14699f9c769a61cbc6cc5e2c2a7465ff'

    Which indicates that the file changed on the puppet master and so will be
    updated on the agent.

    This happens consistently and results in a service restart when the files
    are config files like httpd.conf.

    this is with puppet 2.6.18 on RHEL 6 (puppet master) and RHEL 5 (puppet
    agent)

    Here is my init.pp in my apache module. Note that I'm using templates only
    (nothing in my files directory)

    class apache-httpd {

    $moduleName = "apache-httpd"

    file { '/etc/httpd/conf/httpd.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    # source =>
    'puppet:///modules/apache-httpd/etc/httpd/conf/httpd.conf',
    content => template('apache-httpd/etc/httpd/conf/httpd.conf.erb'),
    }

    file { '/etc/httpd/conf.d/proxy_ajp.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    # source =>
    'puppet:///modules/apache-httpd/etc/httpd/conf.d/proxy_ajp.conf',
    content =>
    template('apache-httpd/etc/httpd/conf.d/proxy_ajp.conf.erb'),
    }

    file { '/etc/httpd/conf.d/ssl.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    ## source =>
    'puppet:///modules/apache-httpd/etc/httpd/conf.d/ssl.conf',
    content => template('apache-httpd/etc/httpd/conf.d/ssl.conf.erb'),
    }

    }
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ed Young at Aug 22, 2013 at 3:53 pm
    Thanks for the response. There doesn't seem to be another process updating
    the files on before the puppet run. I believe the issue was the presence of
    a dynamic tag on the template file.

    The problem appears to be that the tag <%= @uptime_seconds %> was in some
    of the configuration files. When I removed that tag from the apache config
    files, and from the tomcat6 config files, there were no longer any updates
    due to file changes.

    The <%= @uptime_seconds %> appears to be set before execution of the puppet
    run, which I didn't expect, since tags such as <%= @fqdn %> resolve on the
    target agent node.

    Does this sound correct?
    if so, how do I know which tags or variables will be set before the puppet
    execution, and which are set on the agent side after the catalog run?


    On Wednesday, August 21, 2013 7:14:21 AM UTC-6, Rahul Khengare wrote:

    Hi Ed,
    Puppet execute their file resource only if contents of target file get
    changed at the before execution of puppet run.
    I checked your problem on RHEL-6.2 using puppet version 2.7.12, httpd.conf
    file not transferred each time if there is not change in the contents.
    You may have to check the contents of httpd.conf file before and running
    the puppet(use vimdiff command). There may possibility that httpd.conf file
    is edited by another service,

    Thanks and Regards,
    Rahul Khengare,
    NTT DATA OSS Center, Pune, India.

    On Tuesday, August 20, 2013 6:33:03 AM UTC+5:30, Ed Young wrote:


    Despite no change in file (actually, template) content, with each catalog
    run I get such log output as:

    Aug 19 20:49:50 app-dev puppet-agent[30132]:
    (/Stage[main]/Apache-httpd/File[/etc/httpd/conf/httpd.conf]/content)
    content changed '{md5}b8a5c22154e45771bc09ef5c34
    [root@chimps-dev puppet]# service puppet restart
    │603e7f' to
    '{md5}14699f9c769a61cbc6cc5e2c2a7465ff'

    Which indicates that the file changed on the puppet master and so will be
    updated on the agent.

    This happens consistently and results in a service restart when the files
    are config files like httpd.conf.

    this is with puppet 2.6.18 on RHEL 6 (puppet master) and RHEL 5 (puppet
    agent)

    Here is my init.pp in my apache module. Note that I'm using templates
    only (nothing in my files directory)

    class apache-httpd {

    $moduleName = "apache-httpd"

    file { '/etc/httpd/conf/httpd.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    # source =>
    'puppet:///modules/apache-httpd/etc/httpd/conf/httpd.conf',
    content => template('apache-httpd/etc/httpd/conf/httpd.conf.erb'),
    }

    file { '/etc/httpd/conf.d/proxy_ajp.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    # source =>
    'puppet:///modules/apache-httpd/etc/httpd/conf.d/proxy_ajp.conf',
    content =>
    template('apache-httpd/etc/httpd/conf.d/proxy_ajp.conf.erb'),
    }

    file { '/etc/httpd/conf.d/ssl.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    ## source =>
    'puppet:///modules/apache-httpd/etc/httpd/conf.d/ssl.conf',
    content => template('apache-httpd/etc/httpd/conf.d/ssl.conf.erb'),
    }

    }
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen Gran at Aug 22, 2013 at 4:02 pm

    On 22/08/13 16:39, Ed Young wrote:
    Thanks for the response. There doesn't seem to be another process
    updating the files on before the puppet run. I believe the issue was the
    presence of a dynamic tag on the template file.

    The problem appears to be that the tag <%= @uptime_seconds %> was in
    some of the configuration files. When I removed that tag from the apache
    config files, and from the tomcat6 config files, there were no longer
    any updates due to file changes.

    The <%= @uptime_seconds %> appears to be set before execution of the
    puppet run, which I didn't expect, since tags such as <%= @fqdn %>
    resolve on the target agent node.

    Does this sound correct?
    if so, how do I know which tags or variables will be set before the
    puppet execution, and which are set on the agent side after the catalog
    run?
    @uptime_seconds and @fqdn are both facts. Facts are supplied by the
    agent. In this case, uptime_seconds is how many seconds the node has
    been up. This will obviously change between runs. For a list of what
    facts are available, you can run `facter -p` on the node.

    Cheers,
    --
    Stephen Gran
    Senior Systems Integrator - theguardian.com
    Please consider the environment before printing this email.
    ------------------------------------------------------------------
    Visit theguardian.com

    On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad
    Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
    Visit subscribe.theguardian.com

    This e-mail and all attachments are confidential and may also
    be privileged. If you are not the named recipient, please notify
    the sender and delete the e-mail and all attachments immediately.
    Do not disclose the contents to another person. You may not use
    the information for any purpose, or store, or copy, it in any way.

    Guardian News & Media Limited is not liable for any computer
    viruses or other material transmitted with or as part of this
    e-mail. You should employ virus checking software.

    Guardian News & Media Limited

    A member of Guardian Media Group plc
    Registered Office
    PO Box 68164
    Kings Place
    90 York Way
    London
    N1P 2AP

    Registered in England Number 908396

    --------------------------------------------------------------------------

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ed Young at Aug 22, 2013 at 4:50 pm
    Regarding that fqdn and uptime_seconds are facts, that is understood.

    The agent node updating the file and triggered the content change may be
    obvious to you, but I'm a puppet beginner, and I yet don't have a solid
    understanding of the catalog run or how, when or where the tags get
    updated.

    1. I thought that the file on the agent node would never be updated unless
    the content on the puppet master changed which would trigger the catalog
    run and force the update.
    2. Instead, it appears that the agent node will trigger an update per it's
    runinterval, resolve the dynamic tags and if a fact needs updating, it will
    update the corresponding file and generate the content changed message I
    saw in the the agent node log.

    Is this close to correct?

    Meanwhile I'm going through ProPuppet and everything I can find on the
    puppetlabs site and hope to have a better understanding.


    On Thursday, August 22, 2013 10:00:38 AM UTC-6, Stephen Gran wrote:
    On 22/08/13 16:39, Ed Young wrote:
    Thanks for the response. There doesn't seem to be another process
    updating the files on before the puppet run. I believe the issue was the
    presence of a dynamic tag on the template file.

    The problem appears to be that the tag <%= @uptime_seconds %> was in
    some of the configuration files. When I removed that tag from the apache
    config files, and from the tomcat6 config files, there were no longer
    any updates due to file changes.

    The <%= @uptime_seconds %> appears to be set before execution of the
    puppet run, which I didn't expect, since tags such as <%= @fqdn %>
    resolve on the target agent node.

    Does this sound correct?
    if so, how do I know which tags or variables will be set before the
    puppet execution, and which are set on the agent side after the catalog
    run?
    @uptime_seconds and @fqdn are both facts. Facts are supplied by the
    agent. In this case, uptime_seconds is how many seconds the node has
    been up. This will obviously change between runs. For a list of what
    facts are available, you can run `facter -p` on the node.

    Cheers,
    --
    Stephen Gran
    Senior Systems Integrator - theguardian.com
    Please consider the environment before printing this email.
    ------------------------------------------------------------------
    Visit theguardian.com

    On your mobile, download the Guardian iPhone app theguardian.com/iphoneand our iPad edition
    theguardian.com/iPad
    Save up to 32% by subscribing to the Guardian and Observer - choose the
    papers you want and get full digital access.
    Visit subscribe.theguardian.com

    This e-mail and all attachments are confidential and may also
    be privileged. If you are not the named recipient, please notify
    the sender and delete the e-mail and all attachments immediately.
    Do not disclose the contents to another person. You may not use
    the information for any purpose, or store, or copy, it in any way.

    Guardian News & Media Limited is not liable for any computer
    viruses or other material transmitted with or as part of this
    e-mail. You should employ virus checking software.

    Guardian News & Media Limited

    A member of Guardian Media Group plc
    Registered Office
    PO Box 68164
    Kings Place
    90 York Way
    London
    N1P 2AP

    Registered in England Number 908396

    --------------------------------------------------------------------------
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen Gran at Aug 23, 2013 at 2:53 pm

    On 22/08/13 17:50, Ed Young wrote:
    Regarding that fqdn and uptime_seconds are facts, that is understood.

    The agent node updating the file and triggered the content change may be
    obvious to you, but I'm a puppet beginner, and I yet don't have a solid
    understanding of the catalog run or how, when or where the tags get
    updated.

    1. I thought that the file on the agent node would never be updated
    unless the content on the puppet master changed which would trigger the
    catalog run and force the update.
    2. Instead, it appears that the agent node will trigger an update per
    it's runinterval, resolve the dynamic tags and if a fact needs updating,
    it will update the corresponding file and generate the content changed
    message I saw in the the agent node log.

    Is this close to correct?

    Meanwhile I'm going through ProPuppet and everything I can find on the
    puppetlabs site and hope to have a better understanding.
    I think the glue that you're missing is that, while the template on the
    puppetmaster has not changed, the value of the variable in the template
    has changed.

    Variables in templates can come from many places in puppet. In this
    particular case, you (or someone) has used a fact. Facts values are
    filled in by the agent on the node at the start of a run, before
    catalogue compliation, so that they are available to the master for use
    in the catalogue.

    http://docs.puppetlabs.com/guides/custom_facts.html may be of some help
    to you.

    Cheers,
    --
    Stephen Gran
    Senior Systems Integrator - theguardian.com
    Please consider the environment before printing this email.
    ------------------------------------------------------------------
    Visit theguardian.com

    On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad
    Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
    Visit subscribe.theguardian.com

    This e-mail and all attachments are confidential and may also
    be privileged. If you are not the named recipient, please notify
    the sender and delete the e-mail and all attachments immediately.
    Do not disclose the contents to another person. You may not use
    the information for any purpose, or store, or copy, it in any way.

    Guardian News & Media Limited is not liable for any computer
    viruses or other material transmitted with or as part of this
    e-mail. You should employ virus checking software.

    Guardian News & Media Limited

    A member of Guardian Media Group plc
    Registered Office
    PO Box 68164
    Kings Place
    90 York Way
    London
    N1P 2AP

    Registered in England Number 908396

    --------------------------------------------------------------------------

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rahul Khengare at Aug 23, 2013 at 5:38 am
    Ed, It sound correct. The tag/facter value @uptime_seconds changes each
    time you run the puppet on agent machine.
    During the puppet catalog run, puppet first fetch the facter value and then
    apply the puppet manifests. So whatever the value of facter are set before
    the puppet manifests deployment.
    You can view facter values using 'facter -p'.

    You may look for tag concept it might help.
    http://projects.puppetlabs.com/projects/1/wiki/Using_Tags

    Thanks and Regards,
    Rahul Khengare,
    NTT DATA OSS Center, Pune, India.



    On Thu, Aug 22, 2013 at 9:09 PM, Ed Young wrote:

    Thanks for the response. There doesn't seem to be another process updating
    the files on before the puppet run. I believe the issue was the presence of
    a dynamic tag on the template file.

    The problem appears to be that the tag <%= @uptime_seconds %> was in some
    of the configuration files. When I removed that tag from the apache config
    files, and from the tomcat6 config files, there were no longer any updates
    due to file changes.

    The <%= @uptime_seconds %> appears to be set before execution of the
    puppet run, which I didn't expect, since tags such as <%= @fqdn %> resolve
    on the target agent node.

    Does this sound correct?
    if so, how do I know which tags or variables will be set before the puppet
    execution, and which are set on the agent side after the catalog run?



    On Wednesday, August 21, 2013 7:14:21 AM UTC-6, Rahul Khengare wrote:

    Hi Ed,
    Puppet execute their file resource only if contents of target file get
    changed at the before execution of puppet run.
    I checked your problem on RHEL-6.2 using puppet version 2.7.12,
    httpd.conf file not transferred each time if there is not change in the
    contents.
    You may have to check the contents of httpd.conf file before and running
    the puppet(use vimdiff command). There may possibility that httpd.conf file
    is edited by another service,

    Thanks and Regards,
    Rahul Khengare,
    NTT DATA OSS Center, Pune, India.

    On Tuesday, August 20, 2013 6:33:03 AM UTC+5:30, Ed Young wrote:


    Despite no change in file (actually, template) content, with each
    catalog run I get such log output as:

    Aug 19 20:49:50 app-dev puppet-agent[30132]: (/Stage[main]/Apache-httpd/
    **File[/etc/httpd/conf/httpd.**conf]/content) content changed '{md5}**
    b8a5c22154e45771bc09ef5c34
    [root@chimps-dev puppet]# service puppet restart
    │603e7f' to '{md5}**
    14699f9c769a61cbc6cc5e2c2a7465**ff'

    Which indicates that the file changed on the puppet master and so will
    be updated on the agent.

    This happens consistently and results in a service restart when the
    files are config files like httpd.conf.

    this is with puppet 2.6.18 on RHEL 6 (puppet master) and RHEL 5 (puppet
    agent)

    Here is my init.pp in my apache module. Note that I'm using templates
    only (nothing in my files directory)

    class apache-httpd {

    $moduleName = "apache-httpd"

    file { '/etc/httpd/conf/httpd.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    # source => 'puppet:///modules/apache-**
    httpd/etc/httpd/conf/httpd.**conf',
    content => template('apache-httpd/etc/**
    httpd/conf/httpd.conf.erb'),
    }

    file { '/etc/httpd/conf.d/proxy_ajp.**conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    # source => 'puppet:///modules/apache-**
    httpd/etc/httpd/conf.d/proxy_**ajp.conf',
    content => template('apache-httpd/etc/**
    httpd/conf.d/proxy_ajp.conf.**erb'),
    }

    file { '/etc/httpd/conf.d/ssl.conf':
    owner => "root",
    group => "root",
    mode => 0644,
    ensure => 'file',
    ## source => 'puppet:///modules/apache-**
    httpd/etc/httpd/conf.d/ssl.**conf',
    content => template('apache-httpd/etc/**
    httpd/conf.d/ssl.conf.erb'),
    }

    }
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Puppet Users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/puppet-users/Gly9jw9K3m8/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedAug 20, '13 at 5:07p
activeAug 23, '13 at 2:53p
posts7
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase