Why the copied file on client site will not be recovered from server?

[Wei Chen]

Hi,

I change the copied file on client site on purpose to see if this will be recovered by server. According to the document, the changed file on client will be recovered by server every half an hour. But this doesn't happen.

Why?

[jcbollinger]

On Thursday, October 8, 2015 at 1:34:39 AM UTC-5, Wei Chen wrote:

Hi,

I change the copied file on client site on purpose to see if this will be recovered by server. According to the document, the changed file on client will be recovered by server every half an hour. But this doesn't happen.

A file whose content is managed by Puppet will see that content restored to whatever is specified for it whenever Puppet performs a catalog run.  If the agent is running in daemon mode, then by default it will attempt to perform a catalog run every 30 minutes.

If you modify a file and the change is not reverted within 30 minutes, then there is a wide variety of possible explanations, among them:

• no catalog run has been performed.  This could be because
• the agent does not yet have a certificate the master will accept (most likely because its certificate has not yet been signed), or
  
• the agent is not running in daemon mode, and has not been run manually, or
  
• the agent is configured not to perform catalog runs at all, or to perform them only at intervals larger than 30 minutes, or
• catalog runs have been manually disabled, or
  
• the agent was unable to obtain its catalog from the master, and either does not have a cached one or is configured to not use cached catalogs. OR
  
• the affected file's content is not under Puppet management.  This could be because
• the file itself is not under management, or
• the file resource corresponding to the affected file specifies neither a source nor content, or
  
• the file resource's 'ensure' attribute is set to something other than 'file', or
• the file resource is configured with replace => false. OR
• the agent does not have sufficient privilege to modify the file.

There may be other possibilities.

Many of those alternatives could be identified either generally or specifically by examination of the appropriate system log file on the client, and for a few of them the master's logs might also be illuminating.  We could perhaps rule some of them out by examination of the resource declaration for the file in question.  It might also be useful to try running the agent manually ('puppet agent -t').

Overall, however, you have not yet given us nearly enough information to diagnose the problem.


John

[Wei Chen]

Hi John,

Thanks for your answer first.

I am new comer of puppet. I just wrote some simple code as follow:

The 'site.pp' on the server side:

import 'nodes.pp'

$puppetmaster = 's001ap38-test'

The 'init.pp' on the server side:

class httpd {

package { "httpd":

        ensure => present,

        }

file { "/etc/httpd/conf.d/s001is35-test.conf":

        owner => "root",

        group => "root",

        mode => 0666,

        source => "puppet:///modules/httpd/s001is35-test.conf",

        require => Package["httpd"],

        }

}

The 'nodes.pp' on the server side:

node 's001is35-test' {

include httpd

}

I ran the agent with following command:

puppet agent --server s001ap38-test --no-daemonize --verbose --onetime

The file 's001is35-test.conf' is coped from the server to agent. But since I used the option '--onetime', the agent is stopped after this. I think this is the reason why the copied file on the agent side, which I've changed it, is not recovered after 30 min.

Then I try to run the agent manually with 'puppet agent -t' as you told. But I got error as follow:

...

]# puppet agent -t

err: Could not retrieve catalog from remote server: getaddrinfo: Name or service not known

warning: Not using cache on failed catalog

err: Could not retrieve catalog; skipping run

err: Could not send report: getaddrinfo: Name or service not known

...

Then I simply run the agent with:

puppet agent

The agent is ran as a daemon.

But 30 min later, the file is not recovered yet.

Any suggestion?

Wei

[Rich Burroughs]

You are specifying the name of the Puppet master when you use --server but that's not how the agent will usually run. The error you're getting with the puppet agent -t indicates a problem communicating with the master. That's going to behave the same as when the agent runs every 30 minutes.

I would check to make sure that the agent has the correct master listed in its puppet.conf file, and also that you can resolve that master's name from the agent host.

There's a bit of additional troubleshooting info in this doc:

http://docs.puppetlabs.com/puppet/4.2/reference/quick_start_master_agent_communication.html


Rich

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/dbd18b91-3d8e-43e5-b22a-51250c5b9c52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wei Chen]

Hi John,

You are right.

Now I use the following command and it works.

puppet agent --server s001ap38-test -t

Many thanks!

Wei

[Rich Burroughs]

Hi Wei,

I wasn't suggesting you should always run it with that --server flag. What I was saying is that the fact that you have to do that to make it work means something is wrong.

Again, I would check on the agent host to see what server you have listed in its puppet.conf file. And then see if you can actually resolve that hostname from the agent node.

My guess is that you don't have that same server listed in the agent's puppet.conf that you're using when you run with --server. If that's true you should just fix it there.


Rich

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/03a64fb7-a3cd-4c88-8659-0723c04f0ac8%40googlegroups.com.

[Wei Chen]

Hi,

Here is my puppet.conf on the server side:

...

[master]

certname=s001ap38-test

...

The puppet.conf on the agent side is:

...

[master]

server=s001ap38-test

...

[jcbollinger]

The puppet agent does not use anything in the [master] section of the config file.  That section is for configuration specific to the master process -- that is, for the master to use, not to tell other components about the master.  The server setting should be in the [agent] section or maybe the [main] section, because it is for the agent to use.


John

[Wei Chen]

Hi John,

Now I moved the server-setting to the section of [agent]. And really I don't need typing the server option as follow:

puppet agent -t

But the agent can't be started as a daemon now, i.g. the agent can be kept running and is stopped.

Any suggestion?

Wei

[Wei Chen]

Sorry, there is a mistyping. It should be:

...

the agent can't be kept running and is stopped.

...

[jcbollinger]

This is not a normal consequence of having a 'server' setting in the agent's configuration.  I cannot be certain whether it is entirely coincidental, or whether there is some sort of bad interaction with another option or with your environment.

Does the agent emit any diagnostic (into the log, probably) when you attempt to start it as a daemon?  What options are you specifying to it, either on the command line or in the config file?


John

[Wei Chen]

Hi,

If I not using any option, but simply as follow, it works, i.g. the agent will kept running:

puppet agent

But I could remember, I ran 'puppet agent -t' before and it works. I am not sure if  I remember wrong?

What is the difference between these? Maybe the option '-t' is just for onetime?

[Wei Chen]

And here is the puppet.conf on agent side. I haven't changed it except moving the server definition to the [agent]:

]# cat puppet.conf

[main]

    # The Puppet log directory.

    # The default value is '$vardir/log'.

    logdir = /var/log/puppet

    # Where Puppet PID files are kept.

    # The default value is '$vardir/run'.

    rundir = /var/run/puppet

    # Where SSL certificates are kept.

    # The default value is '$confdir/ssl'.

    ssldir = $vardir/ssl

[agent]

    # The file in which puppetd stores a list of the classes

    # associated with the retrieved configuratiion.  Can be loaded in

    # the separate ``puppet`` executable using the ``--loadclasses``

    # option.

    # The default value is '$confdir/classes.txt'.

    classfile = $vardir/classes.txt

    # Where puppetd caches the local configuration.  An

    # extension indicating the cache format is added automatically.

    # The default value is '$confdir/localconfig'.

    localconfig = $vardir/localconfig

    server=s001ap38-test

[jcbollinger]

Yes, the '-t' option is shorthand for a collection of several others, one of which is '--onetime'.  It absolutely implies not running as a daemon.


John

[Wei Chen]

Many thanks for your patience and help!