I know about
puppet agent --disable "my message" --verbose
but I would like to know at some point on a given machine, what is its puppet agent status. I don't see how to do it from
man puppet-agent
Is there an command that would tell me if the agent is enabled or disabled ?
Thank you.
-
------------------- EDIT
CentOS release 6.6 (Final)
bash-4.1$ puppet --version
3.7.4
bash-4.1$ file /usr/bin/puppet
/usr/bin/puppet: a /usr/bin/ruby script text executable
------------------- EDIT2
Whether it is enabled or disabled, I always get this:
[root#p1al25 ~]# cat `sudo puppet agent --configprint agent_catalog_run_lockfile`
cat: /var/lib/puppet/state/agent_catalog_run.lock: No such file or directory
[root#p1al25 ~]# puppet agent --disable "my message"
[root#p1al25 ~]# cat `sudo puppet agent --configprint agent_catalog_run_lockfile`
cat: /var/lib/puppet/state/agent_catalog_run.lock: No such file or directory
[root#p1al25 ~]# service puppet status
puppet (pid 4387) is running...
------------------- EDIT3
This one worked, thanks daxlerod
[root#p1al25 ~]# service puppet status
puppet (pid 4387) is running...
[root#p1al25 ~]# puppet agent --disable "my message" --verbose
Notice: Disabling Puppet.
[root#p1al25 ~]# cat `puppet agent --configprint agent_disabled_lockfile`
{"disabled_message":"reason not specified"}
A one-liner to get the current status is:
cat `puppet agent --configprint agent_disabled_lockfile`
Generally, this must be run as root, so I use:
sudo cat `sudo puppet agent --configprint agent_disabled_lockfile`
There are a number of possible results.
cat: \path\to\lock: No such file or directory Puppet is not disabled.
Any other text means that puppet is disabled, and the text is the reason provided when puppet was disabled by puppet agent --disable 'reason'
I thought I'd post here an updated answer.
If the Puppet agent is disabled, there will be a file $vardir/state/agent_disabled.lock. This file also contains the reasons of the disabling, if a reason has been given via puppet agent --disable 'because reasons'.
You can get the value of $vardir via the command puppet config print vardir.
To sum up:
[me#linuxbox ~]# cat $(puppet config print vardir)/state/agent_disabled.lock
If the agent is disabled, you get:
{"disabled_message":"because reasons"}
If the agent is enabled, you get an error "No such file or directory".
agent status is typically used in a master-slave setup.
More details are here:
https://docs.puppetlabs.com/learning/agent_master_basic.html
since there are two possible questions you could be asking. One being:
Is my service running?
to which the answer would be running your typical service command (for example service puppet status)
Or, is my agent fully able to run?
To which the answer would be to use the command
puppet agent --test
Mac OS X:
Status:
$ puppet resource service puppet
service { 'puppet':
ensure => 'stopped',
enable => 'false',
}
Note that if it's enabled, it will return:
service { 'puppet':
ensure => 'stopped',
enable => 'true',
}
Start:
sudo puppet resource service puppet ensure=running enable=true
Stop:
sudo puppet resource service puppet ensure=stopped enable=false
Bonus: There's a trick I like:
sudo --non-interactive. I use it in scripts for user that is sudoer. This will fail on computers that don't have sudoer instead of blocking execution of script.
Related
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.
I tried to execute shell script automatically when a user logins to a Puppet client node. I need to trigger puppet agent --test on a puppet client when a user logins to it.
I need to execute "puppet agent -t" command automatically when any user login to puppet client machine
That is going to be problematic, as puppet needs to run as root.
You can add
sudo puppet agent -t
to your /etc/profile , and also add
ALL ALL=(ALL) NOPASSWD: puppet
to your /etc/sudoers file.
But this is NOT something I would recommend.
Puppet Enterprise appeared to be installed on my ubuntu 14.04 server:
root#puppet:/# puppet --version
3.8.5 (Puppet Enterprise 3.8.4)
However, the puppet service is not running:
root#puppet:/# service puppet status
puppet: unrecognized service
The Puppet server seems to be working as well, as I can execute following command on the puppet master:
root#puppet:/# puppet resource package nginx
package { 'nginx':
ensure => '1.4.6-1ubuntu3.4',
Puppet cert list is empty as well even after running 'puppet agent -t' on a node:
root#puppet:/# puppet cert list
root#puppet:/#
The puppet service is called pe-puppet and not puppet on PE 3.x.
puppet cert list only displays the outstanding cert requests. You want puppet cert list --all to display the signed certs. https://docs.puppet.com/puppet/latest/reference/man/cert.html
service puppetmaster status
this will show the status of the puppet on the master machine
service puppet status
this will show the status on the slave/agent machine
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.