I am new to puppet and while going through puppet courses, I found one person using 'puppet agent -t' command to configure an agent node while in another course, the instructor using 'puppet apply' command.
What is the difference between these two commands?
These are:
puppet apply - applies or "executes" Puppet code on the local machine.
puppet agent -t also sometimes written puppet agent --test - calls the Puppet Agent to retrieve a catalog (compiled Puppet code) from a Puppet Master, and then applies it locally and immediately.
Note that -t is badly-named, and it may originally have been intended for "testing" but in fact it is not a "test" mode at all, but will make changes to your machine.
See also puppet agent --noop for the real "test" (dry-run) mode.
Related
I am using the following Puppet version on CentOS Linux release 7.2:
# puppetserver -v
puppetserver version: 2016.5.0.11
I have a Win agent node and i might have few more later. Agent version on Win node:
C:\Windows\system32>puppet --version
4.8.1
I would like to disable the agent runinterval permanently so i can only push from my Puppet server when required. I saw few links and tried putting the following line in Puppet server's /etc/puppetlabs/puppet/puppet.conf file. I also restarted the server but still the agent is fetching the catalog.
[agent]
daemonize=false
I would also like to know whether it's possible to disable runinterval only on specific nodes. If yes, how?
What you are basically looking at doing is stopping the Puppet service. This is accomplished most easily with a puppet service resource:
service { 'puppet':
ensure => stopped,
enable => false,
}
To do this only on certain nodes, merely supply it for the corresponding node definitions in your classifier or main site manifest:
node /ones_to_disable/ {
service { 'puppet':
ensure => stopped,
enable => false,
}
}
This is the easy and common method for accomplishing push-style Puppet and disabling pull-style.
If you want to disable Puppet agent on given node you have to use this command: puppet agent --disable. You can specify a reason, why you are disabling agent on given node. The message that you could supply will be printed next time someone will type puppet agent on node.
I am trying to keep puppet master and client/agent on one machine. I have been trying this for last 2 days and I am almost close to finishing it.
1) started puppet master "service puppetmaster start". Its successful
2) started puppet agent "service puppet start. Its successful
3) When I try puppet agent --test. see the errors below
This is the error I am getting when I try "puppet agent --test". I tried setting different values for environment in puppet.conf file and also passing from command line args for environment but nothing seems to be working.
Warning: Local environment: "production" doesn't match server
specified environment "none", restarting agent run with environment
"none"
I googled and tried what people said, but no use. It might work if I try agent from one machine and master on the other. But I want to make it work on one machine.
If you want to make it work on one machine you don't use puppet agent -t. you should use puppet apply. here is a reference
https://docs.puppet.com/puppet/latest/reference/man/apply.html
you can write a small script which will be having puppet apply command with farther argument (of course) and you can name it whatever you want (e.g: Papply) and run it every time whenever you want to run puppet agent -t.
puppet agent -t is not preferred for stand alone Puppet Server & Clint environment.
https://docs.puppet.com/puppet/4.6/reference/architecture.html
How can I check if my puppet set-up (one master, one agent on Ubuntu 14.04 ) is configured correctly? Is there some command to verify if everything is right?
If you want to know, whether the puppet agent can connect to the puppet master and pull the configs. You can try running the agent in dry-run mode:
puppet agent -t --noop
For more details: https://docs.puppet.com/puppet/latest/reference/man/agent.html
Note: You may need to sign the puppet agent cert on the master, if you don't have auto signing enabled.
We have several servers working with puppet as agents today, but I'm having a problem with a new server running CentOS 7. Normally I would update the /etc/sysconfig/puppet file with the puppet master name and then start the daemon and move to signing the certificate on the master. However, puppet agent doesn't appear to be reading the server = myhost.domain in my config file.
I get the following error in /var/log/messages:
puppet-agent[11133]: Could not request certificate: getaddrinfo: Name or service not known
I tried:
myserver:root$ puppet agent --configprint server
puppet
myserver:root$
but the /etc/sysconfig/puppet file has:
PUPPET_SERVER=myserver.domain.com
Can you please help me understand why puppet agent doesn't get the server from the config file?
The /etc/sysconfig/puppet file is not typically read by the Puppet agent. (I'm not very familiar with CentOS operations, but I suppose that this location might hold some settings that are external to the process, such as environment, command line switches etc.)
You will want to use the proper puppet configuration file:
/etc/puppet/puppet.conf for Puppet 3.x and earlier
/etc/puppetlabs/puppet.conf for Puppet 4.x
so ran the following:
"puppet agent --no-daemonize --verbose --onetime --server puppetmaster.xxx.com"
this started puppet properly, requested certificate and I was able to sign on master. Then added:
server = puppetmaster.xxx.com
to /etc/puppet/puppet.conf and "systemctl restart puppet"
and it worked. Thanks for posts here and other places.
I'm using puppet and want to test it with noop, but some configuration depends on the hostname like the node types.
How can I set the node name and run puppet with noop to check the node configuration that match the node name?, currently i got this as error message (my laptop is solaria):
Could not find default node or by name with 'solaria, solaria.lan' on node solaria.lan
Thanks.
puppetd --test --noop --fqdn="hostname.example.com"
Or with 2.6, this may be preferable:
puppet agent --test --noop--fqdn="hostname.example.com"
This will tend to create new certificates on the puppet master, so you'll probably need to run puppetca --clean hostname.example.com on the puppet master afterwords, otherwise when you finally get hosts with those names they'll be unable to set up an SSL relationship with the master.
I just figure out one possible solution, adding this to my config file
nodename = cert
certname = hostname