Very local site policy

We may send a rule-base file to a host, only to decide that we should not install it on that host. This is better than installing rules that can never work, or are not needed. Fewer rules exposed to attack yeilds less surface for attackers to exploit. Also, when the rule is not installed, the libexec recipe will not install any support scripts.

To understand this document

Bring your best shell scripting game. And you need to understand the markup used by mk. See the mk HTML document.

Rules based on a nodes attributes

Most op rules are pushed to a host from the master source based on attributes that msrc learns from hxmd. Sometimes the master source doesn't know enough to offer the rule to the host.

In that case the remote subdirectory offers the rule to the host, which selects or rejects that rule based on the return code from an mk marked shell command.

mk mark-up is employed to establish 'guards' for the op/remote managed op rules. If the guard exits 0, then the rule will be installed. If the guard exits with anything other than 0, the rule will not be installed.

The most primitive version would be to always install the file: 

# Always install this file
# $Guard: exit 0

Rules installed on a local criteria

By using an apropos marked line we can install op rules on each host that are useful there, but of no use on other hosts.

Here are a few examples: 

# Install on systems where /etc/vx is a directory
# $Guard: [ -d /etc/vx ]

# Install on systems where /proc is mounted
# $Guard: [ 2 -eq `stat -1 /proc | sed -n -e s"/Inode: *//"p` ]

# Install on the host nostromo only
# $Guard: expr _`hostname` : _'nostromo\..*' >/dev.null
It can be advantageous to associate an op rule-set with the existence of a particular login or group. For example, if you always want a certain set of op rules to appear everywhere that the oracle account does, you might propagate those rules to all your hosts, but only have them available on hosts where the oracle' user exists.

In this case we are looking for anther login and group: 

# Install on systems where "diag" is in /etc/passwd, and group sample exists:
# $Guard: egrep "^diag:" /etc/passwd >/dev/null && egrep "^sample:" /etc/group >/dev/null

Since the idea behind the op/remote method of op rule management is to have rules associated with a particular login or group; it is recommended to always use such a check in the mk Guard, along with any other guard conditions that you need.

Naming source rule files

For clarity, we usually name op rule files under the op/remote hierarchy is either user.cf or group.cf.

When the rule file contains m4 mark-up, add the .host suffix to force the master source system to m4 process the file. That allows the file's m4 mark-up to leveraged other msrc macros to pass an exit code back to the mk Guard directive.

Here's an example: 

include(class.m4)dnl
`# $Guard: exit 'dnl
ifelse(CLASS,square,`0',
ifelse(CLASS,hexagon,`0',
ifelse(CLASS,pentagon,`0',`1')))
`....
'dnl

In the above example, the return code from the ifelse markup is passed back to the exit in the mk Guard stanza. This can also be use in conjunction with the other user group checks, e.g.: 

include(class.m4)dnl
`# $Guard: egrep "^tfa:" /etc/passwd >/dev/null && exit 'dnl
ifelse(CLASS,square,`0',
ifelse(CLASS,hexagon,`0',
ifelse(CLASS,pentagon,`0',`1')))
`....
'dnl

The setup and cleanup of such rules

Two additional marked lines are honored when a rule-set is installed or de-installed. The Init marker executes when the rule is updated, the Cleanup marker is executed when the rule is removed. By removed we mean that it fails the Guard and was previously installed, not every time it fails the Guard.

There are default marked lines for these markers in the platform Makefile (that linked version is marked-up with m4 for msrc). The default marked lines are shell comments that exit 0, but don't take any action. 


$Id: remote.html,v 1.10 2013/05/18 21:42:06 ksb Exp $ by .