pmloadcheck and pmpluginloadcheck are both commands and background daemons (run with the –i flag). When run as commands, they check, update, and report on the status of the policy server. You can use pmloadcheck from a policy server or PM Agent, and pmpluginloadcheck from a Sudo Plugin host.
When run as daemon processes, they keep track of the status of the policy servers for failover and load-balancing purposes. On policy servers, pmloadcheck is responsible for keeping the production policy file up to date and pmpluginloadcheck is responsible for keeping the production policy file up to date for the off-line policy cache.
|
NOTE: See pmloadcheck and pmpluginloadcheck for more information about the syntax and usage of these commands. |
The primary and secondary policy servers must be able to communicate with each other and the remote hosts must be able to communicate with the policy servers in the policy group.
For example, if you run the pmloadcheck command on a policy server or PM Agent to determine that it can communicate with other policy servers in the policy group; or, if you run pmpluginloadcheck on a Sudo Plugin host to determine that it can communicate with the policy servers in the group, you might get output similar to the following:
++ Checking host:myhost.example.com (10.10.181.87) ... [FAIL]
There are several possible reasons for failure:
These are some ways to verify that the Privilege Manager for Unix service is running properly on the policy server host:
# pmsrvinfo
# ps –ef | grep pmserviced
# netstat –na | grep 12345
pmmasterdEnabled YES
# /etc/init.d/pmserviced restart
-Or-
pmserviced -s
Privilege Manager for Unix might reject a sudo command. For example, let us assume you ran the following command:
$ /usr/local/bin/sudo id
and received output similar to the following:
<user> is not in the sudoers file. This incident will be reported.
Request rejected by Privilege Manager
There are several things you can do to troubleshoot this issue.
To troubleshoot why a sudo command is rejected
Run the following from the policy server:
# sudo –U <username> -l
# pmpolicy masterstatus
|
NOTE: In the output, ensure that Current Revision and Latest Trunk Revision have the same number and Locally modified is "No". |
# cat /etc/opt/quest/qpm4u/policy/sudoers
# pmsrvcheck
This command returns output similar to:
testing policy server [ Pass ]
From the command line, enter:
# pmsrvinfo
This command returns output similar to:
Policy Server Configuration:
----------------------------
Privilege Manager version : 6.0.0 (0nn)
Listening port for pmmasterd daemon : 12345
Comms failover method : random
Comms timeout(in seconds) : 10
Policy type in use : sudo
Group ownership of logs : pmlog
Group ownership of policy repository : pmpolicy
Policy server type : primary
Primary policy server for this group : Myhost1
Group name for this group : Myhost1.example.com
Location of the repository : file:
////var/opt/quest/qpm4u/.qpm4u/.repository/sudo_repos/trunk
Hosts in the group : Myhost1
Refer to Privilege Manager Programs for more information about the syntax and usage of the pmpolicy, pmsrvcheck, and pmsrvinfo commands.
If your sudo policy is not working as expected, use these troubleshooting steps:
# sudo –V
# pmplugininfo
# sudo –l –U <username>
This command returns output similar to:
Matching Defaults entries for testuser on this host: log_output User testuser may run the following commands on this host: (ALL) /opt/quest/bin/
# pmpolicy masterstatus
|
NOTE: Ensure that Locally modified in the output is "No". |
# pmpolicy sync
# pmpolicy checkout –d <dir>
# pmpolicyplugin
|
NOTE: Use the -g option to update the local cached security policy with the latest revision on the central repository (equivalent to pmpolicy sync on a server). |
Refer to Privilege Manager Programs for more information about the syntax and usage of the pmplugininfo, pmpolicy, and pmpolicyplugin, commands.
© 2021 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy