[ Pobierz całość w formacie PDF ]

past examples demonstrated, event scripts are basically op scripts that are
executed automatically in response to a system event. Many successful
event scripts can be written in that way, but this chapter introduces some
unique event script capabilities. These new capabilities allow event scripts
to act in ways that an automatically executed op script cannot, and that
provides new possibilities for event scripts.
In addition, this chapter discusses general event script specific topics that
relate both to true event scripts, which are enabled under event-options
event-script, and to automatically executed op scripts, which are
enabled under system scripts op. Topics that are specific to event scripts
enabled under event-options event-script have that restriction noted
within their section.
NOTE See Chapter 1 for the different storage/enable methods.
Executing Event Scripts
Event scripts are automatically executed by configuring them as an action
of an event policy:
event-options {
policy example {
events ui_commit;
then {
event-script example-script.slax;
}
}
event-script {
file example-script.slax;
}
}
More than one event-script can be executed by a single policy:
event-options {
policy example {
events ui_commit;
then {
event-script example-script.slax;
event-script example-script-2.slax;
}
}
event-script {
file example-script.slax;
file example-script-2.slax;
}
}
 Chapter 4: Event Script Capabilities 55
Event Script Output
Unlike op scripts, event scripts have no way to output text to the user
console. Op scripts are executed manually by users, within their user
session. This session has a corresponding console that the op script can
write text to. In contrast, event scripts are executed automatically by the
event processing daemon. They are not executed within a normal user
session, so there is no console available for event scripts to write to.
But, an alternate output method exists for event scripts. Event scripts can
be configured to write their output to a file, which is stored locally or
remotely, in the same way that the execute-commands event policy action
stores its output. The configuration used is also identical to the execute-
commands statement discussed in Chapter 3. The steps to write event script
output to a file are:
1. A destination is configured  pointing at either a local file directory or
a remote URL.
2. The destination is referenced under the event-script policy action
statement along with an output filename string.
As mentioned in Chapter 3, the actual filename is created by combining
the Junos device hostname with the configured filename string, the date
and time, and a unique index number, if necessary.
Here is an example of the event policy necessary to run the hello-world.
slax op script (shown in Day One: Applying Junos Operations Automation)
as an event script:
event-options {
policy hello-login {
events ui_login_event;
attributes-match {
ui_login_event.username matches "^jnpr$";
}
then {
event-script hello-world.slax {
output-filename hello-world-output;
destination local;
output-format xml;
}
}
}
destinations {
local {
archive-sites {
/var/tmp;
}
}
}
 56 Day One: Applying Junos Event Automation
event-script {
file hello-world.slax;
}
}
In this example, the hello-world.slax script is configured to execute
anytime the jnpr user logs into the Junos device. The script uses hello-
world-output as its output filename string and stores its output files in /
var/tmp. The selected output format is XML rather than text.
With a hostname of Junos, the actual output filenames stored in /var/
tmp might look similar to this:
Junos_hello-world-output_20090803_224719
The script itself is very basic: it outputs Hello World! Here is an exam-
ple of what the output file contents look like (white space has been added
for readability):
Hello World!
Output Format and Executing User
The format used for the event script output file is configured using the
output-format statement in the same way as the execute-commands
policy action, but the default format for event scripts is text rather than
xml. The user-name statement can be configured for the event script as
well, in which case the event daemon executes the script using the
specified user account rather than the default root user.
ALERT! The output-format and user-name statements can only be used with
event scripts that are enabled under system scripts op (see Chapter 1
for the different event script enabling methods). The statements do not
function correctly for event scripts enabled under event-options
event-script. In the latter case, the xml output-format is always used
whether the output-format statement is included or not, and the scripts
must be executed by the root user so the user-name statement should not
be used.
 Chapter 4: Event Script Capabilities 57
Event Script Arguments
Event scripts can receive arguments at execution time in a similar
manner as op scripts. Within the script itself, the arguments are specified
by defining parameters of the same name. For example, to receive an
argument named message the event script would declare the following
global parameter :
param $message;
With op scripts, administrators provide the arguments to the script by
entering them on the command-line, but event script arguments are
supplied from the event policy configuration itself. The event script can
include an arguments statement underneath the event-script statement
and specify multiple arguments:
event-options {
policy log-root-login {
events login_root;
then {
event-script log-message.slax {
arguments {
severity notice;
facility external;
message "Login by root";
}
}
}
}
event-script {
file log-message.slax;
}
}
In the example above, three separate arguments are provided to the
log-message.slax script when it executes. To use the arguments, the
log-message.slax script must have the following global parameters
declared:
param $severity;
param $facility;
param $message;
 58 Day One: Applying Junos Event Automation
Arguments may include event policy variables to pass event specific
information to the event script as well. Event scripts can use each of the
variables available for the execute-commands policy action :
n {$$.attribute} - This variable refers to an attribute of the trigger
event.
n {$event.attribute} - This variable refers to an attribute of the
most recent occurrence of the specified event ID.
n {$*.attribute} - This variable refers to an attribute of the most
recent correlating event from a within clause of the event policy.
NOTE Versions of Junos prior to 9.6 require the event ID within the event
policy variable to be capitalized. Starting with Junos 9.6, the event ID
can be configured in either upper or lower case. The attribute name
must always be configured in lower case.
TIP The {$event.attribute} and {$*.attribute} variables always select
the most recent occurrence of their particular events. When using an
attributes-match statement in the event policy, be aware that the
event that fulfilled the attributes-match might not be the most recent
correlating event.
BEST PRACTICE Do not use an event policy variable to refer to a correlating event that
is subject to an attributes-match for the event policy.
Here is an example of an event policy that passes event policy variables
to an event script through arguments. The goal of this event policy and
event script is to administratively disable all newly inserted interfaces
that do not already have the configuration applied. This is accom-
plished by passing the name of the newly active interface to the event
script, which first checks if any configuration is present for the inter-
face. If the interface is not configured then the event script adds a
disable statement under the interface and commits the change.
Here is the event policy to perform this action:
event-options {
policy set-admin-down {
events chassisd_ifdev_create_notice;
then {
event-script set-admin-down.slax {
arguments {
interface "{$$.interface-name}";
}
} [ Pobierz całość w formacie PDF ]