Backing up SUDO Controls configuration files

When making changes to any of the standard SUDO Controls configuration files on the SUDO master:

  • /etc/sudo_master/grants
  • /etc/sudo_master/alias
  • /etc/sudo_master/targets
  • /etc/sudo_master/fragments.d/*

Make a backup copy first in the designated directory:

[master]$ /etc/sudo_master/manage_sudo.sh --backup

INFO: *** start of manage_sudo.sh [--backup] ***
INFO: logging takes places in /var/log/manage_sudo.sh.log
INFO: runtime info: LOCAL_DIR is set to: /etc/sudo_master
INFO: ACTION: backing up the current configuration & fragments files ...
INFO: resulting backup file is: /etc/sudo_master/backup/backup_repo_20141217-1202.tar.gz
INFO: finished backing up the current configuration & fragments files
INFO: performing cleanup ...

Previewing a change in grants and alias mappings

Making a change to the SUDO Controls configuration can have a large impact in terms of granted access on the client landscape. You can preview the potential effect of your change by requesting a full dump of the configured name space or access rules.

You can do this on the SUDO master server or any client with:

[master]$ /etc/sudo_master/manage_sudo.sh --preview-global

The info presented will be 2-element tuples showing: WHICH rules go WHERE:

INFO: display GLOBAL configuration ....
root_netstat|host1
root_netstat|host2
root_netstat|host3
root_netstat|host4
<…>
root_lsof|host1
root_lsof|host2
<snip>

By simply ‘grepping’ on the output you can apply filters.

Resolving (expanding) aliases

When using nested groups (aliases) it may be difficult to track what the alias will finally expand to. Use the --resolve-alias command-line option to manually request alias resolution.

Example alias file:

@acme_hosts	: acme1.com,acme2.com,acme3.com,@acme_web
@acme_web	: acme5.come,acme7.com,@acme_db
@acme_db	: acme8.com,acme9.com

You can request manually resolution of @acme_hosts with:

[master]$ /etc/ssh_master/manage_ssh.sh --resolve-alias --alias=@acme_hosts

INFO: ACTION: resolving alias @acme_hosts ...
INFO: alias @acme_hosts resolves to: acme1.com acme2.com acme3.com acme5.come acme7.com acme8.com acme9.com
INFO: finished resolving alias

Or the @acme_db alias:

[master]$ /etc/ssh_master/manage_ssh.sh --resolve-alias --alias=@acme_db

INFO: alias @acme_db resolves to: acme8.com acme9.com
INFO: finished resolving alias
INFO: performing cleanup ...

Manually expanding aliases works on both master and client nodes.

Finding errors in --copy and --update operations

Since SUDO Controls will sync & update its clients in parallel via background jobs, it is not easy to always see a potential problem and correlate it to its correct host of origin.

Following command will siphon off the verbose output into a separate log file which can be used for inspection:

[master]$ /etc/sudo_master/manage_sudo.sh --copy 2>&1 | tee /tmp/copy.log

[master]$ /etc/sudo_master/manage_sudo.sh --apply 2>&1 | tee /tmp/apply.log

Then use following pattern to look for problems:

[master]$ grep -i -E -e 'WARN|ERROR|failed|denied|tty' /tmp/copy.log

[master]$ grep -i -E -e 'WARN|ERROR|failed|denied|tty' /tmp/apply.log

Fix any potential problems and clean up the temporary log file afterwards:

[master]$ rm –f /tmp/copy.log
[master]$ rm –f /tmp/apply.log

Alternatively you can also check the return code of the different sub-commands. Any return code different from 0 will be indicative of an error or errors:

[master]$ grep -E -e 'RC=[^0]' /tmp/copy.log

WARN: failed to transfer /etc/sudo_master/sudo_master/grants to client1:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer /etc/sudo_master/sudo_master/grants to client2:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer ./manage_sudo.sh to client1:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer ./manage_sudo.sh to client2:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer ./manage_sudo.conf to client1:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer ./manage_sudo.conf to client2:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer /var/tmp/distribute2host.14428/fragments to client1:/etc/sudo_controls/holding [RC=255]
WARN: failed to transfer /var/tmp/distribute2host.2601/fragments to client2:/etc/sudo_controls/holding [RC=255]
WARN: child process 31283 exited [RC=7]
WARN: child process 31223 exited [RC=7]

Following WARning(s) may be ignored:

Warning: Permanently added … (RSA) to the list of known hosts

Other messages that may ignored are the ones caused by the sudo tool itself (locally on each client):

Last successful login:       Mon Jan 19 08:50:15 MET 2015   
Last authentication failure: Mon Aug 25 23:18:02 METDST 2014 host1  
Last successful login:       Mon Jan 19 08:50:15 MET 2015   
Last authentication failure: Fri Sep  5 20:25:45 METDST 2014 host2

The following warning message indicates that the xauth utility is not installed on the client host:

X11 forwarding request failed on channel 0

Updated:

Comments