BlueCoat - Configuration and Management Guide - 5.x

Blue Coat Systems
Director
Configuration and Management Guide
SGME Version 5.2.x

Blue Coat Director Configuration and Management Guide
Contact Information
Blue Coat Systems Inc.
420 North Mary Ave
Sunnyvale, CA 94085-4121
http://www.bluecoat.com/support/contact.html
bcs.info@bluecoat.com
http://www.bluecoat.com
For concerns or feedback about the documentation: documentation@bluecoat.com
Copyright 1999-2007 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means
nor modified, decompiled, disassembled, published or distributed, in whole or in part, or translated to any electronic medium or other
means without the written consent of Blue Coat Systems, Inc. All right, title and interest in and to the Software and documentation are
and shall remain the exclusive property of Blue Coat Systems, Inc. and its licensors. ProxyAV, CacheOS, SGOS, SG, Spyware
Interceptor, Scope, RA Connector, RA Manager, Remote Access and MACH5 are trademarks of Blue Coat Systems, Inc. and
CacheFlow, Blue Coat, Accelerating The Internet, ProxySG, WinProxy, AccessNow, Ositis, Powering Internet Management,
The Ultimate Internet Sharing Solution, Cerberian, Permeo, Permeo Technologies, Inc., and the Cerberian and Permeo logos are
registered trademarks of Blue Coat Systems, Inc. All other trademarks contained in this document and in the Software are the property of
their respective owners.
BLUE COAT SYSTEMS, INC. DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED,
STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT
LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL BLUE COAT SYSTEMS, INC., ITS SUPPLIERS OR ITS LICENSORS BE LIABLE FOR
ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF BLUE COAT SYSTEMS,
INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Other copyrights apply. See the Appendix B.
Document Number: 231-02977

Document Revision: SGME 5.2.109/10/2007
Revision A.0
ii
Contents
Document Objectives.......................................................................................................................... 9
Audience .............................................................................................................................................. 9
Organization ........................................................................................................................................ 9
Document Conventions ................................................................................................................... 10
Related Documentation.................................................................................................................... 11
Chapter 1: Director Overview

About Director................................................................................................................................... 13
About the Benefits of Director ........................................................................................................ 14
Managing and Monitoring Blue Coat SG Appliances with Director ........................................ 14
Director Terminology....................................................................................................................... 14
About the Director Managment Console and CLI ....................................................................... 15
About the Director Dashboard........................................................................................................ 17
About the Content Sync Module .................................................................................................... 17
Chapter 2: Getting Started

Before You BeginSummary of Initial Tasks .............................................................................. 19
Section A: Performing Management Node Initial Setup
Section B: Connecting to the Director for the First Time
Connecting to Director with the Management Console.............................................................. 21
About the Director Management Console .................................................................................... 25
Configuring the Browser and Output Settings............................................................................. 27
Section C: Adding and Managing Devices
Adding a Device Manually.............................................................................................................. 29
Changing the Authentication Protocol .......................................................................................... 34
Chapter 3: Configuring and Managing Devices

Section A: Setting Up and Managing Device Groups
About the Groups Pane.................................................................................................................... 38
Adding a Group ................................................................................................................................ 38
Removing a Group............................................................................................................................ 39
Section B: Configuring and Managing Devices
Using the New Device Wizard ....................................................................................................... 40
Improving Authentication Security ............................................................................................... 41
Configuring a Device from Director .............................................................................................. 41
Section C: Managing Profiles
About Secure Profiles ....................................................................................................................... 43
iii
Creating a Profile .............................................................................................................................. 43

Applying a Profile ............................................................................................................................ 46
Refreshing or Deleting Profiles....................................................................................................... 47
Section D: Managing Director Overlays
Applying an Overlay Immediately ................................................................................................ 53
Refreshing and Deleting Overlays ................................................................................................. 53
Section E: Managing Substitution Variables
About Substitution Variables.......................................................................................................... 54
Creating and Implementing Substitution Variables.................................................................... 54
Creating the Variables in the Overlay..................................................................................... 55
Defining the Configuration Value and Changing a Device Configuration....................... 59
Section F: Authenticating Director using Appliance Certificates
Overview ..................................................................................................................................... 62
About Director Appliance Certificates.................................................................................... 62
Obtaining an Appliance CertificateInternet Connection.................................................. 62
Obtaining an Appliance CertificateNo Internet Connection ........................................... 63
Section G: Automatically Registering SG Appliances with Director
Overview............................................................................................................................................ 68
About the Registration Process ................................................................................................ 68
Workflow Methods .................................................................................................................... 68
Registering SG Appliances without Pre-Staged Device Records .............................................. 69
Configuring Director to Accept Registered SG Appliances................................................. 70
Registering the SG Appliance with Director.......................................................................... 71
Setting Passwords for Newly Registered Devices on Director ........................................... 73
Configuring New Device Records on Director...................................................................... 74
Registering SG Appliances with Pre-Staged Device Records .................................................... 75
Configuring Director to Accept Registered SG Appliances
(Pre-Staged) .......................................................................................................................... 77
Creating a Partial Device Record on Director........................................................................ 77
Registering the SG Appliance with Director (Pre-Staged)................................................... 78
Configuring the New Device Record (pre-staged)................................................................ 78
Section H: Managing Backups
Topics in this Section ................................................................................................................. 79
Creating a Backup ...................................................................................................................... 80
Pinning a Backup ....................................................................................................................... 82
Unpinning a Backup .................................................................................................................. 83
Restoring a Backup .................................................................................................................... 83
Deleting a Backup ...................................................................................................................... 84
Comparing Two Backups ......................................................................................................... 84
iv
Contents
Managing Backups through the CLI ....................................................................................... 85
Chapter 4: Configuring Jobs

Performing Tasks in the Jobs Tab................................................................................................... 87
Setting Up and Managing Jobs ....................................................................................................... 88
Creating and Scheduling Jobs......................................................................................................... 88
About Job Actions............................................................................................................................. 93
Executing a Job Immediately .......................................................................................................... 94
Verifying Job Execution ................................................................................................................... 94
Verifying Backup Jobs ............................................................................................................... 96
Editing Jobs........................................................................................................................................ 96
Deleting Jobs...................................................................................................................................... 96
Customizing the Job Queue View .................................................................................................. 97
Related CLI Syntax for Working with Jobs ............................................................................ 97
Remotely Upgrading SG Appliance Software.............................................................................. 98
Upgrade and Validation Notes....................................................................................................... 98
Creating a Job to Upgrade SG Appliance Software..................................................................... 98
Chapter 5: Distributing Content

About Content Distribution .......................................................................................................... 103
Distributing URL Lists ................................................................................................................... 104
Validating URLs or Regular Expressions.................................................................................... 108
Prioritizing URLs and Regular Expression Jobs ........................................................................ 109
Querying URLs ............................................................................................................................... 110
Chapter 6: Monitoring Devices

About the Monitoring Tab............................................................................................................. 115
Viewing Group and Device Status............................................................................................... 116
Viewing Alerts ................................................................................................................................ 118
Managing Alerts....................................................................................................................... 118
Viewing Statistics............................................................................................................................ 121
Chapter 7: Monitoring Administrator Activity

About Administrator Activity Logging ...................................................................................... 123
Configuring Administrator Activity Logging ............................................................................ 124
Enabling TACACS+ Authentication ..................................................................................... 124
Setting the Logging Level ....................................................................................................... 124
Configuring Syslog .................................................................................................................. 124
Viewing the log ............................................................................................................................... 125
Audit Logging Details.................................................................................................................... 125
Profile/Overlay/Backup Logging......................................................................................... 125
Job Logging ............................................................................................................................... 126
v
Chapter 8: Monitoring the Health of Devices

About Health Monitoring.............................................................................................................. 130
SG Appliance Health Monitoring Requirements....................................................................... 130
About the Health Monitoring Metrics ......................................................................................... 131
About Device Polling ..................................................................................................................... 131
Health Monitoring Example ......................................................................................................... 132
About the Health Monitoring Device States............................................................................... 133
About the General Metrics...................................................................................................... 134
About the Licensing Metrics................................................................................................... 135
About the Status Metrics......................................................................................................... 135
About Health Monitoring Notification ....................................................................................... 136
Viewing a Devices Health Monitoring Metrics......................................................................... 137
Changing Threshold and Notification Properties ..................................................................... 138
Getting A Quick View of the SG Appliance Health .................................................................. 140
Viewing Health Monitoring Statistics ......................................................................................... 141
Configuring Director to Notify Remote Management Stations of SG Appliance State Changes
143
Verifying SNMP Trap Receipt................................................................................................ 145
Troubleshooting.............................................................................................................................. 145
Chapter 9: Configuring Director Redundancy

Section A: Requirements and Terminology
Requirements................................................................................................................................... 148
Terminology .................................................................................................................................... 148
About the Standby Pair State ................................................................................................. 150
Section B: Detailed Standby Concepts
Failover Assumptions .................................................................................................................... 152
How Data is Mirrored.................................................................................................................... 152
Monitoring Connectivity ............................................................................................................... 153
How Failover Works ...................................................................................................................... 153
Section C: Implementation Details
Configuring the Standby Pair ....................................................................................................... 156
Viewing the State of the Primary or Secondary Director.......................................................... 158
Making Changes on the Primary Director ........................................................................... 159
Connecting to a Non-Active Director ................................................................................... 159
Section D: Scenario: Implementing a Director Standby Pair
Example Companys Disaster Preparedness .............................................................................. 160
Example Procedure: Configuring the Standby Pair .................................................................. 160
Moving the Directors ..................................................................................................................... 162
Moving the Secondary Director ............................................................................................. 162
Taking the Primary Director Offline ..................................................................................... 162
vi
Contents
Network Link Failure..................................................................................................................... 163

Dealing with Network Outages ............................................................................................. 163
Primary Director Failure................................................................................................................ 165
Dealing with the Loss of the Primary ................................................................................... 165
Upgrading the Software on the Standby Pair............................................................................. 166
Software Upgrade the Easy Way: Break the Standby Pair................................................. 166
Software Upgrade Without Downtime................................................................................. 167
Section E: SNMP Notifications for Director Standby
Notifications Sent Only by the Primary Director ................................................................ 169
Notifications Sent Only by the Secondary Director ............................................................ 170
Notifications Sent by the Primary or Secondary Director.................................................. 170
Notifications Caused by Administrator Action................................................................... 171
Chapter 10: Director Logging

Log Message Terminology ............................................................................................................ 173
Components of Director ................................................................................................................ 174
About the Syslog............................................................................................................................. 175
Syslog Log Levels..................................................................................................................... 175
Navigating through the Syslogs ............................................................................................ 176
Syslog Messages.............................................................................................................................. 176
CLI Informational and Error Messages ................................................................................ 190
Appendix A: Administering Director

Changing Director Defaults .......................................................................................................... 199
Setting Up Users ............................................................................................................................. 200
Creating Local User Accounts................................................................................................ 200
Managing Users Who Manage Content ...................................................................................... 201
Authenticating Users...................................................................................................................... 204
Configuring RADIUS .............................................................................................................. 205
Configuring TACACS+ ........................................................................................................... 208
Determining the Connection Protocol ......................................................................................... 209
SSH ............................................................................................................................................. 209
Managing Security Through Access Lists................................................................................... 211
Using Telnet and FTP Servers....................................................................................................... 212
Using the SNMP Server ................................................................................................................. 213
Rebooting Director ......................................................................................................................... 213
Shutting Down Director ................................................................................................................ 214
Upgrading Director ........................................................................................................................ 214
Director 800 and 510 Upgrade Differences........................................................................... 215
Upgrading Software on the Director 510.............................................................................. 217
Upgrading a Director 800........................................................................................................ 219
vii
Upgrade Changes..................................................................................................................... 220

Destroying Old Configuration Files After an Upgrade...................................................... 221
Downgrading to an Earlier Version of Director......................................................................... 221
Restoring the Configuration Files.......................................................................................... 222
Notes .......................................................................................................................................... 223
Managing Director Configuration ............................................................................................... 223
Saving the Director Management Node Configuration ..................................................... 223
Switching the Active Director Configuration ...................................................................... 224
Switching Director Configuration Between Management Nodes .................................... 224
Deleting Configuration Files .................................................................................................. 224
Archiving and Restoring the Entire Director Configuration ................................................... 225
Before You Begin ...................................................................................................................... 225
Procedure Overview................................................................................................................ 226
Creating a Encryption Keypair .............................................................................................. 226
Creating the Archive................................................................................................................ 227
Uploading the Archive File .................................................................................................... 227
Retrieving and restoring the Archive.................................................................................... 228
Appendix B: Third Party Copyright Notices
Index
viii
Preface
This preface describes who should read the Blue Coat Director Configuration and
Management Guide, how it is organized, and its document conventions.
This preface contains the following sections:
Document Objectives on page 9
Organization on page 9
Audience on page 9
Document Conventions on page 10
Related Documentation on page 11
Document Objectives
This configuration and management guide describes how to use the Blue Coat
Director software for setting up, monitoring, and managing all aspects of
networks that use Blue Coat SG appliances.
Audience
This guide is intended for network administrators and managers.
Organization
This document contains the following chapters.
Table 11 Document Organization
Chapter Title Description
Chapter 1 Director Overview Provides Director terminology and

introductory material.
Chapter 2 Getting Started Provides how to connect to Director for

the first time.
Chapter 3 Configuring and Describes how to create and manage

Managing Devices devices, profiles, and overlays.
Chapter 4 Configuring Jobs Describes how to configure Director to

execute various tasks at specified times.
Chapter 5 Distributing Describes how to use Director to create

Content and distribute URL lists and regular
expression lists to Blue Coat devices.
Chapter 6 Monitoring Devices Describes how to use Director to monitor

the health and other status metrics of
Blue Coat devices.
9
Table 11 Document Organization
Chapter Title Description
Chapter 7 Monitoring Describes how to monitor tasks invoked

Administrative by Director administrators.
Activity
Chapter 8 Monitoring the Describes how to use Director to monitor

Health of Devices the health and other status metrics of
Blue Coat devices.
Chapter 9 Configuring Describes how to configure Director

Director devices to be backups should another
Redundancy Director go down.
Chapter 10 Director Logging Provides the codes used in Director

logging.
Appendix A Administering Describes how to perform

Director administration tasks Director using CLI
commands.
Document Conventions
The documentation uses the following conventions:
Convention Description
bold sans seriff type Words used on the user interface.
italicized type Book titles

Variables
New terms
monospaced type File and directory names

Commands and code examples
Text you must enter in an application
Square brackets, as in [value] Optional command parameters
Curly braces, as in {value} Required command parameters
Logical OR, as in value1|value2 Exclusive command parameters where only one

of the options can be specified
10
Related Documentation
The following table shows other Director documentation available from Blue
Coat:
Table 12 Documentation available from Blue Coat
Document name Description
Quick Start Guide Shipped with your Blue Coat Director; describes how
to install the Director hardware and configure access
information.
Blue Coat Systems Director Provides installation information with more details
Installation Guide than the Quick Start Guide.
Blue Coat Systems Director Describes all of the available Director CLI commands.
Command Line Interface
Reference
Blue Coat Director Dashboard

Users Guide
Blue Coat Director Content Sync

Module Guide
Online documentation Provided with the Blue Coat RA Manager to give you
context-sensitive help as well as access to this book.
Release Notes Provides late-breaking news; updates to the product;

and known issues. The most recent Release Notes are
on the Blue Coat Web site
(http://download.bluecoat.com/release/
RA).
11
12
This chapter provides an overview of Director. It discusses benefits,

terminology, the Director Management Console, and the CLI.
Topics include:
About Director on page 13
About the Benefits of Director on page 14
Managing and Monitoring Blue Coat SG Appliances with Director on
page 14
Director Terminology on page 14
About the Director Managment Console and CLI on page 15
About the Director Dashboard on page 17
"About the Content Sync Module" on page 17
About Director
Blue Coat Director centrally manages and monitors all aspects of networks
that use Blue Coat SG appliances. Administrators can use Director to set user
and content policy, manage SG appliance configurations, distribute and control
all types of Web content, upgrade and validate SGOS software, and back up SG
appliances.
Director automates configuration and policy management to one or more SG
appliances from a single point of administration. It manages everything from
SG appliance configuration to policy and license distribution.
Key configuration management features include:
Configure groups of SG appliances based on locations, applications, or
more.
Rapidly deploy standardized configurations using profiles.
Manage the scheduling of policy and configuration changes.
Easily schedule incremental changes to one or more SG appliances.
Create and distribute policy across a system of SG appliances.
Automatically back up configuration snapshots.
Back up SG appliance backup files.
Compare backup files from different SG appliances and restore
configuration backups to multiple SG appliances.
Quickly monitor SG appliance status, statistics, and configurations.
Upgrade all SG appliances at once.
13
About the Benefits of Director

Director provides the following benefits:
Reduces management costs by centrally managing all SG appliances.
Delegates network and content control to multiple administrators.
Eliminates the need to configure each remote SG appliance manually.
Ensures consistency when updating multiple, identical SG appliances.
Recovers from system problems with automated configuration snapshots and
recovery.
You can access Director through either the Director Management Console or the
command line interface (CLI).
Managing and Monitoring Blue Coat SG Appliances with Director

Blue Coat Director centrally manages and monitors all aspects of networks that
use Blue Coat SG appliances. Administrators can use Director to set user and
content policy, manage SG appliance configurations, distribute and control all
types of Web content, upgrade and validate SGOS software, and back up SG
appliances.
Director Terminology
The following special Director terminology is used in this manual:
SGME (Security Gateway Management Edition): The name given to Directors
software.
Device: A synonym for the SG appliance.
Director (or Blue Coat Director): The product as a whole, encompassing the
hardware and software and all the features.
Director CLI: The command line interface for the SGME operating system.
SG CLI: The command line interface for the SGOS operating system.
Director image file: The file containing the Director SGME software.
Director Management Console: The Director user interface.
Director management node: The Director hardware.
Profile: A configuration operation on Director that creates a snapshot of all
configuration and policy from a source device.
Overlay: A configuration operation on Director that is used to replace selected
configurations or policy on one or more SG appliances.
Job: An Director action that is scheduled.
SG appliance: A purpose-built appliance to provide visibility and control of
Web communications and to enable granular policy enforcement to the
individual user. This is a device that can be managed by Director.
14
SG record: Management information stored in Director that corresponds to a

specific SG appliance. Deleting an SG appliance record from Director does not
affect the physical SG appliance.
SG group: A number of SG appliance records that have been put into a group.
SG appliances are usually added to a group when they have similar
constraints, such as location or content requirements.
About the Director Managment Console and CLI

The Director Management Console or the CLI can be used to manage SG
appliances. The Director Management Console provides a graphical view, making
it easier to learn Director. However, the Director Management Console is not used
for initial setup of the Director management node.
The Director CLI is used primarily for initial setup of the Director management
node. After Director is set up, you can rely primarily on the Director Management
Console. Table 11 lists the features and actions that can be done in each interface.
Table 11 Availability of Features in the Director CLI and Management Console
Feature Management CLI

Console
Initial Setup and Managing System Software
Director Software Installation, Upgrade, and No Yes

Downgrade
Global IP Configuration No Yes
Network Interface Configuration No Yes
Time Management No Yes
LCD Pane Management No Yes
SSH Server No Yes
FTP and Telnet Servers No Yes
SNMP No Yes
Director management node No Yes
User Accounts No Yes
Workgroups No Yes
Authentication No Yes
Event Logging No Yes
Director Standby No Yes
Director CLI State Management No Yes
Archiving Configuration and Backups No Yes
15
Table 11 Availability of Features in the Director CLI and Management Console (Continued)
Feature Management CLI

Console
Device Health Monitoring Yes Yes

Configuration Management
Initial setup of Directory HierarchyManagement Yes Yes

Node, Groups, and SG appliances
Configuration Management for Multiple SG appliances Yes Yes
Comparison between two Profiles or two Overlays No Yes
Overlay Creation Yes Yes
Configuration File Backups Yes Yes
Job Management Yes Yes
Job Querying Yes Yes
Job Summary Yes Yes

Content Management
Content Management Yes Yes
Job Management Yes Yes
Job Querying Yes Yes
Using the Management Console (GUI)

The Management Console is Directors graphical user interface, running on
Windows. The Management Console administers multiple Director domains as
well as the SG appliances associated with those domains.
To communicate with SG appliances and the Director management node(s), the
Director Management Console must know the hostname or IP address of the
management node. (You can have more than one management node on the
Management Console.) The Director Management Console communicates with
the management node through SSHv2 /RSA, SSHv2 Simple.
Using the Director CLI

The Director command line interface (CLI) provides a text-based way to set up
Director, its associated SG appliances, and its users. It also provides a way to
automate content jobs and policy. Access the CLI through SSH. (A third-party
SSH client is required.)
To Start a Director CLI Session:

Use SSH to communicate with Director. SSHv2 is the default.
Note: If you have not previously enabled Telnet through the serial console during
hardware installation of the Director management node, Telnet is not available.
16
ssh -2 -l username Director_IP_address

Copyright (c) 1997-2007, Blue Coat Systems, Inc.
Welcome to SGME 5.2.0.0
Director >
Three command modes are used in the CLI: Standard, Enable, and Configuration.
Standard mode appears when you first log in. This mode allows you to
monitor Director without making changes.
Enable mode, accessed by entering enable and the password if one is required
at the prompt, allows you to issue commands to an SG appliance that are
invoked only if they do not permanently affect the Director configuration.
Configuration mode, accessed by entering configuration terminal (or just
config t) at the prompt after you are in Enable mode, allows you to make
permanent changes to the Director configuration, including SG devices,
policies, and job schedules.
Commands listed in Standard mode are also available in Enable and
Configuration modes. Most commands provided in Enable mode are also
available in Configuration mode.
In some command sets, you can enter a submode that allows you to issue
commands without retyping the command set prefix in every command. For
example, enter the workgroup ID_name command set, and all commands you later
enter are applicable only to the specified workgroup.
Note: For information about using the Director CLI to set up Director
management nodes, see Appendix A: "Administering Director" on page 199. For
full command arguments and syntax, refer to the <Emphasis>Blue Coat Director
Command Line Interface Reference.
About the Director Dashboard

The Director Dashboard is a network-monitoring interface specifically designed
for use with Director. The Dashboard subsystem is provided for evaluation
purposes and is offered only as trial software.
Using Dashboard, you can easily obtain aggregated information and statistics for
all groups and devices monitored by Director. Dashboard enables you to gather
real-time system metrics and information without authenticating to Director. All
Dashboard views are read-only.
About the Content Sync Module

The Content Sync Module (CSM) operates by crawling a Web server or file system
and tracking the time that the content was last modified, and then changing the
content in the SG appliances accordingly.
Note: The Content Sync Module does not ship with Director. It is available
separately.
17
The CSM supports:

Scheduled generation of URL lists and upload of URL lists.
Generated URL lists reflecting changes in content, either on request or
automatically, and upload the lists on request.
Issuing of content commands to Director.
Enabling of automatic content updates. CSM can watch where internal
content owners (such as HR or engineering) publish content and then tell
Director to update the SG appliances.
The CSM is discussed in more detail in the Blue Coat Director Content Sync Module
manual.
18
Chapter 2: Getting Started
This purpose of this chapter is to help you understand what the steps are to
install, configure, and start Director. This chapter contains a summary of initial
tasks and a general overview of common tasks. Detailed instructions and
conceptual information are discussed in other chapters.
This chapter discusses the following topics:
"Before You BeginSummary of Initial Tasks" on page 19.
"Section A: Performing Management Node Initial Setup"on page 20.
"Section B: Connecting to the Director for the First Time"on page 21.
"Section C: Adding and Managing Devices"on page 29.
Before You BeginSummary of Initial Tasks

This section summarizes the basic tasks for installing, setting up and
configuring your Director. It directs you to sections, chapters or other guides
that describe these tasks in detail.
1. Unpack and rack your Directorsee the Blue Coat Director Installation Guide,
Chapter 2.
2. Initially configure the Director softwaresee the Blue Coat Director
Installation Guide, Chapter 3 and "Section A: Performing Management Node
Initial Setup"on page 20.
3. Install the Management Console (GUI software)see Blue Coat Director
Installation Guide, Chapter 4 and "Using the Director CLI" on page 16.
4. Launch Director for the first timesee Blue Coat Director Installation Guide,
Chapter 4 and "Section B: Connecting to the Director for the First Time"on
page 21.
5. Configure a Devicesee Chapter 3: "Configuring and Managing Devices"
on page 37.
6. Configure a Jobsee Chapter 4: "Configuring Jobs" on page 87.
7. Create a Content Listsee Chapter 5: "Distributing Content" on page 103
8. Backup up Directorsee "Managing Director Configuration" on page 223.
19
Section A: Performing Management Node Initial Setup

The CLI is used primarily for initial setup of the management node. After you
complete the initial configuration of the system, you should rarely need to use
the CLI again.
Set up by default are:
User account: admin
Authentication method: local
Connection protocol (connection between Director and the SG appliance):
SSHv2 Simple
Authentication Port: 8082 (HTTP is not supported between Director and the
device)
FTP, SNMP and Telnet: disabled by default.
Other activities that can be accomplished only through the CLI include:
Upgrading or downgrading the Director management node
Archiving and Restoring the entire Director configuration
Creating and Managing Workgroups (applies to content management
operations only)
For information on changing the defaults or configuring advanced options on
the Director management node, see Appendix A: "Administering Director".
You must also use the CLI to set up and manage message logs. For more
information on logging, see Chapter 10: "Director Logging".
20
Section B: Connecting to the Director for the First Time
Before you begin, you must have the Director software installed on both the
Director management node and on the system where you are going to manage
Director. Refer to the Blue Coat Director Installation Guide for information on
downloading and installing the software.
Also, review the settings on the management node (see Section A: "Performing
Management Node Initial Setup" on page 20) to ensure that the Director version is
compatible with the version of SGOS you are using.
Note: If you had SGME 4.x installed on your system, you have two instances of
the Director user interface installed. You can use SGME 4.x to connect to 4.x
Directors and SGME 5.x connect to 5.x Directors.
Connecting to Director with the Management Console

To connect to the Director management node from the Management Console, you
must use the same connection protocol and authentication method you specified
when you first installed the Director management node (SSH v2 Simple is the
default). You cannot change connection protocols unless both the Director and the
device are aware of the new method.
To connect to the Director for the first time:

1. Click the Director icon you placed on your desktop during installation. The
Manage Directors dialog displays.
21
2a
2b
2c
2d
2. Set the Director Properties:

a. Director Name: Enter a name designated for this Director device. For
example, a location name.
b. Description (Optional): Enter a description. For example, the SG
appliance model number or more detailed location information (2nd
floor lab).
c. IP Address: Enter the IP address of the Director management node.
d. Enable password: If the Director node already has an enable password,
enter the same password here. The password must match the enable
password already set on the Director management node because the
Director Management Console connects to the Director management
node using this information. If you do not have an enable password on
the Director management node, you cannot add one through the
Director Management Console.
22
3a
3b
3c
3. In the Authentication Details section, select the authentication method you

selected during the initial configuration of the Director management node:
a. SSH Simple. If the Director management node is using SSH-Simple,
enter the username and password that you use to connect to Director.
b. SSH-RSA. If the Director management node is using SSH-RSA:
Note: By default Director connects through SSH Simple. Before you can
use SSH-RSA, you must be connected to Director with SSH simple. To use
Telnet to connect, you must first configure it using the CLI.
RSA username: Enter the name uses to connect to the Director

management node.
Identify file location: Enter the full path to the private identity file that
was generated when the ssh-keygen utility created a keypair. You can
then enter a username password to decrypt and use the identity file.
4. (Optional) Select Connect to director to make the connection after the dialog is
closed. If this option is not selected, you can connect manually from the main
Director screen.
5. Click OK.
If you selected Connect to director, the Director Management Console connects to
the Director appliance; after the successful connection, the appliance appears in
the Manage Director dialog.
23
Figure 21 Connecting to the Director appliance.
Figure 22 A successful connection.
Notes
To manage this Directors settings at a later time or to add other Directors to
this Management Console, select File > Manage Directors.
Each time you connect to Director after first-time configuration, the Login:
Director Management Console dialog displays. You must enter the required
password information to connect to Director.
24
Figure 23 The Director login dialog.
About the Director Management Console

After connecting to the Director management node, the Director Management
Console displays.
25
Figure 24 The Director Management Console

Configuration options are categorized according to task and presented in four
tabs.
About the Monitor Tab

The Monitor tab contains a summary of the current health status and alerts for
devices managed by Director. The upper area contains two metrics:
The Current Device Status indicators show how many devices are currently
connected to Director and cummulative representative health states.
The Accumulated Alerts indicators show how many total alerts are currently
detected Director. These alerts might not represent the current health state of
the device.
To view the current status of a device, highlight the device in the Devices pane.
For more information about the Monitor tab, see "Chapter 6: Monitoring
Devices".
26
About the Configure Tab
The Configure tab allows you to create and manage groups and devices. After you
have added devices to Director, you can edit the devices (by right-clicking the
device and selecting Edit) or place them in groups. After devices are added, you
can then create profiles and overlays to manage the configuration on your
devices.
The Backup Manager can be launched for each specific device, allowing you to
create and manage the backups done for each device.
For more information about the tasks available on the Configure tab, see Section
C: "Adding and Managing Devices" on page 29.
About the Jobs Tab

The Jobs tab allows you to take jobs, such as applying or refreshing overlays or
profiles, doing backups, or rebooting a device, and put them into one-time or
recurring jobs. You can save a one-time job for re-use at a later date.
You can create one-time or recurring jobs for individual SG appliances, multiple
appliances, or groups of appliances.
For more information about the tasks available on the Jobs tab, see "Performing
Tasks in the Jobs Tab" on page 87.
About the Content Tab

The Content tab allows you to identify locally-stored content lists (URLs and
regular expressions) and pre-populate SG appliances with content (push content
to the cache) so users have quicker access and consume fewer network resources.
You can push the content immediately or schedule a job.
For more information about the tasks available on the Content tab, see Chapter 5:
"Distributing Content" on page 103.
Configuring the Browser and Output Settings

Some operations require Director to display a new Web browser (for example, the
Dashboard). The options in this section instruct Director which browser to use
and allow you to specify output settings, which dictate the output level for
profiles and overlays:
To configure the browser and output settings:

1. From the Management Console, click File > Options.
27
2. Specify the broswer file: In the Path To Browser field, enter the path to the
broswer executable file; if you do not know the path, click Browse and
navigate to the location of the file.
3. Specify browser output settings. The combinations of selecting/clearing
Enable verbose output and entering a kilobyte limit provides the following
functionality:
If Enable verbose mode is seleted and the output limit is set to a small
value, such as 10Kb, then:
Profile and overlay output is shown in its entirety.
Archive configuration output is truncated at the value in the Limit output
to: field.
If Enable verbose mode is not selected (the default), and the output limit is
set to a small value, such as 10Kb, then:
Profile and overlay output displays errors only.
Archive configuration output is truncated at the value in the Limit output
to: field.
If Enable verbose mode is not selected and the output limit is set to a large
value, all output is limited to errors only.
4. Click OK.
Notes
The default output limit is 5120 KBytes; the maximum is 1 GB. The limit is
reset to its default if you click Use Defaults.
Backup-restore output is always errors only, no matter the setting of the
verbose mode.
28
Section C: Adding and Managing Devices

To view the configuration options, select the Configure tab. If devices are
already configured on this management node, highlight the All Special Group
to view them.
The Configure tab allows you to:
Add multiple devices
Edit the devices to set the communication protocol to SSH RSA
Create Profiles and Overlays and apply them to selected devices
Create and Manage Groups
Manage Backups
Creating and managing groups and backups is discussed later in this manual.
Adding a Device Manually

Use the New Device Wizard to add devices using either of the following
methods:
Importing a device identification file
A device identification file is a text file that contains a comma-separated list
(CSV format) of the data required to identify new devices. The New Device
Wizard includes a sample device identification file that you can use as a
template.
Manually entering the required data
Note: Because the device identification file is in CSV format, you must enter data
for all fields, and in the correct order. Otherwise, the add device operation will
fail.
To add a device, you must input the following data into the New Device Wizard:
Device name
Device ID
IP Address
Web Port
Authentication Port
Username
Password
Enable Mode Password
To import device data using a device identification file, see the following
procedure. To add devices manually, see "To manually add devices:" on page
31.
29
To add a device by importing a device identification file:

1. Add the required device data to a text file using the correct, comma-separated
format.
2. Click Add Device(s) at the bottom left of the Configuration pane.
3. Read the information that displays on the New Device Wizard and click Next.
The Import window displays.
4a: To view a sample of the

device identification file, click
this link.
Sample appears.
4b
4c
4d
4. Select the import options:

a. (Optional) To view a sample device identification file, click the Click
Here link.
b. Select Yes. Import the appliance file at this location.
c. Enter the path to the device identification file or click Browse to locate
the file.
d. Click Next. The imported appliance data is displayed in the Summary
window.
30
5. Click Finish to return to the Configure pane. The added devices are under the
All or Unassigned to Group categories in the Group pane. After you have
configured groups and reassigned the devices, the devices will no longer be in
the Unassigned to Group category.
To manually add devices:

1. Click Add Device(s) at the bottom left of the Configuration pane.
2. Read the information that displays on the New Device Wizard and click Next.
The New Devices window displays.
31
3. Enter attributes:
a. Device Name: Place the cursor in the Device Name field and give the
device a name thats meaningful to you.
b. Device ID: This unique alphanumeric string is used by the CLI for
indexing purposes.
Important: After it is set here, it can never be changed.
c. IP Address: Add the IP address of the device being added.

d. Web Port: The default for SG appliances is 8082. You can change it if
you use a different port.
e. Authentication Port: The default for SSH is 22.
f. Username: This is the username you use for the SG appliance.
g. Password: This is the password you use for the SG appliance.
Note: A red frame around a cell in the New Devices table indicates that
the data is invalid.
32
4. Continue to enter attributes:
a. Enable Mode Password: This is the password you created on the SG
appliance to enter enable mode through the CLI.
b. Serial Console Password: This is the password you use to access the SG
appliance through a connected PC.
c. Front Panel Pin: This is the number you use to access the SG appliance
LCD front panel display, which contains basic network configuration
options.
d. Serial No: The hardware serial number of the SG appliance
e. Registration State: Select the current SG appliance state.
Configured: The SG appliance is registered and is configured to meet
enterprise goals.
Registered: The SG appliance is registered, but has not been configured to
meet enterprise goals (only the defaults apply).
Not Registered: The SG appliance cannot be administratively controlled by
Director.
5. (Optional) Click Add Row to enter information for another device.
6. Click Next. The imported appliance data is displayed in the Summary window.
33
7. Click Finish to return to the Configure pane. The added devices are under the
All or Unassigned to Group categories in the Group pane. After you have
configured groups and reassigned the devices, the devices no longer appear in
the Unassigned to Group category.
Changing the Authentication Protocol

After a device has been added to Director, you should configure the system to use
SSH/RSA to communicate with Director and with other systems. This is
important later when you want to have a fully-authenticated profile (used for
managing multiple devices.)
Two kinds of profiles can be used:
Simple profile, which means that the SG appliance is authenticated through
SSH Simple. This method does not pull secure data like passwords and some
security related configurations like keyrings might not be included in a Profile
pulled from a device using a SSH-Simple connection; because of this, backups
of the device cannot be complete. Blue Coat strongly recommends using SSH/
RSA when creating profiles.
Secure profile, which means the SG appliance is fully authenticated through
SSH-RSA. This method pulls secure data like passwords and security-related
configuration such as keyrings, so the profile is complete; when applied, the
profile reproduces all of the state of the SG it was pulled from.
Blue Coat strongly recommends that you fully authenticate the SG appliance
through SSH-RSA.
34
To fully authenticate the SG appliance:
1. Highlight the device you want to authenticate. You must be connected to the
device whose authentication you want to change.
2. Select Edit Appliances, using the right mouse button. The Edit Device dialog
displays.
3. Select the SSH-RSA radio button.

In the RSA Username field, the name director automatically displays. This is
the director is the only username allowed for SSH RSA authentication.
4. To generate an RSA key, click Change Key at the bottom of the screen.
35
5a
5b
5. You can have Director create a new SSH RSA keypair, or you can use a keypair
from another device that is currently connected to Director.
Peform one of the following:
a. To generate a new keypair, verify that the Generate a new keypair radio
button is selected.
b. To re-use a keypair, select the Use a keypair from another device radio
button and enter the unique alphanumeric string that is the devices
appliance ID.
6. Click OK.
7. Click Push key to device. This step is required for the device you are editing to
receive the new or re-used key.
8. Click OK.
9. Verify the change by seeing if SSH RSA is listed for the device under Device
Properties in the Properties pane.
36
This chapter discusses how to set up and configure device groups, devices,
profiles and overlays. It also discusses how to automatically add SG appliances to
Director and manage backups. Topics include:
Section A: "Setting Up and Managing Device Groups" on page 38
Section B: "Configuring and Managing Devices" on page 40
Section C: "Managing Profiles" on page 43
Section D: "Managing Director Overlays" on page 50
Section E: "Managing Substitution Variables" on page 54
Section F: "Authenticating Director using Appliance Certificates" on page 62
Section G: "Automatically Registering SG Appliances with Director" on page
68
Section H: "Managing Backups" on page 79
37

If you have a number of SG appliances that have similar constraints, such as
configuration, location, or content requirements, you can create a group and add
the devices to the group. This makes it easy to distribute profiles or overlays
(which can contain multiple SGOS or Director changes) to multiple devices
simultaneously.
Note: Only 500 devices can be viewed in the Director Management Console at
one time, even if the devices are associated with different Director management
nodes.
About the Groups Pane

When devices are added to Director, they are placed in the All System Group.
Until they are assigned to a Custom Group, they are also placed in the Unassigned
System Group.
You can create as many groups as required, and groups can be nested within other
groups. When a device is assigned to a Custom group, it is removed from the
Unassigned System Group, but not from the All System Group.
Devices are added to groups by selecting the device from the All or Unassigned
System Groups and dragging and dropping the device into the Custom group
you want.
A device can be added only once to any group, but it can be added once to each
nested group; that is, if a top-level group called TechPubs includes three nested
groups called Sunnyvale, Waterloo, and Austin, device A can be placed in each of
the nested groups as well as in the top-level group.
You can create groups before you add devices, or you can add devices first. The
two are independent of one another.
Adding a Group
This section describes how to add a group to Director.
To add a group:
1. Verify that the Configure tab is selected.
2. In the Group area, select Custom Groups.
3. Click Add Group at the bottom of the area.
38
4a
4b
4. Enter Group information:

a. Group Name: Enter a name meaningful to you.
b. (Optional) Description: Enter a description to help you remember this
groups purpose.
c. Click OK.
5. To create an additional group, you have two choices:
a. Top-Level Group. Repeat the steps 1 through 4 to create a new top-
level group.
b. Nested Group. Highlight the group you just created, and right click to
add a group that will be subordinate to the top-level group.
6. After the groups are created, drag and drop the devices into the desired
groups. You can add a device to multiple groups, but you cannot add the
device twice to the same group.
Removing a Group
To remove a group, right click the group name and select Delete. If you remove a
group, all devices are moved to the Unassigned group; they are not deleted.
You can move a nested group to a different top-level group by dragging and
dropping, and you can change a nested group to a top-level group by dragging it
to the Custom Groups area.
39

You can use the New Device Wizard to add devices to Director. After the
devices are connected, you can improve security by changing the connection to
SSHv2/RSA. You can also add devices to groups you created previously.
Using the New Device Wizard

The New Device Wizard is used only to add one or more devices to Director. The
connection information (username, password, protocol) required in the wizard
must already exist on the device. You cannot change the existing information
here.
The top-level steps for adding a device to Director are:
1. Launch the New Device Wizard by clicking Add Device(s) in the lower left-
hand corner of the Configure panes.
2. Read the introductory information about what the wizard does and click
Next.
Note: You can also add devices to Director by importing a text file that
contains comma-separated device data into the Wizard.
3. Place the cursor in the Device Name field to begin adding the device
connection information. Fill in each field with the information that already
exists on the SG appliance.
4. Click Add Row to add another device.
For detailed instructions on using the New Device Wizard, see Section C:
"Adding and Managing Devices" on page 29.
After you have added the device to Director and placed it in the Unassigned
system group, you can move it (by dragging and dropping) into any already
existing Custom group.
Related CLI Syntax to Add Devices

You can add devices through the CLI, but the New Device Wizard allows you
to add multiple devices at one time. Also, the CLI requires a unique Device ID
string before it adds a device to the system. Blue Coat recommends using the
Director Management Console to add devices to Director.
Details for all CLI commands can be found in Volume 11: Command Line Interface
Reference, of the <Emphasis>Blue Coat Configuration and Management Guide
Documentation Suite.
director (config) # device unique_string
This changes the prompt to
director (config device "unique_string") #
Commands available from this submode include:
40
director (config device "unique_string") # address

director (config device "unique_string") # auth
director (config device "unique_string") # authtype
director (config device "unique_string") # comment
director (config device "unique_string") # create
director (config device "unique_string") # enable-password
director (config device "unique_string") # exit
director (config device "unique_string") # help
director (config device "unique_string") # name
director (config device "unique_string") # no
director (config device "unique_string") # protocol
director (config device "unique_string") # pushkey
director (config device "unique_string") # list
director (config device "unique_string") # reconnect
director (config device "unique_string") # shell
director (config device "unique_string") # show
director (config device "unique_string") # web-config
Improving Authentication Security

Although Director can communicate with devices using SSHv2/Simple, a much
more secure option is to use SSHv2/RSA. This is particularly important if you
want to use Director to manage the configuration of the added devices.
You can change the communication protocol to SSH/RSA only after you have
added the device to Director.
Note: Director must be connected to the device before the communication

protocol can be changed.
The top-level steps for changing the communication protocol are:

1. Verify the device whose protocol you want to change is connected to Director.
2. Right-click the device.
3. Select Edit.
4. Select the SSH/RSA radio button.
5. Generate an RSA key.
Director immediately attempts to connect to the device using SSH/RSA.
For detailed instructions on improving authentication security, see "Changing the
Authentication Protocol" on page 34.
Configuring a Device from Director

You can use Director as a quick alternative to the SG appliance Web console,
allowing you to make configuration changes to one SG or several SG appliances
(sequentially, not simultaneously).
All the commands executed in the Manage Device area refer to the SG appliance.
You cannot use Directors content or configuration management commands in the
Manage Device window.
41
If you change the version of the SG appliance due to an upgrade or downgrade,

re-connect to the SG before attempting any subsequent operations with Director.
You must also close the Manage Device window and restart it.
You can change the SG username through Director, but you must reconnect to the
SG using the new credentials.
You can also use the Overlay tab to create configuration settings that can then be
applied to multiple devices.
To configure a device from Director:

1. Verify that you are in the Configure tab.
2. Highlight the device you want to configure.
3. Click Configure Device at the bottom of the area.
4. When the device Web console displays, navigate to the tabs on which you
want to make changes. Always click Apply before leaving the tab, or the
changes are not committed.
5. Click the X in the upper right-hand corner to exit the Manage Device pane.
42

A profile is a set of configuration commands pulled from an existing SG
appliance, saved in Director, and then applied to one or more SG appliances.
Profiles work in conjunction with overlays (including substitution variables),
and refreshables (filters) to standardize the SG configuration. Profiles created
from fully-authenticated (SSH-RSA) SG appliances are called secure profiles
and are used to manage multiple devices. The profile summary has a statement
that the profile Includes security credentials.
When you apply a profile, Director first issues a restore-defaults keep-
console command that allows you to restore default settings without losing all
IP addresses on the system. If you just want to change a few settings on a SG,
use an overlay.
About Secure Profiles

A secure profile is a profile created on Director using the SSH-RSA connection
mode. This profile includes the SSL keys created with the show-director or
show attributes.
Note: If a non-secure profile created through an SSH-Simple connection is later

applied to an SG appliance using the SSH-RSA connection, SSL keys with the
show-director attribute are lost but the keys with show attribute are overwritten.
For information on creating SSL keys with the show-director attribute, refer to the
Proxy and Proxy Services volume in the Blue Coat SG Configuration and
Management Suite.
Creating a Profile
Before you begin, highlight the source device that you want to use to create a
profile. The source device must:
Be the same platform as the device or devices to which you plan to apply
the profile.
Include all the settings that you want to apply to other devices.
Not include customized settings that are specific to an individual device,
including:
Bridging settings
Failover
Virtual IP addresses
SSH
Note: If the source device contains default settings for the above options, the
profile can be applied to other devices. If the source device contains
customized settings, the profile might result in the target device losing
connection to Director.
43
Be authenticated with SSH/RSA. See "Changing the Authentication Protocol" on

page 34 for more information.
When you apply a profile, Director first issues a restore-defaults keep-console
command that allows you to restore default settings without losing all IP
addresses on the system. If you just want to change a few settings on an SG
appliance, use an overlay.
The profile does not contain the IP address or other information specific to the SG
appliance. You can edit a profile, but it is not recommended. Only add commands
that match the operating system version of the SG appliance where the profile is
applied. Commands that are not understood by the operating system version fail.
Note: All services, including those with assigned IP addresses, are included in a
newly-created profile. If you push a profile that includes those services to
multiple SG appliances, access to those services fails because the services contain
the IP address of the device the profile was pulled from.
When you create a profile, any command beginning with the following string is
not included in the pulled profile:
ip-default-gateway
dns: (Director manually maintains the DNS settings)

hostname
interface (the entire submode)

line-vty (the entire submode)
The following advanced-config related items are also stripped from profiles.
accelerated-pac path or inline accelerated-pac
security authentication-form path or inline authentication-forms
bypass-list local-path or inline bypass-list
ICP path
license-key path
policy local-path
rip path
socks-gateways path
static-routes path
WCCP path
All licenses are stripped from profiles.
44
To Create a Profile
1. Select the Configure tab.
2. Highlight the source device to use to appy settings to other devices.
3. In the Configuration Library area, select the Profile tab.
4. In the lower right corner, click New.
5a
5b
5c
5. Configure profile options:

a. In the Profile Name field, enter the name of the profile. (The Profile ID
field uses the same string.)
b. (Optional) In the Description field, enter a description of the profile.
c. You can pull the information from the reference device you
highlighted, select a different device by clicking the browse (. . .) drop-
down list, or pull the information from a URL where the information
has been stored.
d. Click OK. The profile displays in the Configuration Library area.
45
Figure 3-1. The new profile displays.
Applying a Profile
You can distribute a profile either immediately or later, as part of a job.
Before the profile is distributed, effectively wiping out an SG appliance
configuration, a backup of the existing configuration on that SG appliance is
taken. (If the profile causes problems, you can recover the backup of the previous
configuration. For more information on backups, see Section H: "Managing
Backups" on page 79.) The profile, minus certain network settings, such as IP
address and hostname, is applied to the specified SG appliance or group.
When a profile is executed, the following procedure occurs:
The restore-defaults command is sent over the configured protocol.
If there are free backup slots, a backup is taken.
After reconnecting, the profile is applied to the SG appliance.
To apply a profile:
1. Highlight the profile you want to apply.
2. Highlight the device you want to receive the profile.
3. In the lower right corner, click Apply.
4. Click Yes to apply the profile.
46
Note: When a profile is applied to a device, a backup of the device

configuration is done. Then the current configuration is overwritten by the
profile.
Before a profile is applied, Director checks the destination SG appliance to see if

any licenses are associated with the given device(s). Any licenses assigned to the
SG appliance are applied to the SG appliance when the profile runs.
Related CLI Syntax to Execute a Profile

Director (config) remote-config
Director (config remote-config) profile profile_ID
Director (config remote-config profile profile_ID) # execute device
device_ID errors-only
If, during the profile output, you see the message Invalid input detected at '^'
marker, it could be invalid for several reasons: the target SG appliance does not
have a given feature enabled, such as streaming; a feature requires a license (such
as RealMedia streaming) or the profile was taken from an SG appliance with a
different version number.
Refreshing or Deleting Profiles

You can refresh or delete individual profiles. If you are using the configuration of
a specific device as the template for your profile, use the refresh feature to update
the profile when the device configuration changes.
To refresh or delete a profile:

1. Highlight a profile in the Configuration > Shortcuts > Profile pane.
2. Right click the profile and select Refresh or Delete. A confirmation box
displays with a prompt to continue.
3. Click Yes to continue.
Related CLI Syntax to Delete a Profile

Director (config) # no remote-config profile profile_id
Comparing Two Profiles

You can compare two profiles from the same SG appliance or profiles from two
different SG appliances through the CLI.
From the (config) prompt:
Director (config) # remote-config diff {unified | context} profiles
first_profile_id second_profile_id
where:
context format uses an identification line for each file, containing the filename
and modification date.
47
unified uses plus and minus signs to indicate differences: each line that
occurs only in the left file is preceded by a minus sign, each line that occurs
only in the right file is preceded by a plus sign, and common lines are
preceded by a space.
Note: The only options supported are context and unified.
profile_id indicates the name of the profile. You can display the list of profile
IDs available for comparison by entering the following command:
Director (config) # remote-config diff unified profiles ?
first_profile_id second_profile_id
2003Nov05160651PST
2003Nov05160921PST
2003Nov05161008PST
2003Nov06113244PST
write-to allows you to save the differences to a file. Give the file a meaningful
name in case you want to delete the file in the future.
Note that if you choose this option, the comparison is not output to the screen.
To view the contents of the file, use the show remote-config diff file_name
command.
The comparison is output.
48
--- /local/tmp/2003Nov05160921PST Fri Apr 16 07:48:55 2004

+++ /local/tmp/2003Nov05161008PST Fri Apr 16 07:48:56 2004
@@ -1,28 +1,10 @@
!
-!
+security management display-realm "Blackbird"
security management no auto-logout-timeout
!
-access-log ;mode
-edit log im ;mode
-client-type websense
-exit
-create log "testlog"
-edit log testlog ;mode
-client-type websense
-websense-client primary 10.24.35.46 55805
-websense-client alternate 10.25.36.47 55805
-exit
-exit
-!
-services ;mode
-telnet-console ;mode
-enable 23
+forwarding ;mode
+add 10.25.36.47 80 http default
exit
-exit
-!
!
!
!
Figure 31 Output text.
49

An overlay is a collection of one or more individual configuration settings
(such as time, SNMP, or bandwidth gain) that can be applied to one or a
selected set of SG appliances. An overlay is designed to change settings created
by a profile or add new settings not covered in the profile.
Tips
When making configuration changes in overlays by using a Management
Console Viewer to view options, configuration changes are not applied to the
SG appliance used to launch the viewer. Perform an immediate action or
schedule a job for the action to apply the overlay changes to a device.
Blue Coat recommends that Overlays do not contain more than 500
commands.
Director does not check overlays for syntax, validity, or version number, so
ensure that overlay commands are from the same version as the targeted SG
appliance. Test overlays before applying them, and be sure they work
correctly with the profile you choose.
Creating Overlays
To create an overlay:
1. In Director, click the Configure tab.
2. In the Configuration Library section, select the Overlays tab.
3. In the lower right corner, click New. The Create New Overlay dialog
displays.
50
4a
4b
4c
4. Configure the Overlay properties:

a. In the Overlay Name field, enter the name of the overlay. (The Overlay
ID field uses the same string.) You can later change the name of the
profile but not of the Overlay ID (the Overlay ID must be unique).
b. (Optional) In the Description field, enter a description of the overlay.
c. (Optional) Select a source device or a URL to add refreshables to the
overlay. Refreshables are configuration and policy options that can be
pulled from a device or URL and refreshed as part of a job.
51
5a
5b
5c
5. In the Add to Overlay section, specify the overlay settings, using the following
methods:
a. To use the Management Console of a device, select Using Device
Management Console and click the browse (...) button. A list of
available devices is highlighted; select the device to be the source.
Click Launch to open the target device (the devices Management
Console displays). Verify or alter settings for the overlay. Click Add to
Overlay to add the device settings to the overlay.
b. To use the CLI, select Using CLI and enter configuration CLI
commands in the pop-up text editor. The commands are not checked
for validity or syntax.
c. If you selected a target device to be used as a refreshable source in Step
5c, select Refreshables to enable these options. Select the source device
or URL settings. To add the information to the overlay, click Add. The
options display in the Overlay Settings section.
Figure 32 Refreshable settings added to the overlay.
6. Click OK.
52
Applying an Overlay Immediately

You can push an overlay immediately or at a later date, as part of a job.
To apply an overlay immediately:

1. Verify that the Overlay tab is selected in the Configuration Library section.
2. Highlight an overlay.
3. Highlight a device or group of devices, excluding System Groups. You can
select multiple devices.
4. Click Apply. A confirmation dialog displays.
5. Click OK to execute the overlay. When completed, an Execution Results dialog
displays.
6. Close the dialog to return to the Configure tab.
Refreshing and Deleting Overlays

You can delete individual overlays.
To refresh or delete an overlay:

1. Highlight an overlay in the Configuration Library section.
2. Right click on the overlay and select Refresh or Delete. A confirmation dialog
displays with a prompt to continue.
3. Click Yes.
Related CLI Syntax to Manage Overlays

Director (config) # remote-config overlay overlay_name
Director (config remote-config overlay overlay_name) #
Director (config remote-config overlay overlay_name) # comment comment
Director (config remote-config overlay overlay_name) # type {SG5 |
SG4}
Director (config remote-config overlay overlay_name) # name
overlay_name
Director (config remote-config overlay overlay_name) # show remote-
config overlay overlay_name
Director (config remote-config overlay overlay_name) # execute device
device
53

This section describes how to use substitution variables in profiles and overlays
to perform configuration changes on SG appliances.
About Substitution Variables

Without substitution variables, you would be required to create multiple
overlays, one for each configuration difference. If you are managing a large
number of SG appliances, maintaining all of those overlays is challenging at
best.
Substitution variables allow you to replace a value on one device without
changing the overlay. Substitution also allows you to replace a variable with
multiple CLI commands.
Substitution tokens are created in the following format: @(name). When an
overlay is applied to an SG appliance, the token is replaced with the
appropriate value from the device-specific configuration.
Use Case
Because of a network update, you must change the DNS setting on SG
appliance Gateway3 from 10.2.2.100 to 10.2.2.200.
The first step is to replace the DNS CLI configuration string with:
@(DNS)
The next step is to create a device-specific setting:
10.2.2.200
Next, create an overlay called GatewayDNS with the contents:
dns clear server
dns server @(DNS)
When the overlay is applied to the target SG appliance, the @(DNS) token is
replaced with the CLI commands to clear to the server settings and apply the
new setting.
Notes and Upgrade Issues

The token format must be as follows: @(name). If there are any spaces, errors
occur.
The maximum length of the name is 64 characters, alphanumeric only.
If you do not want an @(..) token to be a substitution variable, use
backslashes to escape the token: \@$..$.
After upgrading to SGME 5.2.x, Director scans profiles and overlays for the
existance of @( characters.
Creating and Implementing Substitution Variables

This section describes how to create overlays that use substitution variables,
how to create substitution variables on SG appliances, and how to implement a
configuration change using the variables.
54
Creating the Variables in the Overlay

This first step is to create an overlay that replaces the CLI commands invoked by
Director with substitution variable tokens.
To create an overlay with substitution variables:

1. In Director, click the Configure tab.
2. In the Devices section, select an SG appliance for which you require the
configuration change.
3. In the Configuration Library section, select the Overlays tab.
4. In the lower right corner, click New. The Create New Overlay dialog displays.
5a
5b
5. In the Properties area:

a. Enter a name for the overlay. This example uses GatewayDNS. As you
enter a name, the Overlay ID field fills in automatically with the same
name. Blue Coat recommends using the same ID, but you can modify
it.
b. (Optional) Describe the purpose for the overlay.
Use source SG
applianceto
configure.
Use CLI
commands to
configure
6. There are two methods to configure settings that are added to the overlay:
If you know the SG appliance CLI syntax for the feature, go to "Use a
Management Console Viewer" .
55
If you do not know the CLI syntax and require a Management Console for
reference, go to "Use a Management Console Viewer" on page 56.
Use a Management Console Viewer

Configure by displaying Management Console.
1. Select Using Device Management Console name.
2. Click the browse (...) button. The Select Device dialog displays.
3. Select a connected device; you will base the configuration changes on this
device.
4. Click OK.
5. Click Launch. The Manage Device displays the Management Console view of
the device you selected.
Management Console View method: use the user interface to configure thesettings
for this overlay, which In this example is changing the DNS setting.
6f
6g
a. Continuing with the example of setting a new device, select Network >
DNS.
b. Highlight the current DNS value and click Edit. The Edit List Item
dialog displays.
56
Change the
setting.
c. Change the value. This example changes the DNS value to 10.2.2.200.
d. Click OK to close the dialog.
e. Click Save to Overlay at the bottom of the Management Console View.

f. Click OK to close the Create New Overlay dialog.
g. Select the configuration name. In this example, it is DNS because you
changed the Network > DNS setting on the SG Management Console
Viewer.
h. Click Edit. The Edit CLI dialog displays.
57
i. Replace the value with the new variable. In this example, it is @(DNS).
j. Click OK to close the Edit CLI dialog; click OK to close the Create New
Overlay dialog.
k. Proceed to "Defining the Configuration Value and Changing a Device
Configuration" on page 59.
Manually Enter CLI Syntax

Configure by entering CLI syntax into the Director Management Console.
a. Select Using CLI. The Add Components to Add to the Overlay dialog
displays.
CLI method: enter Blue Coat CLI commands to configure the settings for this overlay,
which In this example change the DNS setting.
b. Enter the CLI syntax. This exmple uses the dns clear server and dns
server dns server @(DNS) command lines.
c. Click OK to close the dialog.

d. Click OK to close the Create New Overlay dialog.
e. Proceed to the next section, "Defining the Configuration Value and
Changing a Device Configuration" .
58
Defining the Configuration Value and Changing a Device

Configuration
After the overlay containing the variable(s) is created, the next step is to replace
the variable with a configuration value and distribute that configuration to an SG
appliance.
To define a configuration value and change a device configuration:
1. Select one or
more devices.
2. Right-click and
select Edit.
1. In the Devices area, select one or more SG appliances.

2. Right click the appliance(s) and select Edit. The Edit Device dialog displays.
3. Click Advanced Settings, located at the bottom of the dialog. The Advanced
Settings dialog displays.
59
4a
4c 4b
4d
4. Define a value for the variable:

a. Click the Substitution Variables tab.
b. Click New.
c. In the Substitution Variable Name field, enter the name of the variable.
This is the same name you created in the overlay. For example, the
variable token in the example was @(DNS). So the name of the variable
is DNS.
d. In the Value field, enter the new configuration value. In this example,
the requirement is to change the gateway DNS value to 10.2.2.200.
e. Click OK to close the dialog.
5. Another dialog displays a confirmation prompt to confirm the change in this

device configuration. Click Yes.
6. In the Configuration Library section, select the overlay to apply the changes. In
this example, the GatewayDNS overlay. Click Apply to invoke the variable.
7. Now that the variable token is defined, you can distribute this overlay or
profile to any device. Repeat Steps 1 through 6 to create the variable on the
devices.
60
Related CLI Syntax

device ID substitution-variable name input
show devices ID substitution-variable
no device ID substitution-variable name
61

This section discusses how to obtain appliance certificates for Director.
Overview
An Appliance certificate allows Director to be authenticated without sending
passwords over the network. Device or appliance authentication is a process
that allows devices to verify each others identity. Devices that are
authenticated can be configured to trust only other authenticated devices.
Device authentication is important in the following situations:
Securing the network. Devices that are authenticated have exchanged
certification information, verified each others identity, and know which
devices are trusted.
Securing protocols. Many protocols require authentication at each end of
the connection before they are considered secure.
Director appliance authentication is used in association with other Director
features. For example, Director requires an appliance certificate in order to use
the auto-registration feature. The auto-registration feature, where an SG
appliance registers itself with Director, requires that both the SG appliance and
the Director appliance first authenticate each other.
About Director Appliance Certificates

Director appliances come with a cryptographic key that allows the system to be
authenticated as a Director appliance when an appliance certificate is obtained.
An appliance certificate is an X.509 certificate that contains the hardware serial
number of a specific Director device as the CommonName (CN) in the subject
field. This certificate can then be used to authenticate the Director appliance
whose hardware serial number is listed in the certificate.
Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance
certificates. The root certificate for the Blue Coat CA is automatically trusted by
SGOS for device authentication. These Blue Coat signed certificates contain no
authorization information and are valid for five years.
Obtaining an Appliance CertificateInternet Connection

To obtain an appliance certificate for a Director appliance that has an Internet
connection:
1. Log in to the Director appliance whose certificate you want to obtain.
2. From the (config) prompt, enter:
Director (config) # ssl request-appliance-certificate-cert
Requesting certificate
Verifying certificate
Certificate verified successfully
62
This command creates a new private key, creates the certificate signing request
signature (CSR) for the private key, and sends the CSR to abrca.bluecoat.com
to fetch the corresponding appliance certificate.
To display the appliance certificate:

From the (config) prompt, enter:
Director (config) # show ssl request-appliance-certificate
Obtaining an Appliance CertificateNo Internet Connection

To obtain an appliance certificate for a Director appliance that does not have an
Internet connection:
1. Log in to the Director CLI.
Director (config) # show ssl appliance-certificate-request
This command creates a CSR (if it does not already exist) and displays it. It
also creates the digital signature for the CSR, using the appliance private key.
63
-----BEGIN CERTIFICATE REQUEST-----

MIICuDCCAaACAQAwczELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQH
EwlTdW5ueXZhbGUxHDAaBgNVBAoTEydCbHVlIENvYXQgU3lzdGVtcycxEDAOBgNV
BAsTB1NHTUU1MTAxEzARBgNVBAMTCjQ3MDYxMDUyMzMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDGC0CSms4F2C4pFuHbJW0zAEJfna+54giEIW49I2qA
l9J/yAmwDhPcScd+mAJJEMdsWuU5BIuNcoGCTXBQCTXF/Wjo6B9CHTTENvAy8r2Y
JiHE5OJPXfqHDjzsnxppo54L//G3CgAsW8rI7UDsnpML8gDuQ1SXefopFPfa8WOw
RtKpU87Ma/YhTexHMmI1p+wYyOaiv/P/KpfLPyIqICvdKhMdvh3lk49u+maPLt0R
7+ljzWbJ8cD2oQvQkEmhEOMtX+rotkUT1GHJF+J5maSns8WfCkjnQ8N7NzwQAGnb
7plbhZcA4jIGvIltavCcREab3VfHlVJKn5eskNKrFKzrAgMBAAGgADANBgkqhkiG
9w0BAQUFAAOCAQEALGNLV4I6Vk5Rznq4DvLbdi7rceO8xD0e2poAjxdjFUaBXf/4
9vQMB41BdjA1f1Ic1f9a0MG6Qwm+ngJsAUJN46ZGtRRjgd5kImYveFX1+hJjg9vb
5Wp/5xEf3jWVB1EBtvqdAcSe+y8qS4/fDFs2VJv806i4oNCvzJKLmNcY7/J5++3Z
BvOThkuI5DROqA4ivN8o+ENIG98xgcsQqKnf+wGg3TKqC9x/15PcoCgxAsc6zlmU
joUgYgFNCJIGZBn2pqCgS7giHfNz2Di6LUf0ZCiOxR8p2n0fr4c1D6OmNpEB5vXH
DTUG7fyToMQITCK6vKz+oL+alQyVvDpYgNpAug==
-----END CERTIFICATE REQUEST-----
----- BEGIN CSR SIGNATURE -----
wrj98DWIUuIfiCxOcq7GnbQOjKI4S20WG3/6gzlzNaJN/pyQHwG4ehpzII+6JlY+
GKwzXmpa46Tyhkfv3HMIDBhAB31vJljNMwzjwn2Uc3AmEhd/mVBdw9U1q4UTWhzU
M8yuhbjMla3939IcwNrwIbQmEiaSRXHxUfcRYty5Q8CYZe0A8OSB8JDIHex1+E9K
ICjUBlUpz8rdeL/SxYZmwnrOTDoZ1KOz0bCbNVcjPsmZhqLwSrQwsBUXGiutjHDe
B/Hg3z0bPcvh1CNQZNv2LgSVPdPpeB6OPaSaQkuSs6WwPmeGGurSl7K0w6t/V6XL
VY93Z3Jph1FNpH7FES+pvw==
----- END CSR SIGNATURE -----
Figure 33 Sample CSR
3. Copy the CSR and the signature to your clipboard. Include the Begin
Certificate and End Certificate statements, as well as the Begin CSR
Signature and End CSR Signature statements.
4. Open a browser and go to the Blue Coat CA Server Website at

https://abrca.bluecoat.com/sign-manual/index.html.
5. Paste the CSR and signature into the CSR panel.
64
6. Click Generate Cert.

The signed certificate displays and can be pasted into Director.
65
-----BEGIN CERTIFICATE-----
MIIF/jCCBOagAwIBAgICAMowDQYJKoZIhvcNAQEFBQAwgbYxCzAJBgNVBAYTAlVT
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV
BAoTF0JsdWUgQ29hdCBTeXN0ZW1zLCBJbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs
IEFCUkNBMRswGQYDVQQDExJhYnJjYS5ibHVlY29hdC5jb20xJDAiBgkqhkiG9w0B
CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMjkyMDM5NDdaFw0xMjAx
MjkyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcT
CVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd
BgNVBAsTFkJsdWUgQ29hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTCjA1MDUwNjAw
OTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMBUmCuKSsSd+D5kJQiWu3OG
DNLCvf7SyKK5+SBCJU2iKwP5+EfiQ5JsScWJghtIo94EhdSC2zvBPQqWbZAJXN74
k/yM4w9ufjfo+G7xPYcMrGmwVBGnXbEhQkagc1FH2orINNY8SVDYVL1V4dRM+0at
YpEiBmSxipmRSMZL4kqtAgMBAAGjggLGMIICwjAJBgNVHRMEAjAAMAsGA1UdDwQE
AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr
BgEEAfElAQECAQYLKwYBBAHxJQEBAgIGCysGAQQB8SUBAQIDMB0GA1UdDgQWBBSF
NqC2ubTI7OT5j+KqCPGlSDO7DzCB6wYDVR0jBIHjMIHggBSwEYwcq1N6G1ZhpcXn
OTIu8fNe1aGBvKSBuTCBtjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExEjAQBgNVBAcTCVN1bm55dmFsZTEgMB4GA1UEChMXQmx1ZSBDb2F0IFN5c3Rl
bXMsIEluYy4xGTAXBgNVBAsTEEJsdWUgQ29hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi
cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AYmx1ZWNv
YXQuY29tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB
hj1odHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9jZ2ktYmluL2RldmljZS1hdXRo
ZW50aWNhdGlvbi9vY3NwMEIGCCsGAQUFBzAChjZodHRwOi8vYWJyY2EuYmx1ZWNv
YXQuY29tL2RldmljZS1hdXRoZW50aWNhdGlvbi9jYS5jZ2kwSAYDVR0fBEEwPzA9
oDugOYY3aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj
YXRpb24vQ1JMLmNybDBfBgNVHSAEWDBWMFQGCisGAQQB8SUBAQEwRjBEBggrBgEF
BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj
YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X
d2/Qw7NiVsnqOlAy913QZlieFfVATJnCeSrH+M9B/2XtnRxVT0/ZWrf4GbsdYqTF
hc9jR/IwKu6kZq32Dqo8qFU5OzbAEzT2oebB5QgwuJtHcJHggp9PS9uS27qAnGQK
OeB2bYcjWtMvTvr50iDOV69BEQz+VXos8QiZmRHLVnebQSjl3bi1w3VjBw31tCmc
clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq
r23/+BsZlYKAeVMq3PEmxaA2zLzO+jf79a8ZvIKrF27nNuTN7NhFL/V6pWNE1o9A
rbs=
-----END CERTIFICATE-----
To import the certificate onto the Director appliance:

1. Copy the signed certificate to your clipboard. Be sure to include the Begin
Certificate and End Certificate statements.
2. Log in to the Director CLI.

Director (config) # ssl input appliance-certificate
66
Enter your certificate now.

Press Ctrl-D when finished, or Ctrl-C to abort.
4. Paste the certificate from your clipboard into the CLI.

5. Press Ctrl-D when finished.
To view the imported certificate:

To display the appliance certificate, from the (config) prompt, enter:
Director (config) # show ssl appliance-certificate
The certificate displays in the CLI.
67

This section describes how to automatically and securely register SG appliances
with Director.
Note: This feature is only supported on the Linux platform 510 Director.
Overview
The Director auto-registration feature allows you to automatically register an
SG appliance with Director, thus enabling Director to establish a secure
administrative session with the appliance. After the secure session has been
established, Director takes administrative control over the SG appliance. This is
useful if you want to control access to the appliance or if you want to ensure
that only Director controls changing the configurations.
About the Registration Process

The auto-registration feature results in Director having full adminstrative
control over the SG appliance.The SG appliance communicates with Director
during the registration process using HTTPS while Director uses two web
services to listen for registration requests.
Both devices use their Blue Coat appliance certificates or a shared secret to
confirm identities before exchanging public keys. If the SG appliance has an
appliance certificate, that certificate is used to authenticate the SG appliance to
Director as an SSL client. If the SG appliance does not have an appliance
certificate, you must configure a shared secret (a registration password
configured on Director) and enter the same password when configuring the SG
appliance to confirm identities before exchanging public keys. After both
appliances authenticate each other, registration is complete and Director has
full administrative control over the SG appliance.
When the SG appliance either succeeds to or fails to register with Director,
different traps are generated. The SG-newly-registered trap is sent when
registration is successful. If registration fails, the SG-registration-failed trap is
sent.
Workflow Methods
There are two types of workflow methods for setting up auto-registration:
"Registering SG Appliances without Pre-Staged Device Records" on page 69
Use this method to add SG appliances to Director on demand.
"Registering SG Appliances with Pre-Staged Device Records" on page 75
Use this method to pre-stage (pre-create) basic configuration, which
includes setting access control passwords, for all your SG appliances on
Director. This method can help you with your workflow when planning a
large deployment.
68
Registering SG Appliances without Pre-Staged Device Records

Table 31 provides a high-level view of workflow tasks for automatically
registering SG appliances with a Director that does not have pre-staged device
records. It also provides a task description and the role most suitable for
performing the task.
Review this table, then read the sections that follow for detailed information
about each task.
.
Table 31 Workflow TasksRegistering SG Appliances without pre-staged device records
Task Task Description Role
1. Configure Director to accept the Configure Director so that both the Director Director
SG appliance request. and SG appliance can authenticate each other. Administrator
See Section F: "Authenticating Director using
Appliance Certificates" on page 62.
Authentication procedure depends on
whether the SG appliance has an appliance
certificate. See "How Director Authenticates
the SG Appliance" on page 70.
1. Register SG appliance with Verify the SG appliance has been installed SG Technician
Director. and connected to the network.
Enter SG appliance initial configuration SG
settings including the Director IP address Administrator
and the registration password (if required).
Register the SG appliance with Director,
then verify the Director serial number.
Director and the SG appliance automatically
authenticate each other as part of the
registration process.
1. Set passwords for newly View the newly registered device on Director
registered Director device. Director. Administrator
Change randomly set passwords (Enable
and Serial Console passwords) exchanged
during the authentication process, to
something meaningful.
Device record is now complete and fully
connected to Director through a secure
SSH-RSA connection.
1. Configure the new device and Configure the device by pushing profiles Director
place it into a group. and overlays to it. See Section C: Administrator
"Managing Profiles" on page 43 and Section
D: "Managing Director Overlays" on page
50.
Mark the device as configured and then
place it into a group.
69

Before an SG appliance sends a registration request to Director, Director must be
have an appliance certificate and be configured properly so that it can receive the
request. For the registration process to succeed, both the SG appliance and
Director need to first authenticate each other.
Note: For information about obtaining an appliance certificate for an SG

appliance, refer to Volume 5: Advanced Networking in the Blue Coat SGOS
Configuration and Management Suite.
For information about obtaining an appliance certificate for a Director, see section
"About Director Appliance Certificates" on page 62.
How Director Authenticates the SG Appliance

Director needs to authenticate the SG appliance that is making the registration
request. The authentication procedure depends on whether the SG appliance has
an appliance certificate.
Authenticating an SG Appliance That Has an Appliance Certificate

Director authenticates an SG appliance that has an appliance certificate
automatically. Director receives the appliance certificate from the SG appliance
and then verifies it using the ABRCA root certificate.
Refer to Volume 5: Advanced Networking in the Blue Coat SGOS Configuration and
Management Suite for more information about how to obtain an appliance
certificate for an SG appliance.
Authenticating an SG Appliance That Does Not Have an Appliance

Certificate
If the SG appliance does not have an appliance certificate, it uses a shared secret-
based authentication method. The Director Administrator creates a random
shared-secret registration password that is known only by Director and the SG
appliance. The shared-secret password must match on both appliances for
authentication to succeed.
To create a registration password, use the ssl configuration mode CLI command:
From the CLI config mode on Director, enter:
director(config)# ssl registration-password password
If the front panel is being used, the registration password character set is a-z0-
9A-Z-,. (The final dash is a true dash). Minimum length is 1; maximum length
is 16.
On the SG appliance side, the administrator must enter the same shared-secret
password (registration password) through the SG appliance serial console or
managment console. For more information see "Configuring the SG Appliance
from the Serial Port" on page 71.
70
Note: The serial console password can be set only via the SG serial console or the
registration protocol and not through an SG CLI command. This protects the
serial console password from a user who may have access to the SG CLI.
How an SG Appliance Authenticates Director

The SG appliance needs to authenticate the Director with which it is attempting to
register. Director must already have an appliance certificate for authentication
and registration to succeed.
Authenticating Director Appliances that Have Appliance Certificates

Generally, an initial install occurs on a new Director appliance. New Director
appliances already have their appliance certificates automatically configured
during the manufacturing process. The Directors appliance certificate
information is securely sent (through the HTTPS protocol) to the SG appliance
and authenticated automatically.
Authenticating Director Appliances That Do Not Have Appliance

Certificates
If you already have a Director appliance that needs to be upgraded, it may not
have an appliance certificate. In this case, the Director Administrator must fetch
the appliance certificate from ABRCA and import it.
Note: For information about obtaining an appliance certificate for Director, see
"About Director Appliance Certificates" on page 62.
Registering the SG Appliance with Director

After the SG appliance is installed and connected to the network, the SG
administrator needs to configure the SG appliance specific initial settings.
Note: The SG appliance can be configured using its front panel buttons, Web
wizard, or serial console. Refer to the SG appliance installation guide for your
platform for more information. The SG appliance can also register with Director
from the SG appliance Management Console. For detailed instructions, refer to
Chapter 2 in Volume 7: Managing Content of the Blue Coat Systems SGOS
Configuration and Management Suite.
Configuring the SG Appliance from the Serial Port

Although there are various methods of configuring the SG appliance, this section
provides sample information about configuring the SG appliance from the serial
port.
Initial SG appliance configuration settings include:
Register with Director option
71
SG IP address
SG appliance IP subnet mask
Director IP address
SG appliance IP gateway
Registration password (only if the SG appliance does not have an appliance
certificate. The SG appliance administrator needs to know this password and
it must be the same one configured on Director.)
Appliance name (optional)
Verify the Director serial number
The following example is a sample SG appliance setup console code output.
Welcome to the SG Appliance Setup Console
How do you want to set up the SG appliance?

M)anual setup using the serial console
R)egister with Director (registration password required)
Choose setup mode:R
IP address: 10.0.0.1
IP subnet mask : 255.255.255.0
Director IP :
address [0.0.0.0]: 10.0.0.146
IP gateway : 10.9.44.1
Registration password:
Appliance name (optional):
You have entered the following IP addresses:
IP address: 10.0.0.1
IP subnet mask: 255.255.255.0
Director IP: 10.0.0.146
10.
IP gateway: 10.9.44.1
Would you like to change any of them? Y/N N

Connecting to 10.0.0.146 to determine Director serial number
This can take up to 90 seconds ... please wait
Director reports serial number: 1234567899
Is that the expected serial number? Y/N Y
Connecting to 10.0.0146 to register with Director 1234567899

Registration succeeded
Press "enter" three times to activate the serial console
Figure 34 SG serial console output text
Note: The SG appliance does not prompt for a registration password if it detects
that it has an appliance certificate.
The SG administrator needs to verify that the Director serial number is correct for
registration to succeed. After the serial number is verified, authentication
automatically occurs as part of the registration process.
72
After the registration process is complete, the SG appliance is administratively

controlled by Director. When registration succceeds, the SG-newly-registered trap
is generated.
Setting Passwords for Newly Registered Devices on Director

After registration is complete, a new device (representing the SG appliance)
displays in the Devices section on the Director Management Console. This device
is part of the registered group by default.
At this point, you must change the Enable and SSH Console passwords that were
randomly set on the SG appliance during the auto-registration protocol. We
recommend that you change the passwords to something meaningful. You must
also enter a Frontpanel pin password.
To reset randomly set passwords and set the Frontpanel pin password:
1. Verify that you are in the Configure tab on the Director Management Console.
2. Right-click on the new device whose passwords you want to set. A pop-up
menu displays.
3. Select Set Passwords. The Enter Passwords dialog displays.
4. Enter the new passwords:

a. In the Enable Password field, enter a password to access enable mode
on this device and device record. Character minimum length is 1;
maximum length is 64.
b. In the SSH Console Password field, optionally enter a password that
allows both the SG appliance CLI and SG appliance management
console to be enabled. Character minimum length is 1; maximum
length is 64.
c. In the Frontpanel Pin field, enter a password to set the front-panel-pin
on this device and device record. The character set is 19; and the
length is 4 characters.
73
Note: To save your changes, you must enter a valid password in all
three fields.
d. Click OK.
Related CLI Syntax

The pushpassword and front-panel-pin commands set these passwords on
both the SG appliance and the device record.
director (config device device_id) # pushpassword {enable-password
password | front-panel-pin pin | password password}
director (config device device_id) # front-panel-pin pin
The enable-password and serial-console-password commands set these

passwords on the device record only.
director (config device device_id) # enable-password enable-password
director (config device device_id) # serial-console-password password
Configuring New Device Records on Director

After the new device has registered with Director and you have reset both the
Enable and SSH Console passwords, the device is ready to be configured.
To complete device configuration:

1. Configure the device according to the instructions in "Configuring a Device
from Director" on page 41.
2. Apply profiles and overlays to the device according the instructions in
"Applying a Profile" on page 46 and "Applying an Overlay Immediately" on
page 53.
74
3. After the device is completely configured, click the Configure tab and right-
click on the device name. A pop-menu displays.
4. Select Mark As Configured. The devices state changes from Registered to
Configured and is automatically placed in the Unassigned group under
System Groups.
5. Place the device into a group of your choice. Follow instructions in "Using the
New Device Wizard" on page 40.
Registering SG Appliances with Pre-Staged Device Records

If your company is rolling out a large deployment, it might be more effective to
pre-stage or pre-create basic configuration tasks for all your systems on Director.
This workflow method lets you preconfigure passwords, create profiles and
overlays, and create jobs that are already associated with a device before the SG
appliance has registered with Director. Pre-staging accelerates registration and
deployment efficiency.
75
You can also create groups beforehand and then place the device, after it has been
registered and been configured, in the group of your choice.
Table 32 provides a high-level view of workflow tasks for automatically
registering SG appliances with a Director that has pre-staged device records. It
also provides a task description and the role most suitable for performing the
task.
Review this table, then read the sections that follow for detailed information
about each task.
Table 32 Workflow tasksRegistering SG Appliances with pre-staged device records
1. Configure Director to accept the Configure Director so that both the Director Director
SG appliance request. and SG appliance can authenticate each other. Administrator
See Section F: "Authenticating Director using
Appliance Certificates" on page 62.
Authentication procedure depends on
whether the SG appliance has an appliance
certificate. See "How Director Authenticates
the SG Appliance" on page 70.
2. Create a partial device record on Create a partial device record which Director
Director. contains configuration information that Administrator
matches with the configuration information
of the SG appliance that will be deployed.
See "Creating a Partial Device Record on
Director" on page 77.
Configure the passwords in the device
record.
Optionally, configure profiles and overlays
for the device. See Section C: "Managing
Profiles" on page 43 and Section D:
"Managing Director Overlays" on page 50.
3. Register SG appliance with Verify the SG appliance has been installed SG Technician
Director. and connected to the network.
Enter SG appliance initial configuration SG
settings, including the Director IP address Administrator
and the registration password (if required).
Register the SG appliance with Director
and verify the Director serial number.
Director and the SG appliance automatically
authenticate each other as part of the
registration process. The registration request
matches the pre-staged device record and
populates it with SG appliance connection
information.
76
Table 32 Workflow tasksRegistering SG Appliances with pre-staged device records
4. Configure the new device and Configure the device by pushing profiles Director
place it into a group. and overlays to it if it is not already Administrator
configured during the Step 2 task.
Mark the device as configured, and then
place it into a group.

(Pre-Staged)
To configure Director to accept registered SG appliances, follow the instructions in
"Configuring Director to Accept Registered SG Appliances" on page 70.
Creating a Partial Device Record on Director

You can create a partial device record, which contains configuration information
that matches the SG appliance configuration. When Director receives a
registration request from an SG appliance, it tries to match the information in the
request with information that is contained in an existing device record.
If there is a match between the partially created device record and the SG
appliance, the passwords in the device record are pushed to the SG appliance.
Director matches information in the device record with SG appliance settings
according to the following rule order:
1. Director matches the SG appliances serial number with the device record
serial number first, if it exists.
The serial number in the device record is matched first, if it exists.
2. Director matches the SG appliances IP address with the device record IP
address.
Director first performs a DNS lookup on the associated hostname and then
matches the IP address.
3. Director matches the SG appliances name with the device record Device ID.
The appliance name is optional on the SG appliance.
If more than one parameter exists in the device record, all of the parameters are
matched. If any parameter fails, Director rejects the registration request, an error
message displays on the SG appliance console, and an
SG-registration-failed trap is generated.
If all matches fail, a new device record is created with the SG appliance name as
the Device ID. If the SG appliance name is not provided then the IP address is
used to create the Device ID.
77
To create a partial device record:

1. Launch the New Device Wizard by clicking Add Device(s) in the lower left-
hand corner of the Configure panes.
2. Read the introductory information about what the wizard does and click Next.
3. Enter the device ID in the Device ID field. Optionally, you can also enter the
IP address and serial number in the IP Address andSerial No.fields,
respectively.
4. Click Add Row to add another device.
5. Click Add Device(s) to save changes.
Registering the SG Appliance with Director (Pre-Staged)

Registration is complete only after Director has successfully matched the SG
appliance with an existing device record. When a match occurs, Director gains
administrative control over the SG appliance. This means that only Director
controls the SG appliancess configuration and operations going forward.
The device is now complete and fully connected to Director using SSH-RSA,
which is more secure when compared to password authentication.
Configuring the New Device Record (pre-staged)

Place the device into a group of your choice. For instructions, see "Configuring
New Device Records on Director" on page 74.
78

You can return to a previous SG appliance configuration by using a backup (a
snapshot of the device at a point in time). Backups are either created explicitly
by request or automatically prior to each profile being run. They are stored on
Director.
Backup configurations consist of specific configuration parameters related to a
particular SG appliance. A backup saves all configuration settings.
Director stores a certain number of backups per SG appliance (the default is 10).
These are time-stamped and rotated out on a first-in, first-out basis after the
number of allowed backups per SG appliance reaches the configured
maximum. You can prevent any specific backup from being rotated out by
pinning it. This allows you to save the backup for later use.
Note: You cannot set the maximum number of backups per SG appliance to a
lower number than the number of backups that already exist on Director. To set
three backups as the default, for example, you must not have more than three
backups on Director. You can manually delete the extra backups. You set the
maximum number of backups through the Director CLI.
The absolute maximum number of backups is 2000, but Director Management
Console performance is significantly degraded and backup functions, such as
sorting, cannot be done.
You can also back up both the Director management node configuration and
SG appliance backup files.
Any show configuration command that begins with the following string is not
included in the backup:
ip-default-gateway
interface (the entire submode)

line-vty (the entire submode)
Topics in this Section

The following topics are discussed in this section:
"Creating a Backup" on page 80Creating an immediate backup.
"Pinning a Backup" on page 82Keeping a backup indefinitely.
"Restoring a Backup" on page 83Restoring SG appliance backups.
"Deleting a Backup" on page 84Deleting unneeded backups.
"Comparing Two Backups" on page 84Comparing two backups.
Note: You can also archive and restore the Director configuration, including the
SG backup files (see "Archiving and Restoring the Entire Director Configuration"
on page 225).
79
Creating a Backup
Backups are created two ways: automatically, immediately prior to a profile, or
manually, at the point when you need a backup. The manual backup procedure is
discussed below. To schedule a backup job, see "Scheduling a Job" on page 91.
To start the Backup Manager:

1. Verify that the Configure tab is selected.
2. Highlight the device to back up.
3. In the Description area for the device, click Launch Backup Manager. The Back
Up Manager displays.
Figure 35 The Backup Manager dialog.
The Backup Manager dialog contains a summary table and buttons to create,
view, edit, pin, unpin, delete, restore, and refresh the list of backups.
Director automatically creates a backup when you apply a profile to a specified
device. If you want to create a backup without sending a new configuration to an
SG appliance, click Create below the summary table and follow the procedure on
the next page.
80
To create a backup using the Backup Manager:
1. Click Create below the Backup Manager table. The Create Backup dialog
displays.
2. Click Yes in the dialog. Director creates the backup.
81
3a
3b
3c
3. The following settings are optional:

a. Enter a different name than the generated default. Click Save Name to
display the new name in the field (the default name is not changed; it
is appended to the custom name).
b. Enter a description. Click Save Description to display the new
description.
c. Click View Contents to display the configuration file.
4. Click Close to return to the main Configure window.
Pinning a Backup
You can make a backup of an SG configuration and keep it permanently by
pinning it. By default, backups are unpinned, and are rotated out of storage after
the maximum number of backups is reached.
82
The maximum number of backups per device is unlimited (the default is 10),
unless you change it through the command remote-config backups option max-
backups number. The maximum number of pinned backups is one less than the
maximum number of backups allowed.
Note: You must leave at least one backup unpinned.
To pin a backup:
1. Start the Backup Manager.
2. Highlight an item in the Backup Manager table. You can choose more than one
at a time.
3. Click Pin.
5. Click OK. The backup now displays a check in the Pinned column in the
Backup Manager table.
Unpinning a Backup
Unpinning a backup allows it to be rotated out of the storage directory. Follow the
steps as pinning a backup (previous section), except click Unpin in Step 2. You can
select and unpin several backups at once.
Restoring a Backup
If you encounter problems on an SG appliance with a current configuration, you
can restore a known good configuration with a saved backup. There are several
ways to restore configurations to SG appliances:
With a manual, stored time-specific backup
Through a known profile/overlay configuration
Note: You can also back up and restore the Director configuration, including
the SG backups stored on the Director management node. For more
information on backing up Director, see "Archiving and Restoring the Entire
Director Configuration" on page 225.
When a backup is restored, the following procedure takes place:

The restore-defaults command is sent over the configured protocol.
After sending the restore-defaults command, the reconnection protocol is
SSH Simple.
After reconnecting, the backup is applied to the SG appliance; then the
connection protocol is switched to the configured protocol.
83
To restore a backup:
2. Highlight the backup you want to use in the Backup Manager table.
3. Click Restore. A confirmation box displays, prompting you to continue.
4. Click Yes to continue. A progress dialog displays during the operation.
5. Click Close to return to the Configure tab.
Deleting a Backup
Director deletes backups automatically as the number of backups reaches the
maximum number you select. You can also manually delete backups.
To delete a backup or a pinned backup:

2. Highlight an item in the Backup Manager table.
3. Click Delete. The Delete confirmation dialog displays.
5. Click Close to return to the Configure tab.
Comparing Two Backups

You cannot compare backups through the Director Management Console. You
must use the CLI.
To compare two backups:

From the (config) prompt, enter:
Director (config) # remote-config diff {context | unified} backups
first_device_id first_backup_id second_device_id second_backup_id
-or-
Director (config) # remote-config diff {context | unified} backups
first_device_id first_backup_id second_device_id second_backup_id
write-to filename
where:
context format uses an identification line for each file, containing the
filename and modification date.
unified uses plus and minus signs to indicate differences. Each line that
occurs only in the left file is preceded by a minus sign, each line that
occurs only in the right file is preceded by a plus sign, and common lines
are preceded by a space.
The only options supported are context and unified.
84
first_device_id indicates the hostname or IP address of the device whose

backup you want to compare; first_backup_id is the backup on the device
you want to use; second_device_id indicates the hostname or IP of the
second device (it can be the same one) you want to compare; and
second_backup_id indicates the backup you want to compare to the first
backup.
write-to allows you to save the differences to a file. Give the file a
meaningful name in case you want to delete the file in the future.
Note: If you select write-to, the comparison is not output to the screen.
To view the contents of the file, use the show remote-config diff
file_name command. The comparison is output.
--- /local/tmp/10.25.36.48-10.25.36.48-2004.04.06-180451 Wed Apr 7 21:24:25 2004

+++ /local/tmp/10.25.36.48-10.25.36.48-2004.04.06-182142 Wed Apr 7 21:24:25 2004
@@ -6,6 +6,16 @@
!
!
!
+content-filter ;mode
+download day-of-week none
+download day-of-week sun
+select-provider smartfilter
+smartfilter ;mode
+download url http://list.smartfilter.com/cgi-bin/getlist.cgi?version=4.0&file=sfcontrol
+download username test
+download password "test123"
+exit
+exit
!
ntp interval 180
!
@@ -17,11 +27,11 @@
security hashed-enable-password $1$/L3S/lX$ElR3VYQrwV4mMA7MRbxGI1
security no enforce-console-acl
-inline policy vpm-xml "end-260826895-inline"
Managing Backups through the CLI

You can use the following commands to manage backups through the CLI. Details
for all CLI commands can be found in the Blue Coat Director Command Line
Interface Reference Guide.
From the (config) prompte, enter the following:
director (config) # remote-config backup
This changes the prompt to:

director (config remote-config backup) #
Use the following options to manage backups through the CLI:
85
director (config remote-config backup) # all

director (config remote-config backup) # device
director (config remote-config backup) # exit
director (config remote-config backup) # group
director (config remote-config backup) # help
director (config remote-config backup) # no
director (config remote-config backup) # options
director (config remote-config backup) # restore
director (config remote-config backup) # shell
director (config remote-config backup) # show
86
This chapter describes how to set up one-time and recurring jobs. Jobs enable
you to automate common or recurring tasks, for example, applying profiles and
overlays and rebooting appliances. Jobs consist of a list of actions. Each action
can target a single device, an arbitrary collection of devices, or a group of
devices.
Use jobs to automate the following tasks:
Applying or Refreshing Overlays
Applying or Refreshing Profiles
Distributing Content
Peforming Backups
Rebooting devices
Clearing various caches (object, DNS, byte-caching)
Upgrading SG appliance system software
Validating SG appliance software versions
Note: See "Creating a Profile" on page 43 for information about profiles and
overlays. See "Remotely Upgrading SG Appliance Software" on page 98 for
information about upgrading and validating SG appliance software.

"Performing Tasks in the Jobs Tab" on page 87
"Setting Up and Managing Jobs" on page 88
"Creating and Scheduling Jobs" on page 88
"Executing a Job Immediately" on page 94
"Verifying Job Execution" on page 94
"Editing Jobs" on page 96
"Deleting Jobs." on page 96
"Customizing the Job Queue View" on page 97
Performing Tasks in the Jobs Tab

The Jobs tab provides several different methods of selecting GUI items. For
example, to edit a job you can highlight the job and
Select Edit in the Jobs pane.
Right click the job and select Edit.
87
Select Edit Job from the Edit menu.

For clarity, the following procedures describe only a single method.
Setting Up and Managing Jobs

Jobs can be either:
Actions that occur on a regular, recurring schedule (for example, certain days
of the week, certain hours in the day). You can configure Director to
automatically schedule jobs to run on days and times that you specify.
Actions that occur irregularly. A non-recurring job does not adhere to a
regularly schedule, or perhaps occurs only once. You put the actions into a job
to save the settings, then you can run it again at some point in the future. If
you want to execute the job only a single time, you can execute the job
immediately. To execute a job immediately, see "Executing a Job Immediately"
on page 94.
You can schedule any number of jobs to run at any time and for any targets
defined in Director. Additionally, you can apply conditional operators to your
jobs to ensure a certain job execution behavior, such as:
Abort on errors: This operator configures the job to abort if any job action fails
Continue on errors: This operator configures the job to continue executing
actions even if a job action fails
These operators apply only to actions following the abort or continue action and
are overridden by any subsequent abort or continue action
Jobs can be set up at any time, but the commands within the job are not verified
until they are actually executed.
Creating and Scheduling Jobs

Creating a new job involves:
Creating the job, which includes the name and identification name.
Selecting which actions the job invokes.
Creating a schedule that determines when the job executes the actions.
Creating the Job and Selecting Actions

To create a job and select actions:
1. Select the Jobs tab.
2. From the Properties tab, select New in the lower right corner of the section. (If
you have not created any jobs, you can also click Please Click Here to create a
new Job.) The Create a New Job dialog displays.
88
3a
3b
3c
3. In the Properties tab, identify the job by entering a name in the Job Name field.
a. Name the job. Notice that the Job ID field mirrors the Job Name. You
can manually change this ID information; however, because the
Director CLI uses Job IDs to identify jobs, Blue Coat recommends
using the same string for the job name and job ID. You can change the
Job Name field at any time before you click OK; after you click OK, the
Job ID cannot be changed.
b. Enter a description for the job.
c. Enable is selected by default. Clear the Enable check box if you want
the scheduler to ignore this job for now.
89
4. Select the Actions tab to define the actions you want the job to execute.
Note: You can select the other tabs to add actions and a schedule without
clicking OK in the Profile tab first.
5. Click New.
6. From the Action drop-down list, select a task to be executed:

Push OverlayPush the overlay (specified in the Object field) to the
designated target device.
Refresh OverlayRefresh the overlay (specified in the Object field) from
the designated source device.
Push ProfilePush the profile (specified in the Object field) to the
designated target device.
Refresh ProfileRefresh the profile (specified in the Object field) from the
designated source device.
90
Abort on errorsAbort the job if any of the subsequent job actions fail.
Continue on errorsContinue job execution even when a job action fails.
Take BackupTake a backup of the target devices configuration.
Reboot DeviceReboot the target device.
Clear Devices Byte CacheClear the byte cache on the target appliance.
Clear Devices DNS CacheClear the DNS cache on the target appliance.
Clear Devices Object Cache Clear the object cache on the target
appliance.
System DownloadDownload a software version to the target appliance.
System ValidateValidate the software version on the target appliance.
Repeat to add more actions.
If you selected an Overlay or Profile action, proceed to Step 7. If you did not
select an Overlay or Profile action, proceed to Step 8.
7. If you selected an Overlay or Profile action in Step 6, new fields display.
a. From the Overlay or Profile drop-down list, select the profile or overlay
to be pushed to a target device or refreshed from another device or
location.
b. (Refresh action only) Select the refresh method:
Use Stored Source Information
From DeviceClick the browse (...) button, which displays the Choose
Target dialog. Select the device that contains the source overlay or
profile.
From Remote URLEnter the URL path to the server that contains the
source overlay or profile.
8. Select the target or source device for the action.
9. Click Apply. The action displays in the left section.
Note: You can select the Schedule tab without clicking OK in this tab first.
Scheduling a Job
To schedule a job:
1. Select the Schedule tab.
To schedule a one-time job or multiple jobs at irregular times, proceed to
Step 2.
To schedule a regularly occuring job, proceed to Step 3.
91
2. This step: schedule a job to execute one time or at multiple, irregular times.
For recurring scheduled times, proceed to Step 3.
a. Select This is a job to be executed on:.
b. From the drop-down lists, select the month, day, year, hour, minute,
and am or pm.
c. Click the plus (+) button to add the time.
d. (Optional) Repeat steps a
through c to add more times.
The times display in the List of
Dates/List of Times area on the
right side of the screen.
e. Click OK. Proceed to "About
Job Actions" on page 93.
92
3a
3b
3c 3e
3d
3. This step: schedule a recurring job.

a. Select This is a recurring job to execute on:
b. Select the days of the week for the job to execute.
c. Select the hours minutes and AM or PM.
d. Specify the start and end dates.
e. Click the plus (+) button to add the schedule to the List of Times,
located on the right side of the screen.
The job scheduler allows you to add multiple times with different
parameters. For example, you can add a new time that executes the job on
different days.
4. Click OK to save the job and return to the main job screen.
5. Verify that the job has been added to the Config Jobs section.
About Job Actions

Job actions are executed in the order in which they are added. Therefore, add your
actions in a logical order. For example, to push a profile and subsequently add an
overlay, you would add the following actions:
abort-on-errors
push profile (if this fails, the job halts)
continue-on-errors
push overlay (if this fails, job execution continues)
push overlay
93
After adding an action, you can change its place in the execution order by using
the Move Up and Move Down buttons.
Action Restrictions
The following restrictions apply to action creation:
You can have multiple overlay actions per job, but these must be added to the
job one action at a time.
You can assign only one profile action per job. If you add another profile
action to a job, the newer profile overwrites the existing profile for that job.
Executing a Job Immediately
You can execute any job immediately. Executing the job does not affect the next
scheduled running of the job. When you execute a backup job, for example, the
backup is taken regardless of schedule or job state (enabled or disabled).
To immediately execute a job:

2. In the All Jobs pane, highlight a job.
3. Click Execute.
4. Verify the job results by examining the job status in the Job Queue pane.
Verifying Job Execution

The Job Queue and Description sections of the Jobs tab display job execution
information:
A red X in the Status column of the Job Queue indicates that an error occurred
during execution.
A green check mark indicates that the job executed successfully.
A dash indicates that the job is scheduled but has not run yet.
The Description pane provides additional information, including a link to the Job
Report, which lists the CLI commands executed on the target object or device. You
can customize the job report output. The default is to show only errors. To see all
CLI output, you must set the output to verbose. See "Configuring the Browser and
Output Settings" on page 27.
To view job results:

94
2. Select a 3. Ciick to view execture

job. CLI commands.
2. In the Job Queue list, highlight the job. The page refreshes, displaying a job
execution summary.
3. Click View Job Report for a listing of the CLI commands that were executed.
The Job Report dialog displays.
Figure 4-1. The CLI commands executed in this job.
This job report shows an example of verbose output. For information about
setting the output level, see "Configuring the Browser and Output Settings" on
page 27.
4. Click Close to close the job report dialog.
Note: You can also open the Job Summary report from the Properties tab of
the Edit Job dialog.
95
Verifying Backup Jobs

Use the following procedure to view the results of a backup job.
To examine the result of a backup job:

1. Review the job status in the Job Queue to make sure the backup job executed
successfully.
2. Click the Configure tab.
3. Highlight the device you want to view the backup for. The device information
displays in the Description pane.
4. Click Launch Backup Manager. The Backup Manager displays.
5. Highlight the backup you want to view.
6. Click View Contents. The backup contents display in the right pane.
Editing Jobs
Use the following procedure to edit a jobs properties.
To edit a job:
1. Click the Jobs tab.
2. In the Job Library area, select the Configure or Content tab to display
3. Select a job.
4. Click Edit. (Or right click the job and select Edit.)
The Edit Job dialog displays, enabling you to make changes to the job
properties, actions, and scheduling, as shown in the following figure.
5. Edit settings.
See "Creating and Scheduling Jobs" on page 88 for information about the
Properties, Actions, and Schedule tabs.
6. Click OK to save your changes.
Note: You can also highlight the job and select Edit>Edit Job from the Edit
menu.
Deleting Jobs.
To delete a job:
1. Click the Jobs tab.
2. In the Job Library area, select the Configure or Content tab to display
3. Select a job.
4. Right click the job and select Delete.
96
Note: You can also highlight the job and select Edit > Delete from the Edit
menu.
Customizing the Job Queue View

The Job Queue lists the scheduled and recently-executed jobs. You cannot delete
jobs from the job queue; they are automatically rotated out. By default, Director
displays the last 10 executions of a job.
Use the Display Jobs next run time and Display Jobs that ran in the last n days (up
to 365) options at the bottom of the Job Queue area to customize the Job Queue
listing.
The Display Jobs next run time displays only one next run time per job.
Related CLI Syntax for Working with Jobs

Syntax for working with jobs in the CLI:
director (config) # job jobname
This changes the prompt to
director (config job jobname) #
Commands available from this submode include:
director (config job jobname) # cancel
director (config job jobname) # commands-type
director (config job jobname) # comment
director (config job jobname) # create
director (config job jobname) # date-time-pairs
director (config job jobname) # disable
director (config job jobname) # execute
director (config job jobname) # exit
director (config job jobname) # help
director (config job jobname) # input
director (config job jobname) # name
director (config job jobname) # no
director (config job jobname) # saved-executions
director (config job jobname) # shell
director (config job jobname) # show
director (config job jobname) # time-of-day
director (config job jobname) # type
Other related commands:
director (config) # job update-status
director (config) # abort-on-errors
97
Remotely Upgrading SG Appliance Software

You can use the Director Jobs feature to remotely upgrade or validate the SGOS
software on managed SG appliances. To upgrade the software on one or more SG
appliances, create a new job or add the upgrade actions to an existing job.
The following job actions can be set for software upgrade tasks:
System Download
Reboot Device
System Validation
Upgrade and Validation Notes

The following notes apply to SG appliance software upgrade and validation.
Back up the SG appliance configuration before performing any upgrade.
You do not have to download, reboot, and verify the software at one time. For
example, you can specify that an appliance download the software at 9 a.m.
and then reboot at 9 p.m. However, if the appliance reboots at any time after 9
a.m. and before 9 p.m., it will install the newly downloaded software.
You can also validate a system at any time. For example, if you have forgotten
what software versions a group is running, you can use the validate action.
Creating a Job to Upgrade SG Appliance Software

The following example assumes that you have already created a job as described
in the previous section "You can schedule any number of jobs to run at any time
and for any targets defined in Director. Additionally, you can apply conditional
operators to your jobs to ensure a certain job execution behavior, such as:" on page
88.
Important: Before performing any software upgrade, back up the appliance

configuration.
Creating a remote software upgrade job.

2. Select the job that you want to add the upgrade action to and click Edit. The
Edit Job dialog displays.
3. Select the Actions tab.
4. Click New to add an upgrade action.
98
5a
5b
5c
5. Configure the options:

a. In the Action drop-down, select System Download.
b. Enter the location of the software package in the From Remote URL
field.
Note: The SG appliance must be able to reach the specified URL.
c. Select the Target Device(s). The Choose Target dialog displays.
99
6. In the Choose Target dialog:

a. Select the groups or devices to receive the software download. (Use
CTRL+click to make multiple selections.)
b. Click OK to close the dialog.
c. Click Apply.
7. Add a Reboot Device action:
a. In the Edit Job dialog, select New.
b. In the Action drop-down list, select Reboot Device. Rebooting installs
the downloaded software.
c. Select the Target Device(s). The Choose Target dialog displays.
d. In the Choose Target dialog, select the groups or devices to be
rebooted. You must reselect the devices because there might be times
when you want to download software without installing it.
e. Click OK.
f. Click Apply to add the action to the job.
8. Add a System Validate action:
a. In the Edit Job dialog, select New to add the next action.
b. In the Action drop-down, select System Validate.
c. In the Version field, enter the version number to be validated.
The version number can be used to match releases, as shown in the
100
following table.
Version Number Matches
5.4.3 5.4.3, 5.4.3.1, 5.4.3.2, 5.4.3.3, etc.
5.4 All of the above plus:

5.4, 5.4.1, 5.4.1.3, etc.
5 All of the above plus:

5.1, 5.2, 5.1.1, 5.1.1.3, etc.
Do not precede the software version number with SGOS. Doing so results
in an error.
d. Select the Target Device(s). The Choose Target dialog displays.
e. In the Choose Target dialog, select the groups or devices to be
validated.
f. Click Apply to add the action to the job.
9. Click the Schedule tab to create a schedule for the job.
For instructions on creating a schedule, see "Scheduling a Job" on page 91.
10. Click OK to save the job and return to the main job pane.
11. Verify that the job has been added to the Job Queue.
The job will run per the configured schedule.
Related CLI Syntax for SG appliance remote software upgrade

SGME # remote-config download-system url url [device|group|addr-
device|all]
SGME # remote-config install-system [device|group|addr-device|all]
SGME # remote-config validate-system version version
[device|group|addr-device|all]
101
102
This chapter describes the options on the Content tab, which allow you to
distribute, or pre-populate, URL lists to target devices.
About Content Distribution

It is common that an enterprise employee, such an IT administrator, is tasked
with pushing content to one or more proxies on the network. Pre-population
usually occurs during off-peak hours to avoid clogging bandwidth pipes.
Furthermore, this reduces bandwidth resources during peak hours because
when users request the content during the next business day, the content is
already cached. Examples of mass-distributed content might be a video
message from the CEO and large information files, such as a PDF.
The IT administrator creates a URL list that contains the content URLs and
stores the list file locally. Blue Coat Director allows you to either instantly push
the URL list to target SG appliances or schedule a day and time when the push
occurs.
Legend
1: The IT admin creates a list of URLs to content objects stored on an internal Web server:
a video message from the CEO and the annual report PDF file.
2: The IT admin uses Director to create a new content job that calls the list stored on the IT
admins PC. The IT admin also creates a job schedule that execute the push at 12:01 am.
3: At 12:01 am, the SG appliances at headquarters and the branch office receive the
content URLs and request the content from the Web server.
4: The Web server sends the content to the SG appliances, which cache the objects.
5: The next morning, the companys users access the content locally from their respective
SG appliances.
Figure 51 Pre-populating process flow.
103
Distributing URL Lists

This section describes the tasks involved in pre-populating content to SG
appliances.
To pre-populate content:
1. Verify the content to be pushed is accessible; note the path to the content.
2. Create a content object URL list in a file, with only one entry per line. For
example:
https://example.com/IT/content/CEOvideo0707.qt
https://example.com/IT/content/07annualreport.pdf
The file can be a text file or an HTML file. Save the file on your PC. For
example:
C:\adminpc\contentfiles\CEOpush07.txt
3. In Blue Coat Director, click the Content tab.

4. In the Content collections area, click URL Lists or Regex Lists as required.
5. At the bottom of the area, click New (if there currently are no other lists
created, URL Lists or Regex Lists areas provide a Click here link). The
Create URL List dialog displays.
6. Specify the job attributes:

a. In the URL List Name field, enter a name that easily identifies the
purpose of the push. By default, the URL List ID mirrors the URL
List Name, but you can manually change this name if desired.
b. (Optional) Enter a more detailed task description.
104
7a
7b
7c
7. Specify the list source:

a. If you are retrieving the URL list from a locally stored file, select
Import from local and enter the path (or click Browse and navigate to
the location).
-or-
b. If you are retrieving the URL list from an HTML file, select Import
from URL and enter the URL path.
c. The When importing entries options apply if you are editing a
previously existing URL list (on Director):
Append imported entries to list: The lists from the file or HTML are
added the existing URL list.
Replace list with imported entries: The lists from the file or HTML
replace the existing URL list.
d. Click Import. Director performs validation on the list, then area on
the right side of the dialog displays the imported URLs. An error is
displayed if the URLs are not valid. Fix them in file and perform this
step again (a common error is more than one entry per line).
Figure 5-1. The imported URLs.
e. Click OK to close the Create URL List dialog. The Content

collections area on the Content tab displays the new object.
105
8a
8b
8. The final step is to distribute the URL list to either a single SG appliance or
a group (you cannot distribute the lists to one or more standalone devices in
a single operation). There are two methods to accomplish this: manual and
scheduled.
a. In the Groups area, select a group (or select a single appliance from
the Devices area).
b. Click Apply. The Perform URL List Action dialog displays.
106
9a
9b
9c
9. Specify the actions:

a. From the Action drop-down list, select Distribute URLs.
b. Select Apply content as an immediate action to push the list without
job tracking. This option is designed for users who do not have
permissions to create jobs. Also, if you are distributing the URL list
one time only and you do not want to add too many jobs to your list.
-or-
c. Select Apply content as a job to enable job tracking. In the Job Name
field, accept the numerical default or enter a name to describe the
job (recommended for tracking purposes).
Select Execute now for an immediate push or use the month, day, year,
hour, minute, and am/pm drop-down lists to schedule a time to push
the lists.
d. Click OK.
All objects that appear in the Content collection area on the Content tab are
selectable on the Jobs tab. You can create a recurring schedule to push content,
which means you can use the same job and just replace the URL lists. For
detailed information about scheduling jobs, see Chapter 4: "Configuring Jobs"
on page 87.
Related CLI Syntax
107
Validating URLs or Regular Expressions

Director allows you to verify the content on the target caches to determine if it
is fresh or if a new version exists on the server. If newer content is available, it is
automatically fetched and cached. The validation operation supports URLs and
regex lists.
Similar to the URL list file you created as described in "Distributing URL Lists"
on page 104, you can create a text file that contains a list of regular expressions
(regexes). Regex lists can only be used to revalidate, delete or prioritize content
that is already in the cache; content distribution does not support regex lists.
For example, create a regex list to validate all PDF and Windows Media files:
https://example.com/IT/content/*pdf
https://example.com/IT/content/*wm
To validate URLs or regular expressions

1. In the Director Management Console, click the Jobs tab.
2. Select the content job that contains the URLs to verify:
a. In the Job Library area, click the Content tab.
b. Select the Content job.
c. Click New. The Create a New Job dialog displays.
3. In the Properties tab, name the job. For example: CEO_Message_verify.
4. Create the job:
a. Click the Actions tab.
b. Click New.
c. From the Action drop-down list, select Revalidate URL(s) or
Revalidate Regex(es).
d. Select the URLs or regexes to validate:
From a URL list: select a list you created from the Content tab.
From a remote URL: use a list that exists in an HTML file.
Single URL: enter a URL to test.
e. Select one or more target devices. Click the browse (...) button to
display a list of devices.
f. Click Apply to move the job to the list of actions.
5. Click the Schedule tab and specify when the verification occurs. See
"Creating and Scheduling Jobs" on page 88 for more information about the
scheduler.
6. Click OK to close the dialog.
108
Reviewing Validation Results

To verify the freshness status of cached URLs, perform a content query (see
"Querying URLs" on page 110). For greater details, performing a query from the
CLI allows you to view timestamp information.
Prioritizing URLs and Regular Expression Jobs

If you have scheduled Director to send multiple jobs to target network devices,
you can prioritize job actions by assigning them a numerical value. The lowest
number receives the highest priority.
To set priority status for URL and regex jobs:

1. In the Director Management Console, click the Jobs tab.
a. In the Job Library area, click the Content tab.
b. Select the content job.
c. Click New. The Create a New Job dialog displays.
3. In the Properties tab, name the job. For example: CEO_URLs_priority.
4. Create the job:
a. Click the Actions tab.
b. Click New.
4c
4d
c. From the Action drop-down list, select Prioritize URL(s) or Prioritize

Regex(es). The Priority drop-down option list appears.
d. Select the URL source. You can select a list or a single URL
109
e. From the Priority drop-down list, select a priority. Zero (0) assigns
the job the highest priority; seven is the lowest. In this example, the
CEO broadcast is assign the highest priority to ensure availability.
f. Select one or more target devices. Click the browse (...) button to
display a list of devices.
g. Click Apply.
5. Click the Schedule tab and specify when the verification occurs. See
"Creating and Scheduling Jobs" on page 88 for more information about the
scheduler.
6. Click OK to close the dialog.
Querying URLs
Querying URLs allows you to verify the status of contentwhether it is cached
or not and URLs currently in progress.
To query URLs for cached status:

1. In the Director Management Console, click the Content tab.
a. In the Content Collections area, click the URL Lists tab.
b. Select the URL list to query.
110
3. In the lower left corner of Director, click Query Selection.

4. After the query completes, the Show Results button becomes active. Click
to view.
Note: During the query operation, the Show Results button changes to
the Cancel Query button. Clicking Cancel Query does not halt Director
from processing the query, but it does allow you to submit a new query.
Figure 5-2. Query results dialog.
In this example, the results show no cached content. The push content job
has not yet occurred.
111
Note: Percent values are rounded up (decimal values are not

supported). For example, if you used a 30K URL-list and 10 URLs are not
in the cache, the percent shown for in cache is 100%.
5. For each category that Director registers results, the View/Export button
displays. In this example, the two URLs in the content job were not detected
in the SG appliance cache. Click to display more detailed results.
Figure 5-3. Detailed URL results.
The options at the bottom of the dialog allow you to perform different
actions using this result set.
6. To export the results, select a format:

Export: Saves the list to a Director-compatible file in a local directory of
your selection (the default is the Director-MC directory).
Save: Saves the list as a new content list. This might be useful for a set of
successful taken from a larger set mixed with unsuccessful URLs.
Distribute: Saves list as a new content list and immediately distribute the list to
the target device selected when the Query and Show Results buttons were
clicked on the main page.
7. Click Close.
Related CLI Commands

The following equivalent content CLI commands are available:
(config) content
The following sub-modes are available:
112
(config) content url-list name create

(config) content regex-list name create
(config) content priority one-time value (0 to 7)
(config) content distribute {url | url-list | urls-from}
(config) content revalidate {regex | regex-list | regexes-from | url
| url-list | urls-from}
(config) content query {command | in-progress | info | liveness |
outstanding | priority | status}
(config) content delete {regex | regex-list | regexes-from | url |
url-list | urls-from}
113
114
This chapter describes the options on the Monitoring tab and how to use them
to view device status.
"About the Monitoring Tab" on page 115
"Viewing Group and Device Status" on page 116
"Viewing Alerts" on page 118
"Viewing Statistics" on page 121
About the Monitoring Tab

After you have added devices, you can view device status in the Monitoring
tab.
Figure 61 Director Monitoring Tab
115
DocTitle
The Monitoring tab enables you to quickly determine the status of groups or of
individual devices. The Monitoring tab provides a quick, global view of the health
of your devices by listing the total number of alerts for all devices and providing a
summary of device health for those systems. It also enables you to access alert and
statistics information.
Viewing Group and Device Status

The Groups field lists all of the groups you have created, as well as the All and
Unassigned System Groups. When a group is selected, the groups overall status
is displayed. When a device is selected, its individual status and alerts summary
is displayed in the Description pane.
To view group status:

To view the status of a particular group from the Monitor tab, select it. When
selected, the group status displays in the Description area, as shown in the
following figure.
Figure 62 Viewing Group Status
To view device status:

1. Select the Monitoring tab.
2. From the Group field, select the group that contains the device. The list of
group members displays in the Devices field.
3. Select the device for which you want to view status.
The device status displays in the Description field, as shown in the following
figure.
116
Figure 63 Viewing Device Status

The device information contains additional status information not displayed in
the group status, such as health statistics. See Chapter 8: "Monitoring the Health
of Devices" for more information about device health statistics.
To view device model:

You can also view the model or edition of a device. The device edition can be
either a proxy or MACH5. Scroll toward the bottom of the Description field to
display the device Edition metric.
117
DocTitle
Figure 64 Viewing Device Edition
Viewing Alerts
Alerts apprise you of specific device events, such as fan failures or CPU utilization
warnings. Director fetches the device status as reported in the system resource
metrics XML; when a change is detected, Director records the change as an alert.
Director records a maximum of 5000 alerts. If the 5000 alert limit is reached, the
oldest alerts are overwritten by new alerts.
For monitoring purposes, an alert can be active or inactive. An active alert is an in-
progress event that requires immediate attention. Inactive alerts are alerts that
have occurred but that have since returned to a normal condition and no longer
require attention.
The Monitoring tab displays an overall picture of the total amount of alerts for all
devices, grouped devices, and individual devices. To view the list of alerts for
All devices: The status box at the top of the Monitoring page provides a
summary of the total events for all devices.
A group of devices: Select the group name.
An individual device: Select the device name.
Managing Alerts
The Alerts window enables you to view all of the alerts for the selected device or
group and allows you to comment on and acknowledge those alerts.
To manage alerts
1. From the Monitoring tab, select a device or group of devices.
118
2. Click Alerts. The Alerts window displays.
3a
3b
3c
3d
3. (Optional) Customize the alert view. The default view lists only the active
alerts.
a. Deselect Show only active alerts to see all active and inactive alerts.
b. Select a historical view from the dropdown menu. The following views
are available:
119
DocTitle
In the past 30 days

In the past 15 days
In the past 7 days
In the past 1 day
c. Sort the view by clicking a table column heading.
d. Select an alert. Information about the selected alert displays in the
lower pane.
Note: You can select multiple alerts by selecting CTRL+right click,

SHIFT+right click, or by clicking Select All.
4. (Optional) Enter a comment in the Comments field and click Update.

5. (Optional) Click Acknowledge to acknowledge the alert. The flag in the
Acknowledged column turns green to note that the alert has been
acknowledged.
Acknowledging an alert makes the alert a candidate for deletion when the
maximum number of alerts is reached.
Note: To acknowledge multiple alerts, select the alerts and click

Acknowledge.
6. (Optional) Click Delete to delete the selected alerts.

7. Click OK to close the Alerts dialog.
120
Viewing Statistics
The Manage Device page enables you to view the alerts and statistics for
individual devices. When you click the Statistics button, an instance of that
devices SG appliance Management Console Statistics tab is displayed for your
review. The Alerts tab enables you to switch back and forth between alert and
statistics information to obtain additional details.
Note: Unlike alerts, statistics can be viewed only for individual devices.
To view device statistics:

1. From the Devices field in the Monitoring tab, select a device.
2. Click Statistics. The Manage Device window displays, with the Management
Console of the selected device in view.
121
DocTitle
3. Select a statistic to view.

4. (Optional) Click the Health: field status hyperlink to navigate to the Health
statistics.
5. (Optional) Select the Alerts tab to review alert information.
Note: You can make configuration changes only to devices from the
Configure tab.
122
This chapter describes the Director administrator activity logging feature. The
Director administrator activity logging feature enables you to pinpoint the
actions of all administrators performing tasks on Director. This can be useful if
you need to document Director administrator behavior for change
management auditing or troubleshooting. The auditing feature includes
Authentication using TACACS+
Logging of all actions performed by a user
Export of the generated log entries in real time to a syslog server
Important: Only TACACS+ authentication is supported. Authorization is not

supported.

"About Administrator Activity Logging" on page 123
"Configuring Administrator Activity Logging" on page 124
"Audit Logging Details" on page 125
About Administrator Activity Logging

When a user performs an action in the Director GUI, the GUI issues CLI
commands to execute the user action. All the commands executed by the user
action are logged in the event log on Director. If a command returns an error,
the error message is logged. Because Director does not give a success
confirmation, all other commands are assumed to have succeeded.
The event log message includes the following:

The command that was executed
The user name of the person who executed the command
The IP address from which the command was executed
For example:
Jun 23 22:37:57 <cli.notice_minor> hostname cli[1287]:
admin@0.0.0.0: Processing command: remote-config overlay new_overlay
execute device 0.0.0.1
You can also configure the logs to be exported to a syslog server.
Note: See Chapter 10: "Director Logging" for information about how event log
entries are created.
123
Configuring Administrator Activity Logging

To enable administrator activity logging, you must:
Enable TACACS+ authentication.
Set the logging level to notice_minor.
Configure the syslog daemon (to export the log messages to a syslog server).
Enabling TACACS+ Authentication

You must configure TACACS+ from the Director CLI. To enable TACACS+, you
must configure TACACS+ server communication and then enable TACACS+ user
authentication.
To configure TACACS+ communication:

1. Configure the TACACS+ server and port:
Director (config)# tacacs-server host hostname port port_number
2. Set the key for host communication:

Director (config)# tacacs-server key shared_secret
3. Set the communication timeout:

Director (config)# tacacs-server timeout timeout
To enable TACACS+ authentication:

The following command configures Director to authenticate a user using
TACACS+, followed by the local UNIX password file. The username and
password is picked from the TACACS+ database if the authentication scheme is
TACACS+.
Director (config)# aaa authentication login default tacacs+ local
Since Director supports authentication using RADIUS/TACACS+, the remote
usernames do not need to be configured on Director. Usernames and passwords
for remote users, however, are restricted to 16 bytes. If the username is longer, the
authentication/login attempt fails.
Setting the Logging Level

To use the auditing feature, you must set the logging level to notice_minor:
Director (config)# logging local notice_minor
If you intend to send logging information to a syslog server:

Director (config)# logging trap notice_minor
See Chapter 10: "Director Logging" for more information about setting logging
levels.
Configuring Syslog
If you want user actions to be logged to a remote syslog server and to the Director
message log, you must configure the system log daemon (syslogd).
124
To send logged actions to a syslog server:

Director (config)# logging external_serverIP_or_hostname
Viewing the log

To view the log from the Director CLI, enter the following command:
Director # show syslog
Audit Logging Details

This section describes the log details for profiles, overlays, backups, and jobs.
Profile/Overlay/Backup Logging
Profile, overlay, and backup commands are logged in the order they are executed
on various devices. The event log message includes the following:
Username of the person executing the command
The IP address of the user's computer
The name of the Overlay/Profile/Backup
All the event log messages for command execution are bracketed by a start and an
end event log message that includes the name of the overlay, profile, or backup
and the device ID on which the command is executed.
The following example shows the logged results of an Overlay execution.
admin@10.2.11.90: Processing command: remote-config overlay
new_overlay-1151102100: execute device 10.9.44.38
Jun 23 22:37:57 <configd.notice_minor> hostname configd:
admin@10.2.11.90: new_overlay-1151102100: Applying overlay
<new_overlay> to cache 10.9.44.38
admin@10.2.11.90: new_overlay-1151102100: command 1: show version
admin@10.2.11.90:new_overlay-1151102100: command 2: show clock
Jun 23 22:37:57 <configd.notice> director configd: admin@10.2.11.90:
new_overlay-1151102100: Overlay push complete for device "10.9.44.38"
The overlay in the preceding example has the following properties.
Property Example Value
Overlay Name new_overlay
Overlay Execution Instance 1151102100
Director Host Name hostname
Director IP Address directorIP
Username admin
User IP Address 10.2.11.90
125
Job Logging
Job creation and edit commands are logged with the user name and IP address.
All Job executions, on the other hand, are logged with the username director.
However, if a job is executed immediately, the executed command is logged with
the username and IP address.
The event log messages for all job commands are printed as they are executed.
These event log messages include the following:
Job ID
Instance ID
The instance ID is used to distinguish one execution of a recurring job from
another.
Username of the person executing the command
The IP address of the user's computer
The following example shows the logged results of an immediate job execution
admin@10.2.11.90: Processing command: job ab execute (Note: This
message will only be there for an immediate Job)
Jun 23 22:35:00 <schedulerd.notice_minor> hostname schedulerd:
sched@director Executing Job "ab" execution 1151102100
Jun 23 22:35:00 <runner.notice_minor> hostname runner[1288]:
sched@director:ab-1151102100: Processing command: remote-config
profile ab execute device 10.9.44.38
sched@director: ab-1151102100: Applying profile <pab> to cache
10.9.44.38
Jun 23 22:35:00 <runner.warn> hostname runner[1288]: sched@director:
ab-1151102100: command 1: "remote-config profile ab execute device
10.9.44.38". Output 1/1:\#% No commands to execute.\# (Note: Only the
error messages will be shown)
sched@director: ab-1151102100: Applying overlay <new_overlay> to group
g
Jun 23 23:15:07 <configd.notice> hostname configd: sched@director: ab-
1151102100: Overlay push start for device "10.2.11.211"
sched@director: ab-1151102100: command 1: show version
1151102100: Overlay push complete for device "10.2.11.211"
1151102100: Overlay push start for device "10.9.44.38"
sched@director: ab-1151102100: command 1: show version
1151102100: Overlay push complete for device "10.9.44.38"
Jun 23 23:15:07 <runner.notice> hostname runner[1517]: sched@director:
ab-1151102100: Job "ab" execution 1151104506 finished running.
The job execution in the preceding example has the following properties:
126
Property Example Value
Job ID ab
Job Instance 1151102100
Director Host Name hostname
Director IP Address directorIP
Username admin
127
128
This chapter describes the Director health monitoring feature. The health
monitoring feature enables you to use Director to remotely monitor your SG
appliances. By monitoring key hardware and software metrics, Director
provides administrators with a remote view of the health of the SG appliance.
This chapter also describes how to configure Director to send traps to a remote
management station when it fails or comes online.
"About Health Monitoring" on page 130
"SG Appliance Health Monitoring Requirements" on page 130
"About the Health Monitoring Metrics" on page 131
"About Device Polling" on page 131
"Health Monitoring Example" on page 132
"About the Health Monitoring Device States" on page 133
"About Health Monitoring Notification" on page 136
"About the Health Monitoring Device States" on page 133
"Changing Threshold and Notification Properties" on page 138
"Getting A Quick View of the SG Appliance Health" on page 140
"Viewing Health Monitoring Statistics" on page 141
"Configuring Director to Notify Remote Management Stations of SG
Appliance State Changes" on page 143
"Troubleshooting" on page 145
129
About Health Monitoring

The health monitoring feature enables Director (and other third-party network
management tools) to remotely display the current state of all SG appliances
monitored by it. By monitoring key hardware and software metrics, Director can
display a variety of health-related statisticsand trigger notification if action is
required.
Figure 8-1. Health Monitoring Configuration and Notification Process

As shown in the preceding figure, the health monitoring metrics can be remotely
queried from Director. The metrics are also configurable on the SG appliance
itself.
SG Appliance Health Monitoring Requirements

Before using the health monitoring feature, you should ensure that the e-mail
addresses of all persons that should be notified of health monitoring alerts are
listed in the Event log properties of the SG appliance.
Note: SGME 5.1.4.x and later ignores SNMP traps sent to it by SG appliances.
If you want to configure e-mail notification for individual alert types, the
notification settings for the alert must be set on each SG appliance. To set
notification properties for specific alerts on multiple devices, create a profile or
overlay that contains the settings you want and then apply the settings to your
devices. See "Configuring and Managing Devices" on page 37 for more
information.
130
About the Health Monitoring Metrics

Health Monitoring allows you to set notification thresholds on various internal
metrics that track the health of a monitored system or device. Each metric has a
value and a state.
The value is obtained by periodically measuring the monitored system or device.
In some cases, the value is a percentage or a temperature measurement; in other
cases, it is a status like "Disk Present" or "Awaiting Approval".
The state indicates the severity of the metric as a health issue:
OKThe monitored system or device is behaving normally.
WARNINGThe monitored system or device is outside typical operating
parameters and may require attention.
CRITICALThe monitored system or device is either failing, or is far outside
normal parameters, and requires immediate attention.
The current state of a metric is determined by the relationship between the value
and its monitoring thresholds. The Warning and Critical states have thresholds,
and each threshold has a corresponding interval.
All metrics begin in the OK state. If the value crosses the Warning threshold and
remains there for the threshold's specified interval, the metric transitions to the
Warning state. Similarly, if the Critical threshold is exceeded for the specified
interval, the metric transitions to the Critical state. Later (for example, if the
problem is resolved), the value may drop back down below the Warning
threshold. If the value stays below the Warning threshold longer than the
specified interval, the state returns to OK.
Every time the state changes, a notification occurs. If the value fluctuates above
and below a threshold, no state change occurs until the value stays above or
below the threshold for the specified interval.
This behavior helps to ensure that unwarranted notifications are avoided when
values vary widely without having any definite trend. You can experiment with
the thresholds and intervals until you are comfortable with the sensitivity of the
notification settings.
About Device Polling

Starting with SGME 5.1.4, Director no longer uses SNMP traps to determine if the
SG appliance health state has changed. To ensure that the appliance state is
accurately displayed, Director polls all managed devices approximately every
minute to determine if the system-resource-metrics XML data has changed since
the last polling. Director retrieves the updated system-resource-metrics XML
only when a device state has changed, thus reducing the bandwidth load on the
network.
Note: You can initiate an immediate device poll by clicking Refresh in the Health
Statistics field of the Monitoring tab Description pane. For more information, see
"About the Health Monitoring Device States" on page 133.
131
Polling can be slower for SG appliances running SGOS releases prior to SGOS
5.1.4 or SGOS 4.2.4 because the entire system-resource-metrics XML is fetched
every minute, not just when a change has occurred. To ensure rapid polling, Blue
Coat recommends that you upgrade to SGOS 5.1.4.x or later or SGOS 4.2.4 or later
(when available).
Note: If you enable Director Dashboard, you must either reconnect to all devices
or reboot Director so that it will discover the system resource metrics of devices
running SGOS 4.2.3.7 or later. See "About the Director Dashboard" on page 17 for
more information.
Health Monitoring Example

The following picture shows an example. The lower horizontal line represents the
Warning threshold; the upper horizontal line is the Critical threshold. Note how
they divide the graph into bands associated with each of the three possible states.
Assume both thresholds have intervals of 20 seconds, and that the metric is
currently in the OK state.
1. At time 0, the monitored value crosses the Warning threshold. No transition
occurs yet. Later, at time 10, it crosses the critical threshold. Still, no state
change occurs, because the threshold interval has not elapsed.
2. At time 20, the value has been above the warning threshold for 20 seconds--
the specified interval. The state of the metric now changes to Warning, and a
notification is sent. Note that even though the metric is currently in the critical
range, the State is still Warning, because the value has not exceeded the
Critical threshold long enough to trigger a transition to Critical.
3. At time 25, the value drops below the Critical threshold, having been above it
for only 15 seconds. The state remains at Warning.
4. At time 30, it drops below the Warning threshold. Again the state does not
change. If the value remains below the warning threshold until time 50, then
the state will change back to OK.
132
20 seconds above the Warning threshold a Warning notification is sent
CRITICAL
WARRNING
OK
Value
0 5 10 15 20 25 30 35 40 45 50 55 60
Time
Figure 81 Relationship between the threshold value and threshold interval
About License Expiration Metrics

The threshold values for license expiration metrics are set in days until expiration.
In this context, a "critical" threshold indicates that license expiration is imminent.
This is the only configurable metric in which the Critical threshold value should
be smaller than the Warning threshold value. For example, if you set the Warning
threshold to 45, an alert is sent when there are 45 days remaining in the license
period. The Critical threshold would be less than 45 days, for example 5 days.
For the license expiration metrics, the threshold interval is irrelevant and is set by
default to 0. You should set the Warning Threshold to a value that will give you
ample time to renew your license. By default, all license expiration metrics have a
Warning Threshold of 30 days. By default, the Critical Threshold is configured to
0, which means that a trap is immediately sent upon license expiration.
About the Health Monitoring Device States

The following table describes the possible health monitoring device states and
provides a corresponding description.
Note: You can configure Director to send end device status updates to a third-
party management station. See Configuring Director to Notify Remote
Management Stations of SG Appliance State Changes on page 143 for more
information.
133
Table 81 Director States and Descriptions
Device State Description
OK The SG appliance is functioning normally. When this trap is sent,

it indicates that the SG appliance is again functioning normally.
All prior conditions that caused it to be in another state have
ceased.
Warning The SG appliance has one or more events that are causing it to be
in a Warning state. Note that if additional warning-level event(s)
occur, they do not cause additional traps; (however a new critical-
level event would generate a Critical trap).
Critical The SG appliance has one or more events that are causing it to be
in a Critical state. Note that if additional event(s) occur, they do
not cause additional traps, (unless such events cause the
appliance to move from state Warning to state Critical).
Connected The SG appliance is reachable through SSH from Director. This is

the normal state of SG appliances that do not support the Health
Monitoring XML.
Disconnected The SG appliance is no longer reachable via SSH connection from

Director.
About the General Metrics

The following table lists the metrics displayed in the Maintenance > Health Monitoring >
General page. The thresholds for these metrics are user-configurable. See "About Health
Monitoring" on page 130 for information about thresholds and alert notification.
All threshold intervals are in seconds.
Table 8-2. General Health Monitoring Metrics
Metric Units Default Notes

Thresholds/Intervals
CPU Utilization Percentage Critical: 95%/120 seconds Measures the value of CPU 0
Warning: 80%/120 on multi-processor systems--
seconds not the average of all CPU
activity.
Memory Pressure Percentage Critical: 95%/120 seconds Memory pressure occurs

Warning: 90%/120 when memory resources
seconds become limited, causing new
connections to be delayed.
Interface Utilization Percentage Critical: 90%/120 seconds Measures the traffic (in and
Warning: 60%/120 out) on the interface to
seconds determine if it is
approaching the bandwidth
maximum.
134
About the Licensing Metrics

Licensing page. You can monitor User License utilization metrics and the following license
expiration metrics:
SGOS Base License: Licenses not listed here are part of the SGOS base license.
SSL Proxy
SG Client
See "About the Licensing Metrics" on page 135 for information licensing thresholds.
Metric Units Default Notes

Thresholds/Intervals
License Utilization Percentage Critical: 100%/0 For licenses that have user
Warning: 90%/0 limits, monitors the number
of users.
License Expiration Days Critical: 0 days/0 Warns of impending license

Warning: 30 days/0 expiration.
For license expiration
metrics, intervals are
ignored. See "About the
Licensing Metrics" on page
135 for more information.
About the Status Metrics

Status page. The thresholds for these metrics are not user-configurable.
Table 8-3. Status Health Monitoring Metrics
Metric Threshold States and Corresponding

Values
Disk status Critical:

Bad
Warning:
Removed
Offline
OK:
Not Present
Present
Temperature Critical:
Bus temperature High-critical
CPU temperature Warning:
High-warning
135
Table 8-3. Status Health Monitoring Metrics (Continued)
Fan Critical:
(The fan metric differs by hardware model, for Low-critical
example, CPU fan, chassis fan) Warning:
Low-warning
Voltage Critical:
Bus Voltage Critical
CPU voltage High-critical
Power Supply voltage
Low-critical
Warning:
High-warning
Low-warning
ADN Connection Status OK:

Connected
Connecting
Connection Approved
Disabled
Not Operational
Warning:
Approval Pending
Mismatching Approval Status
Partially Connected
Critical:
Not Connected
Connection Rejected
See Volume 5: Advanced Networking for
more information about the ADN
metrics.
ADN Manager Status OK:

No Approvals Pending
Not Applicable
Warning:
Approvals Pending
About Health Monitoring Notification

By default, the Director polls the SG appliances to determine their current state. If
the state has changed, Director updates the device status. Other types of
notification are also available. Any or all of the following types of notification can
be set:
SNMP trap
Sends an SNMP trap to all configured management stations.
E-mail
Sends e-mail to all persons listed in the Event log properties on the SG.
136
Log
Inserts an entry into the Event log on the SG.
Viewing a Devices Health Monitoring Metrics

Using Director, you can view the overall health of a device and specifics about the
state of its hardware, environmentals, and system resources.
See "About the General Metrics" on page 134 and "About the Status Metrics" on
page 135 for a description of these metrics.
To view a devices health monitoring metrics:

1. Select the Monitoring tab.
2. From the Group field, select the group that contains the device. The list of
group members displays in the Devices field.
3. From the Devices field, select the device whose status you want to view.
The Health Statistics display in the Description field, as shown in the
following figure.
Figure 84 Displaying health statistics.
4. Review the current state of the metric.

The icon next to each health statistic indicates the current state of the metric:
green indicates OK, gold indicates Warning, and red indicates Critical.
137
Note: To avoid losing one hours worth of alerts when the SG clock is set back
during daylight savings time, manually refresh the health statistics after the SG
clock is reset.
5. (Optional) Click Refresh to update the health statistics.

Clicking Refresh initiates an immediate polling of the selected device.
Changing Threshold and Notification Properties

The health monitoring threshold and notification properties are set by default.
Use the following procedure to modify the current settings.
To change the SG threshold and notification properties:

1. Navigate to the Configure tab in the Director Management Console.
2: Right-click and
select Configure.
2. Right-click the device to configure and click Configure. The Manage Device
window displays. This window replicates the SG Management Console of the
device.
138
4: Select a tab.
3. In the Manage Device window, select Maintenance > Health Monitoring.

4. Perform one of the following:
To change the system resource metrics, select General.
To change the hardware/environmental metrics, select Status.
Note: You cannot change the threshold values for metrics from the
Status tab.
To change the licensing metrics, select Licensing.
5. Select the metric to modify.

6. Click Edit to modify the threshold and notification settings. The Edit Metric
dialog displays. (Sensor thresholds cannot be modified.)
139
7: Modify threshold
values.
8: Modify notification
settings.
7. Modify the threshold values.

8. Modify the notification settings.
Log adds an entry to the Event log.
Trap sends an SNMP trap to all configured management stations.
Email sends an e-mail to the addresses listed in the Event log properties.
9. Click OK to close the Edit Metric dialog.
10. Click Apply.
Related SG CLI Syntax for Modifying Threshold and Notification Properties

#(config) alert threshold metric_name warning_threshold
warning_interval critical_threshold critical_interval
#(config) alert notification metric_name notification_method
Getting A Quick View of the SG Appliance Health

The Management Console uses the health monitoring metrics to display a visual
representation of the overall health state of the SG. The health icon is located in
the upper right corner of the SG Management Console and is always visible.
The health icon is also displayed in Director Management Console Monitor and
Configure tabs (for a device or group). When you highlight a device in the Monitor
page and click Statistics, the icon is displayed at the top left corner of the Manage
Device dialog.
140
System health is determined by calculating the aggregate health status of the

following metrics:
CPU Utilization
Memory Pressure
Network interface utilization
Disk status (for all disks)
License expiration
License user count usage (when applicable)
Sensor values (for all sensors)
The possible SG appliance health states are OK, Warning, or Critical.
Clicking the health icon displays the SG appliance Statistics > Health page, which
lists the current condition of the systems health monitoring metrics, as described
in the next section.
Viewing Health Monitoring Statistics

While the health icon presents a quick view of SG health, the Statistics > Health
page enables you to get more details about the current state of the SG health
monitoring metrics.
To review the health monitoring statistics:

1. Navigate to the Configure tab in the Director Management Console.
2. Select the device you want to configure.
3. Click Configure Device. The Manage Device window displays. This window
replicates the SG appliance Management Console of the device.
4. In the Manage Device window, select Statistics > Health.
141
5. Select a health monitoring statistics tab:

General: Lists the current state of CPU utilization, interface utilization, memory
pressure, and disk status metrics.
Licenses: Lists the current state of license utilization and expiration metrics.
Sensors: Lists the current state of all sensor metrics.
6. To get more details about a metric, highlight the metric and click View. The
View Metrics Detail dialog displays.
142
7. Click Close to close the View Metrics Detail dialog.

8. OptionalTo modify a metric, highlight the metric and click Set Thresholds.
The Maintenance > Health Monitoring page displays. To modify the metric,
follow the procedure describe in " Changing Threshold and Notification
Properties".
Related SG CLI Syntax for Viewing Health Monitoring Statistics

SGOS#(config) show system-resource-metrics
The show system-resource-metrics command lists the state of the current system
resource metrics.
Sensor notification varies by SG platform. If you try to set notification for a sensor
that does not support notification, you will see the following error message:
Sensor not supported on this platform
Depending on the SG platform, the sensor metrics displayed by the show system-
resource-metrics command might differ from the sensor names listed in the
alert command output. For example, the bus-temperature sensor can be shown
as motherboard temperature in the show system-resources-metrics output. If you
are setting notification from the Management Console, you can verify the sensor
category by clicking the Preview button to view the CLI output.
Configuring Director to Notify Remote Management Stations of SG

Appliance State Changes
Though Director displays the status of all managed devices, it can be helpful to
configure Director to send status updates to a third-party management station
like HP OpenView.
While you can configure your SG appliances to send SNMP notifications directly
to the management station, there is no guarantee that such a notification would be
sent if the SG appliance is failing or is unreachable because a router between the
data center and that appliance has failed.
143
Instead, Director can be used to send such notifications, since it polls the state of
each managed SG appliance every minute. When you enable this feature, Director
sends a notification to all configured hosts whenever an SG appliance state
change is detected. Only one notification is sent when a device enters a new state.
The notifications correspond to the following health monitoring states:
Ok
Warning
Critical
Connected
Disconnected
These health monitoring states are described in Table 81 on page 134.
Additionally, a single notification is sent if either of the following events occur
(these events are always initiated by an administrator):
[SG] Added
An administrator has added the SG appliance to Director's list of known
devices.
[SG] Deleted
A administrator has deleted the SG appliance from Director's list of known
devices.
Note: Blue Coat provides a MIB defining the SG appliance state-change

notifications. The MIB is written in SMI v2 and matches all of the SNMP v2c
notifications sent by Director. Director also supports the sending of SNMP v1
traps, but no SMI v1 MIB is provided (many converters are available on the
Internet). Blue Coat recommends using SNMP v2 notifications rather than SNMP
v1 traps.
To enable Director to send SNMP notifications for SG appliance state changes:
Note: The snmp-server enable traps command does not need to be executed to
enable the SG appliance state notification feature. However, you must enable the
notifications as described in the following procedure.
1. Enter the following command to specify the remote management station as an

SNMP trap recipient:
director (config) # snmp-server host hostname inform community string
2. Enter the following command to specify the SNMP trap version:

director (config) # snmp-server host hostname traps version 1|2c
community string
3. Enter the following command to enable all device state SNMP notifications:
director (config) # snmp-server traps device-state all enable
144
The device-state notifications can also be enabled individually:

device-state added
device-state deleted
device-state connected
device-state disconnected
device-state ok
device-state warning
device-state critical
device-state auto-registered
device-state auto-registered-failed
For example:
director (config) # snmp-server traps device-state connected enable
Verifying SNMP Trap Receipt

To verify that your network and management station are properly configured to
receive device-state SNMP notifications from Director, use the monitoring
diagnose device-state state commands. These commands force Director to
send the specified SNMP notification. To receive a listing of the available
diagnostic notifications, enter the following command:
director (config) # monitoring diagnose device-state ?
When these traps are sent, the var-binds in the body of the trap have the following
fixed values (the values cannot be specified or overwritten):
sgHostname = "0.0.0.0"
sgSerialNumber= "0000000000"
sgDeviceId= "test-SG-id"
sgDeviceName= "test-SG-name"
Troubleshooting
If you continue to receive alerts, contact Blue Coat Customer Support. For
licensing questions, contact Blue Coat Support Services. It is helpful to obtain a
packet capture for CPU, memory pressure, and network interface issues, before
calling Technical Support.
Table 82 Customer Support and Support Services Contact Information
Blue Coat Customer 1.866.36.BCOAT (Toll Free)

Support E-mail: support@bluecoat.com
http://www.bluecoat.com/support/contact.html
Blue Coat Support http://www.bluecoat.com/support/services/index.html
Services
145
146
This chapter describes the Blue Coat Director standby feature and how you can
use it to achieve redundancy and disaster preparedness.
The Director standby feature is designed to minimize Director service disruptions
caused by network outage, disaster, or Director failure. When standby is
deployed, the Director configuration is mirrored to a second Director whose only
function is to take over for the first Director if a failure occurs. The takeover is not
automatic; an administrator must manually instruct the standby Director (called
the Secondary) to take over the functions of the Primary Director.
All configuration of the Director standby feature is done through the CLI.
Important: The Director standby feature is supported only for the Director 510
platform.

"Section A: Requirements and Terminology"on page 148
"Section B: Detailed Standby Concepts"on page 152
"Section C: Implementation Details"on page 156
"Section D: Scenario: Implementing a Director Standby Pair"on page 160
"Section E: SNMP Notifications for Director Standby"on page 169
147

This section describes Director standby requirements and terminology.
Requirements
To implement Director standby, you must have the following:
Two Director 510 appliances
A unique IP address for each Director appliance
Approximate synchronization (ten seconds or less) of the two Director's
clocks.
One method of ensuring clock synchronization is to run NTP on both
Directors. Clock synchronization is important because if an administrator
makes the Secondary Active (see "Active" on page 150), jobs that were not
started on the Primary Director need to start at the right time on the
Secondary Director. Since it is difficult to achieve exact clock synchronization,
having the Secondary Director lag behind slightly is preferred.
One or more administrators with read/write privileges
A remote SNMP management station, for example, HP Openview
The management station is required to monitor the state of the Directors.
Without a management station, you will not be able to determine if one of the
Directors has failed. The SNMP Management station:
Receives SNMP notifications from the standby pair.
Periodically polls the Directors to ensure they are online.
See "Configuring Director to Notify Remote Management Stations of SG
Appliance State Changes" on page 143 for more information.
Terminology
Before reading further, you should familiarize yourself with the following terms.
Standby Pair
Two Director 510 appliances, one configured as a Primary Director and one
configured as a Secondary Director. The pair works together to achieve
redundancy.
Partner
A given Director's "partner" is the opposite Director in the Pair. The Primary
Directors partner is the Secondary Director and the Secondary Directors partner
is the Primary Director.
148
Primary Director
A Director identity. The Primary Director is the device in the standby pair that
normally performs all day-to-day Director operations. All changes on the Primary
Director are propagated to the Secondary Director by means of the rsync utility
running over SSH. The Primary Director continually executes SSH commands on
the Secondary Director to verify connectivity. The default state of the Primary
Director is Active, which means that it is able to perform monitoring and
configuration operations.
The Primary Director is the only device that:
Initiates syncs. The Secondary Director is only a passive Rsync client.
Connects to the Secondary Director to obtain connectivity status. The
Secondary Director does not initiate such checks but notices if it has not been
queried by the Primary Director.
Secondary Director
A Director identity. The Secondary Director is the device in the takeover pair
whose only purpose is to take over for the Primary Director when a failure occurs.
The normal state of the Secondary Director is Reserve, which means that it cannot
perform any monitoring or configuration operations and will not accept user-
interface connections. If a user configures the Secondary Director to be Active, it
will perform all functions previously performed by the Primary Director.
When you execute the make-secondary command, the Director reboots. To access
the Secondary Director, you must then use the standbyuser username.
Sync
The process of copying all changes from one Director to its partner. This includes
changes made by administrators as well as changes to the event database and job
status. The possible status for sync is: "in-sync", "syncing", or "retrying sync"
(reported if the first attempted sync failed).
Standalone Director
A Director state. A Standalone Director is one that is not participating in a
standby pair and that technically has no standby identity. This is the factory
default state of Director. A standalone Director cannot participate in a standby
pair until an administrator changes its identity to Primary or Secondary.
Executing the make-standalone command on a Primary or Secondary Director
takes the appliance out of the standby pair. Note that in this document, a Primary
or Secondary Director that has been made standalone is still referred to by its
previous identity, i.e., Primary or Secondary.
When you execute the make-standalone command, the Director reboots.
149
Active
A Director state that either the Primary or the Secondary can achieve. In the
Active state, the Director allows configuration and monitoring operations to be
executed on it. You use the Active Director for all Director tasks, including remote
administration via overlay, profile, and job creation and execution, health
monitoring, and backup and restore. The normal state of the Primary Director is
Active.
Reserve
A Director state that only the Secondary can achieve. In the Reserve state, the
Director stands by and awaits any failure of the Active Director (the Primary).
In the Reserve state, the Director is essentially an rsync client. If the Primary
Director fails, the administrator must change the Secondary Directors state to
Active so that it can resume service. Absent any failures, the normal state of the
Secondary Director is Reserve.
Inactive
A Director state that only the Primary Director can achieve. If, while the Primary
Director was powered off, the Secondary was made Active, the Primary Director
notices this and immediately enters the Inactive state. Transitioning to Inactive
prevents different changes to both Directors configuration. If the Primary and
Secondary Directors have different configurations, those changes cannot be
merged and you will have to discard the changes from one of those
configurations.
About the Standby Pair State

This section describes the Primary and Secondary Director states.
Primary Director States

The Primary Director can be in the states described in the following table.
Table 91 Primary Director States
Primary Director State Description
Active The state of the Director performing all

configuration and monitoring operations.
Inactive The Primary Director assumes this state when the

Secondary has been made Active.
Standalone Not part of the standby pair.
Secondary Director States

The Secondary Director can be in the states described in the following table.
150
Table 92 Secondary Director States
Secondary Director State Description
Reserve The Secondary Director assumes this state when

the Primary Director has been made Active.
Active The state of the Director performing all

configuration and monitoring operations.
Standalone Not part of the standby pair.

If a Director goes offline for any reason, it resumes its prior state when it comes
back online. For example, if the Primary Director was Active when it went offline,
it is still Active when it comes back online. (It is possible, however, that its partner
was promoted to Active in the interim; in that case, the Primary Director
immediately transitions to the Inactive state. When the Primary Director is made
Active again, it will synchronize with the Secondary Directors configuration.)
151

A Director standby pair is composed of a Primary Director and a Secondary
Director (these identities are configured by the administrator). The normal state of
the Primary Director is Active, meaning that it allows configuration and
monitoring operations to be executed on it. The normal state of the Secondary
Director is Reserve, meaning that its only function is to mirror the configuration
and database of the Primary Director so that it can take over for the Primary
Director if configured to do so. Until the Secondary Director is made Active, no
commands or operations can be executed on it (aside from the make-active
command).
Failover Assumptions
These assumptions will help you understand the operation of the standby pair:
Only administrators can alter the state of the standby pair.
If an administrator manually intervenes, it requires another manual
intervention to get the standby pair back to the initial state. Consider the
following examples:
If an administrator executes the make-standalone command on a Director
(breaking the standby pair), then the administrator must perform a make-
primary or make-secondary to get that Director back into the pair.
If an administrator executes the make-active command on the Secondary

Director, then an administrator must execute the make-active command
on the Primary Director to make it Active again. (which will indirectly
cause the Secondary Director to revert back to the Reserve state.)
There is only one automated transition.
If the Primary Director notices that the Secondary Director has been made
Active, it automatically transitions to the Inactive state. No other transitions
occur without administrator intervention.
When a Director comes up, it resumes its prior state.
If a Director goes down for any reason, (the Director powers down or crashes),
that Director will resume its prior state when the condition is resolved. For
example, if the Primary Director was in the Active state when it failed, it
resumes the Active state when it comes back online (unless the Secondary
Director was made Active in the interim; in that case, the Primary Director
transitions to Inactive).
How Data is Mirrored

When a change is made to the Primary Director, that change is immediately
propagated to the Secondary Director over an SSH connection, thus ensuring
redundancy. Normally, the Primary Director and Secondary Director are
synchronized or are in the process of synchronizing. However, a network outage
will result in a longer-term out-of-sync condition.
152
Figure 91 Data Mirroring between the Primary Director and Secondary Director
Monitoring Connectivity
To verify that its partner is reachable and functioning normally, the Primary
Director continually executes (every five seconds) a specific CLI command (SSH)
on the Secondary Director. If the CLI command fails 12 times in a row (one
minute), the Primary Director sends an SNMP notification to any configured
management stations (if you have configured this featuresee "Requirements" on
page 148). If the Secondary Director is functioning normally and has not received
the expected CLI command within one minute, it sends an SNMP notification to
the management station.
Note: You must configure the Primary Director to send the standby SNMP
notifications. For more information, see "Configuring the Standby Pair" on page
156.
Figure 92 Standby Pair Verification
How Failover Works

If the Primary Director fails, the Secondary Director notes that the expected SSH
connectivity check has not arrived and sends an SNMP notification to all
configured management stations. While the Secondary Director is fully capable of
resuming Director operations as though it were the Active Director, it cannot do
so unless an administrator changes its state from Reserve to Active. This manual
153
process prevents the Directors from switching states prematurely. For example, if
the network link failed and the Primary Director could not query the Secondary
Director, an automated transition might make the Secondary Director Active. This
would result in two Active Directors performing operationseach with a
different configuration.
To make the Secondary Director Active, an administrator must execute the make-
active CLI command on it. Only an administrator with read/write privileges can
issue this command. After the Secondary Director has been made Active, it
assumes all configuration operations previously performed by the Primary
Director.
When the Primary Director comes back online, it asserts itself as Active again, but
will immediately transition to Inactive if it discovers that the Secondary Director
has been made Active in the interim. The only way that the Primary Director can
regain Active status is by manual intervention; an administrator must make it
Active again by executing the make-active command on it (the Secondary
Director then transitions to Reserve).
Figure 93 Making the Secondary Director Active after Failure of the Primary
Failure of the network link between the Primary Director and Secondary Director
does not trigger any automatic state transitions. During a network outage, any
changes on the Primary Director are not immediately synchronized with the
Secondary Director. After connectivity is restored, the Primary Director then
automatically synchronizes all changes (since the last successful sync) with the
Secondary Director.
154
No state change occurs as a result of network link failure. All state

transitions are the result of administrator intervention.
Figure 94 Network Link Failure and Standby State
155

To create a standby pair, you must first decide which Director 510 is to be the
Primary Director and which is to be the Secondary Director.
The Primary Director should be the device that you want to normally be the
Active Director, that is, the Director that normally executes all operations. When
you configure a Director as a Primary, it automatically assumes the Active state
and begins normal operations. As part of this initial configuration, the Primary
Director sends its state to the Secondary Director so they are in sync (except that
which is clearly unique to each Director, for example IP address).
The Director configured as Secondary automatically assumes the Reserve state
and immediately begins acting as the Rsync client for the Primary Director. No
other operations can be performed on the Secondary and user-interface
connections are refused. If a user tries to initiate a connection to the device, the
following dialog is displayed.
Figure 95 Non-Active Director Error Dialog
Taking a Director Out of the Pair

You can remove the Primary Director or Secondary Director from the standby
pair, for example to perform maintenance, by changing the Director identity to
Standalone. To change the Director identity to Standalone, execute the make-
standalone CLI command on the appliance.
Configuring the Standby Pair

The standby pair can be created only through the Director CLI.
During configuration, you must enable the Primary Director to send the standby
SNMP notifications. These notifications are used to report the state transitions of
the standby pair. If you do not enable these, you will have no mechanism for
determining the current state of the standby pair, including device failure.
156
Note that you do not have to enable SNMP notifications on the Secondary
Director. Any (or all) notifications enabled on the Primary Director are
automatically enabled on the Secondary Director. However, the two Directors are
not fully configured as a standby pair (and thus, do not send notifications) until
they have been configured as such, have rebooted, and are in-sync.
To configure the standby pair:

1. Change to configuration mode:
director # conf t
2. On the Director that is to be Primary, enable the standby-state SNMP

notifications:
director (config) # snmp traps standby-state all enable
You can enable the notifications individually if you desire. To get a listing of
the available standby states, enter the following command:
director (config) # snmp traps standby-state ?
3. On the Director that is to be Primary, enter the following command to make it

Primary:
director (config) # standby make-primary secondary_ip-address
ssh_password
The Director reboots and comes back online as Primary.

4. On the Director that is to be Secondary, enable the standby-state SNMP
notifications:
director (config) # snmp traps standby-state all enable
5. On the Director that is to be Secondary, enter the following command to make

it Secondary:
director (config) # standby make-secondary primary_ip-address
ssh_password
The Secondary Director reboots and comes up in the Reserve state. When
accessing the Director after the reboot, you must use the standbyuser
username.
6. Reboot the Primary Director again.
Verifying the Standby Settings

To view the standby settings:
director # show standby-settings
Identity:Primary
State:Active
Partner IP:10.9.40.118
Partner State:Reserve
Sync State:In-sync
Time Last HB Recd.:Tue Mar 06 2007 09:38:04
157
Viewing the State of the Primary or Secondary Director

After you have configured the standby pair, the identity of both Directors and the
current synchronization status are displayed at the top of the Director
Management Console.
Figure 96 Management Console Standby Pair Identity and Status Indicator

The possible standby pair identities, states, and synchronization status for the
standby pair status (as shown in the preceding screenshot) are described in the
following table.
Table 93 Possible Standby Pair Identities, States, and Synchronization Status
Standby Status Item Possible Values Notes
Director Identity Primary OK
Secondary OK
Standalone Not part of a standby pair.
158
Table 93 Possible Standby Pair Identities, States, and Synchronization Status (Continued)
Partner Status Primary Director GUI Reserve The Secondary is operating

(partner is the normally.
Secondary)
Unreachable Indicates that the
Secondary Director is
down or that the network
link has failed.
Misconfigured The Secondarys standby

settings do not show this
Primary Director as its
partner.
Secondary Director Inactive The Primary Director is

GUI inactive because the
(partner is the Primary) Secondary was made
Active while the Primary
Director was down.
Unreachable Indicates that the Primary

Director is down or that
the network link has failed.
Sync Status In-sync OK
Syncing Synchronization in process
Retrying sync The first synchronization

attempt failed, retrying.
Making Changes on the Primary Director

If you have configured the standby pair and are performing operations on the
Primary Director, commit your changes and carefully watch the synchronization
status to ensure that the changes are synchronized before leaving to go do
something else.
The reason for this is that if the Primary Director fails before synchronization is
complete (or the network link is down), you might need to make the Secondary
Active and those changes will not be present on the Secondary Director. By
waiting for the sync to complete, you will remember what those changes were in
the event that you need to re-create them on the Secondary.
You can track your changes by enabling audit logging. For more information, see
Chapter 7: "Monitoring Administrator Activity" on page 123.
Connecting to a Non-Active Director

You can only connect to a Reserve or Inactive Director by using the standbyuser
username. If you subsequently break the standby pair, the username reverts to its
previous setting.
159

The following scenario illustrates basic standby concepts. Reading these scenarios
will help you understand how Director standby functions.
Example Companys Disaster Preparedness

Example Company is a global company headquartered in Sunnyvale, California.
Example Company has hundreds of branch offices distributed throughout the
world. Because of its many SG appliances, Example relies on a Director (located in
the data center) to monitor its devices and to make configuration changes.
However, Examples executives worry about disaster preparedness. What would
happen if the data center Director failed or was destroyed? All of Examples
Director configuration and data (from the time the last archive was taken) would
be lost and Director service would be interrupted.
To ensure Director redundancy, Examples administrator wants to implement
Director standby. The company decided to replace their existing Director with
two Director 510s. (The Director 510 is the only platform that currently supports
Director standby.)
Examples administrators installed the first Director in the data center in
Sunnyvale and installed the second Director in a branch office in Los Angeles.The
appliances are configured as described in the following table.
Table 94 The Properties of Example Companys Standby Pair Directors
Director Location IP Address Hostname
Sunnyvale 10.1.1.2 SV
Los Angeles 20.1.1.2 LA
Example Procedure: Configuring the Standby Pair

This procedure describes the steps that Example Companys administrators
would follow to create their standby pair.
Configuring Example companys standby pair:

1. On the Sunnyvale Director, enable SNMP and set Examples HP OpenView
management station as a notification recipient for device-state and standby-
state notifications.
Note: For more information about the standby-state notifications, see

"Configuring the Standby Pair" on page 156. For more information about the
device-state notifications, see "Configuring Director to Notify Remote
Management Stations of SG Appliance State Changes" on page 143.
Sunnyvale Director:
director-sv (config) # snmp-server traps standby-state all enable
160
director-sv (config) # snmp-server traps device-state all enable

director-sv (config) # snmp-server host 0.0.0.0 traps version 2c
In the preceding command, 0.0.0.0 is the IP address of the management

station.
2. Configure the Sunnyvale Director 510 as Primary and specified the IP address
of the Secondary Director and the password of the SSH connection:
director-sv (config) # standby make-primary 20.1.1.2 thunder
Where thunder is the SSH connection password.

The Sunnyvale Director reboots and comes back online as Primary.
3. Configure the standby state notifications on the Los Angeles Director:
director-sv (config) # snmp-server traps standby-state all enable
4. Configure the Los Angeles branch office Director 510 as Secondary and
specified the IP address of the Primary Director and the password of the SSH
connection:
director-la (config) # standby make-secondary 10.1.1.2 thunder
Where thunder is the SSH connection password.

The LA Director reboots and came back up as Secondary. To access the
Secondary Director in the Reserve state, you must use the standbyuser
username to connect to the CLI; you cannot connect to the Management
Console of a Director in the Reserve or Active state.
When the Secondary reboots and comes online, the Primary Director discovers it
and synchronizes all of its data over an SSH connection. The administrators can
verify the synchronization by opening the Primary Directors Management
Console and observing the synchronization status.
Configuration Notes
Only two commands are allowed on the Secondary, make-active and make-
standalone.This ensures that the two Director configurations are never
unsynchronized.
Reserve and Inactive Directors allow connections only from the standbyuser
user, regardless of any previously configured usernames. If you subsequently
break the standby pair, the username reverts to its previous setting.
After the standby pair is configured, the identity of the Secondary Director
cannot be changed unless the standby pair is broken by making it standalone.
If by accident, both Directors were configured as Primary, each Primary
Director would report the opposite as misconfigured because its partner is not
Secondary
161
Moving the Directors

Later, Example Companys Sunnyvale and Los Angeles labs are scheduled for
improvements. Examples administrator needs to move the Directors. The
following sections describe how these moves would be accomplished.
Moving the Secondary Director

To accomplish this move, the administrator can simply take the Secondary
Director offline.
After the lab improvements are complete, the Secondary Director can be re-racked
and powered up; the Primary Director will automatically synchronize all changes
with it.
Taking the Primary Director Offline

Taking the Primary Director offline requires additional consideration because the
Primary Director performs all configuration operations. Therefore, before
shutting down the Primary Director, the administrator should do the following:
1. Schedule the downtime during a relatively quiet period in which no jobs or
configuration operations (or very few) are running. This minimizes the
chances that that an operation will be partially completed when the Primary
Director is powered-down.
2. Ensure that all changes have been synchronized with the Secondary by
verifying the synchronization status indicated in sync in the Management
Console.
3. Make the Secondary Director Active:
a. Using the standbyuser account, access the Secondary Directors CLI:
login as: standbyuser
b. Switch to enable mode:

director-la > en
c. Make the Secondary Director Active:

Director-la # standby make-active
Note: The username of the Secondary reverts from standbyuser to its original
setting when the Director is made Active.
162
When the Primary Director notices that the Secondary Director has been made
Active, it will transition to Inactive.
4. Properly shut down the Primary Director. See "Shutting Down Director" on
page 214 for more information.
5. Perform the move.
6. Power up the Primary Director.
7. Make the Primary Director Active:
a. Using the standbyuser account, access the Primary Directors CLI:

director-sv > en
c. Enter the following command:

director-sv # standby make-active
When the Primary Director is made Active, it synchronizes its configuration

with the Secondary Directors.
Note: The username of the Primary reverts from standbyuser to its original
setting when the Director is made Active.
Network Link Failure

Later, the network link between the two Directors failed.
Example Companys management station receives SNMP notifications from the
Primary Director and Secondary Director stating that its partner was unreachable.
Because both the Primary and Secondary Directors were still online, the
administrator suspected a network failure. As expected, the management station
also showed a failure of the network link between the two Directors.
Example would deal with this type of network outage in the following ways.
Dealing with Network Outages

When a network link fails, the administrator should analyze the standby pair to
determine the current status. If both Directors are operating normally, there is no
cause for concern, even though:
The synchronization status indicates retrying-sync.
The Secondary is unreachable.
Changes have been made to the Primary Directors configuration since the
link failure.
Jobs are scheduled or in progress.
163
These conditions are not a cause for concern as long as the standby pair is in its
normal state (Primary Active and Secondary Reserve). This is because all changes
will eventually be synchronized with the Secondary Director as soon as the link is
restored.
Assume that the network link then starts going up and down. Due to the nature of
the network outage, the Secondary Director is able to reach more of Examples SG
appliances than the Primary Director. In this case, the administrator should
consider the following options:
Break the standby pair
The administrators can break the standby pair and running two standalone
Directors. However, if the long-term plan is eventually remake the standby
pair, every change made to the Secondary Director must be manually recorded.
Any time that both Directors have pertinent, but different, configuration data,
the data must be manually synchronized. Otherwise, the Primary (Active)
Director will overwrite the Secondarys configuration during the automated
synchronization process, which is part of the make-primary process.
Keep the standby pair
A better alternative is to keep the standby pair. If the Secondary Director can
reach more devices, the administrator can shut down the Primary Director
and make the Secondary Active. Powering down the Primary Director ensures
that a double Active condition will not occur that could cause different
changes to be made to the two configurations.
Before shutting down the Primary, the administrator should wait until no jobs
are scheduled or in progress. To confirm that there are no incomplete jobs, the
administrators should verify that there are no empty job reports on the
Secondary Director. If a job had been started on the Active Director but the
results had not been synchronized with the Secondary Director, there will be
empty job reports.
When the stability of the link is restored, the administrator can bring the Primary
Director online. The administrator should then check the Management Console to
see if changes have been made to:
The Secondary Directors configuration but not the Primarys.
If this occurs, no further action is required. This is the only case in which the
changes on the Secondary Director are synchronized with the Primary
Director.
The Primary Directors configuration but not to the Secondarys.
If this occurs, no further action is required. In this case, the Primary Directors
changes are automatically synchronized to the Secondary Director when the
link is restored.
Both the Primary Directors configuration and the Secondarys.
If this occurs, the administrator will have to identify which changes to keep
because changes cannot be merged.
164
Primary Director Failure

If Example Companys Primary Director fails, the following section describes how
Example Company can deal with that failure.
Dealing with the Loss of the Primary

If the Primary Director fails, the administrator should execute the make-active
command on the Secondary so that Director service is resumed as soon as
possible. The administrator must then check the Secondary Director to determine
if the following situations exist.
Synchronization is complete and no jobs were in progress when the

Primary Director Failed
In this situation, Example Company can simply continue to operate the
Secondary Director.
An administrator was making changes that had not finished synchronizing

at the time the Primary Director failed; no jobs were in process
If Example Company discovers that an administrator was making changes when
the link went down, those changes are lost. (This is why administrators are
encouraged to ensure that changes properly synchronize before moving-on to
their next task.)
Jobs were in progress when the Primary Director Failed

If jobs were in process at the time the Primary Director failed, the administrator
will have to determine if the jobs completed and if those changes were
synchronized. The administrator can determine if the jobs completed by checking
for incomplete job reports in the Secondary Directors Management Console (Jobs
tab).
If they determine that some of the jobs failed to complete, the administrator must
analyze the jobs to determine the required corrective action, if any.
The type of corrective action depends on the job type, one-time only, idempotent,
and restartable. These three job types are defined by their contents, and not by the
software:
Idempotent job: A job that will yield the same result if it is run once or many
times. For example, a job that backs up multiple devices.
Corrective action: Run the job again.
One-time only job. A job that is to be executed exactly one time. For example,
a job that changes the passwords on a device. if a one-time job is re-run, it will
fail if that job has already been executed.
Corrective action: To determine if action is required, log into the remote device
and verify if the one-time job has been executed.
165
Restartable job: An idempotent job that would result in benign errors or

warnings when run a second time. For example, a job that defines five realms
would produce errors if several of those realms were already defined.
Corrective action: Re-run the job on each target SG appliance and evaluate
each error to see if additional action is required.
Jobs Were Scheduled to Start During the Primary Directors Downtime

If Example Companys administrator discovers that some jobs failed to start
because the job start time occurred after the Primary died but before the
administrator did make-Active on the Secondary, the administrator will have to
identify those jobs so that they can be re-run.
Upgrading the Software on the Standby Pair

When Example Company decides to upgrade the software on the two Directors in
the standby pair, they can upgrade the standby pair in the following ways:
Taking both Directors out of service
This is the easiest software upgrade method.
Maintaining Director service
Use this method if Director service cannot be interrupted.
Software Upgrade the Easy Way: Break the Standby Pair

The administrator breaks the standby pair and makes both the Primary and
Secondary Directors standalone. Of course, this means that the Directors are
offline during the upgrade process. If the administrator uses this method, they
should ensure that no jobs are scheduled to run during the anticipated outage.
After both Directors have been upgraded, they can recreate the standby pair by
designating one Director as Primary and one Director as Secondary.
To upgrade the Directors by breaking the standby pair:

1. Select a time when no jobs or operations were scheduled on the Primary
Director.
2. Make the Primary and Secondary Directors standalone:
Director (config) # standby make-standalone
3. Upgrade the Directors normally.

4. Remake the Primary Director:
Director (config) # standby make-primary primary-ip ssh_password
5. Remake the Secondary Director:

Director (config) # standby make-secondary secondary-ip ssh_password
166
Software Upgrade Without Downtime

The second upgrade process is more complex because one of the Directors has to
be up at all times.
To upgrade the standby pair while maintaining service:
Note: The following procedure assumes that the Secondary Director is acting in
Reserve.
1. Verify that both Directors are in sync.

2. Change the state of the Secondary Director from Reserve to Active.
a. Using the standbyuser account, access the Secondary Directors CLI:

director > en
c. Make the Secondary Director Active:

director # standby make-active
3. Make the Primary Director Standalone.

Director # standby make-standalone
Note: After you make the Primary or Secondary Director standalone, you
must connect to it using the username that was configured before you created
the standby pair.
4. Upgrade the Director software of the Primary Director.
Important: To ensure that the Directors do not get out of sync during the
upgrade process, do not make any configuration changes to and verify that
no jobs are scheduled on the Secondary Director for the duration of the
upgrade process.
5. Make the Secondary Director standalone.

Director # standby make-standalone
6. Archive the Secondary Directors configuration.

7. Upload the archive to a Web server.
8. Restore the archive on the Primary Director.
The archive contains the IP address of the Secondary Director. You must
replace it with the IP address of the Primary Director.
9. Change the identity of the Primary Director from standalone to Primary.
167
Director # standby make-primary primary-ip ssh_password
10. Upgrade the software on the Secondary Director.

11. Put the Secondary Director in Reserve.
Director # standby make-secondary secondary-ip ssh_password
After completing the software upgrade, ensure that the Primary and Secondary
Directors are up, synchronized, and running the upgraded version.
168

An SNMP notification is sent for each type of state transition in the standby
pair. All transitions that cause notifications also cause entries in the event log.
Each type of notification can also be individually enabled or disabled.
Notifications Sent Only by the Primary Director

Sync-failed
blueCoatDirectorStandbyChgSyncFailed
A synchronization from the Primary Director to the Secondary Director has
failed. (The Primary Director will continuously retry the synchronization, but
this notification will NOT be sent after every successive failure).
Remediation: This notification is often caused by loss of reachability from the
Primary Director to the Secondary Director, (look for a corresponding
_PartnerReachabilityLost notification).
Sync-reestablished
blueCoatDirectorStandbyChgSyncReestablished
After a _SyncFailed condition was reported, a successive synchronization
operation succeeded. (This notification is NOT reported after every successful
synchronization).
Primary-backing-off-to-Inactive
blueCoatDirectorStandbyChgPrimaryBackingOffToInactive
While running in the Active state, the Primary Director discovered the
Secondary Director in the Active state. In this case, the Primary Director
automatically 'backs-off' to the Inactive state.
Remediation: There are two common ways of getting into this condition:
1. With the Primary Director in the Active state and the Secondary Director in
the Reserve state, there was a network failure. An administrator promotes
the Secondary to the Active state. On the first 'heartbeat' after the network
comes back up, the double-Active condition is detected.
2. With the Primary Director in the Active state and the Secondary Director in
the Reserve state, the Primary Director powers-off. An administrator
promotes the Secondary to Active. When the Primary Director powers-up,
the double-Active condition is detected.
In both cases, an administrator has to determine which Director(s) have
changes (if any), and decide upon the set of changes to keep when they make
the Primary Director Active again.
Partner-config-invalid
blueCoatDirectorStandbyChgPartnerConfigInvalid
The reason for this notification depends on whether the Director intended to be
this Director's partner is configured as part of a standby pair, or not.
169
If the partner Director is configured as part of a pair: This Director (the Primary)
logged into the Secondary (as part of the 'heartbeat' process) and asked the
Secondary Director who it thought its Primary Director was. The Secondary
'pointed-to' a THIRD Director, when it should have been configured to point to
the Primary Director. The IP address of the THIRD Director is reported by the
'standbyPartnersPrimary' varbind in this notification.
If the partner Director is standalone: The Primary Director has found no Primary
configured on the other Director, and will report '0.0.0.0' for the varbind
'standbyPartnersprimary' in this notification.
Remediation: An administrator must check and resolve the configuration on
either or both Directors in the pair.
Partner-config-validated
blueCoatDirectorStandbyChgPartnerConfigValidated
After reporting a _PartnerConfigInvalid condition, this Director once again
found that its Secondary Director correctly 'pointed' to this Director as partner.
Notifications Sent Only by the Secondary Director

Secondary-indirectly-forced-to-Reserve
blueCoatDirectorStandbyChgIndirectlyForcedToReserve
The Secondary Director has transitioned to the Reserve state in response to seeing
the Primary Director transition to the Active state.
This transition is not automatic since it is only the second-order effect of
administrator intervention on the Primary Director.
Receipt of this notification confirms that the Secondary Director has 'heard' the
Primary Director transition to Active. As a result, the Secondary transitions to the
Reserve state.
If the Secondary Director does not report this notification immediately after the
Primary Director is promoted via the make-active command, the network
between the two Directors might be down, (which would be reported by a
_PartnerReachabilityLost notification). In this case, administrators must be
especially cautious because both Directors will be running in the Active state, and
they can inadvertently make changes on both Directors, thus creating a problem
when the standby pair is rejoined (one set of changes or the other will have to be
discarded).
Notifications Sent by the Primary or Secondary Director

Partner-reachability-lost
blueCoatDirectorStandbyChgPartnerReachabilityLost
If this notification is reported by the Primary Director, that Primary could not
reach the Secondary Director to log-in and check its Standby status (also called a
heartbeat).
170
If this notification is reported by the Secondary Director, that Secondary has not
'heard' the Primary Director log-in for over a minute. Either way, the network link
between the two Directors is not working properly. Any changes made on the
Primary Director will not by synced to the Secondary (assuming the Primary is
the Active Director).
Remediation: Fix the network link between the two Directors. In the meantime, be
careful that no administrator makes the Secondary Director Active or you might
reach a condition in which there are two Active Directors with changes on each.
Partner-reachability-regained
blueCoatDirectorStandbyChgPartnerReachabilityRegained
After a _PartnerReachabilityLost condition was reported, the partner Director
reestablished communication with this Director.
Notifications Caused by Administrator Action

All notifications in this section are reported only by the Director on which the
administrator executed the state change.
Forced-to-Primary
blueCoatDirectorStandbyChgForcedToPrimary
The reporting Director has been forced, by administrator command, to be the
Primary Director in a standby pair.
Forced-to-Secondary
blueCoatDirectorStandbyChgForcedToSecondary
The reporting Director has been forced, by administrator command, to be the
Secondary Director in a standby pair.
Forced-to-StandAlone
blueCoatDirectorStandbyChgForcedToStandalone
The reporting Director has been forced, by administrator command, to run
standalone (outside a standby pair).
Forced-to-Active-State
blueCoatDirectorStandbyChgForcedToActiveState
The reporting Director has been forced, by administrator command, to the Active
state.
171
172
Blue Coat Director logs help you to determine the nature and location of a
problem when you troubleshoot Director. They inform you if the URL that you
entered is invalid or unreachable, or if your syntax is incorrect. Log files contain
information about connection and configuration issues encountered by
Director. They also inform you about the operating conditions of the system.
To monitor your system, you can:
Use the daily syslog to view results of commands generated by the Director
CLI.
Click the All Jobs for Director icon or select Content > Query Content in the
Director Management Console.
Use the show commands from the Director CLI.
Log Message Terminology

The terms in the following table are used frequently in log messages.
Table 101 Log Message Terms
Terms Definitions
Addr-device A command option for IP address or hostname of an SG
appliance.
backup ID A string that uniquely identifies a backed up configuration file

within the management domain.
cmd ID A unique identifier generated by the content manager for each

command that is executed.
device ID A string that uniquely identifies an SG appliance record.
device spec A group ID, device ID, or the hostname/IP address of an SG

appliance.
Exponent An integer that is used with an RSA key.
Filename Name of a file. Filename should begin with an alphanumeric

character. It can contain the following characters: - (dash),
_ (underscore) or . (dot). Filenames of configuration files and
Director image files are case-insensitive.
group ID A string that uniquely identifies an SG appliance group within

the management domain.
Interface number Used in network management. Interface number specifies the

number of a network interface on the Director management
node.
Job ID A string that uniquely identifies a job within the management

domain.
173
Table 101 Log Message Terms (Continued)
Terms Definitions
Keyword An SG appliance, group or addr-device.
Netmask A string of 0s and 1s that screen out the network part of an IP

address so only the address of the host computer remains.
PIN Personal Identification Number for the front panel LCD made
up of four numeric values.
Process ID (PID) A unique identifier assigned to all processes, when they are
started. Each system has a maximum value for the PID number.
When this is reached the PID numbering is started again.
state The type of outstanding content query request (pending or in-

progress).
urls from target A file of list of URLs stored on a remote host.
Components of Director
Syslog messages are generated by the components of Director. They are explained
below:
Table 102
Content Manager Responsible for handling content management commands

through the Director CLI.
Configuration Manages the configuration on Director. All the processes on

Manager Director receive their configuration from the Configuration
Manager. It also enables the administrator to centrally
manage multibox configuration and OS upgrades.
LCD Panel Manager Communicates with the front panel LCD and Configuration
Manager to handle the input and output via LCD. When it is
not engaged in configuring the system, LCD Panel Manager
displays information, such as the hostname and CPU
utilization.
Communication Responsible for executing Director CLI commands on SG

Manager appliances. Clients, such as Configuration Manager and
Content Manager, which send Director CLI commands to the
SG appliances, communicate using the Communication
Manager.
Process Manager Manages processes that run continuously in user address

space. It detects termination of all processes that are not
requested by Process Manager. Process Manager generates a
syslog message every time a process starts or exits.
Job Manager Responsible for the execution of scheduled content and

configuration management commands.
174
About the Syslog

Director CLI logging allows the components/facilities in the system to log
messages based on the varying levels of severity of the message. These facilities
are discussed under "Syslog Messages" on page 176.
You can monitor the system by viewing the syslogs.
Syslog acts as an error manager, allowing you to view log entries at the local host
and forward them to remote hosts. Setting up a remote logging host increases the
net traffic from Director. If Director accesses the remote logging host and the SG
appliances on the same interface, extensive logging can impair the
communication between the devices and Director. Remote logging increases the
activity of the Configuration Manager and slows down its operations.
Syslog Log Levels

You can set up logging levels to restrict the log messages sent to the system log
daemon (syslogd) and to the messages log (the console).
Destinations for log messages are referred to as log sinks.
Console sink (the CLI session): Set the level at which messages are sent to all
open CLI sessions (the messages log). This is also the level at which messages
pop up on the terminal screen outside the log and on the serial console.
Local sink (/var/log/messages): Set the level at which messages are saved
locally. At the local sink, warning is the highest logging level you can choose. If
you try to choose a higher logging level, you will receive an error message and
the logging level will reset to warning.
Trap sink (remote host): Set the level at which remote messages are sent to
syslogd servers.
From the console or trap sinks, you can select five levels of messages. Message
levels are based on the severity of the problem that generates the message.
notice_minor: These messages reflect normal operations occurring in the
system. These messages are more detailed than the notice messages. An
example of notice_minor behavior is the notification of every CLI command
executed through the CLI interface.
Important: The Director Management Console does not work if the logging
console level is set to notice_minor.
notice: These messages provide information about the normal but significant
conditions in the system. This level is the default logging level for the local
sink.
warning: Warning messages indicate abnormal operating conditions that
require immediate attention.
error:These messages inform you about the errors that Director encounters
when it interacts with external systems (that are not developed by Blue Coat)
through user input.
175
critical: These messages give information about a malfunction of the system.

This logging level is the default for the console sink.
Critical messages and their descriptions are not listed in this document. If
critical messages recur, Blue Coat recommends that you copy the message
exactly as it appears on the Management Console console or in the syslog, call
your Blue Coat Customer Support representative, and provide the
representative with the gathered information.
Other log levels are reserved for internal use.
Performance can be affected by setting the logs to trap messages at too low a level.
If you set the local logging level too high, though (above notice), job reporting
fails.
Navigating through the Syslogs

Syslogs are generally long. Below are shortcuts to enter an interactive mode
where you can scroll through and search the syslog files:
Enter < to go to the beginning of the file.
Enter > to go to the end of the file.
Press <spacebar> to move down a page.
Enter /string (without quotes) and press <Ctrl> to search forward for
string.
Enter ?string (without quotes) and press <Ctrl> to search backward for
string.
Enter n to find the next occurrence of string in the direction last searched.
Press <up arrow> to move up one line at a time.
Press <down arrow> to move down one line at a time.
Enter b to move up one page.
Enter q to quit.
Syslog Messages
Syslog messages are generated by the components of Director. For more
information, see "Log Message Terminology" on page 173. Some of the frequently
used terms in the syslog are explained in this section.
Syslog messages are created and logged in the form of plain text ASCII string.
Given below are the messages sent to the syslog by the components of Director:
Table 103 Content Management Messages
Message Level Description

Command ID: <cmd ID> Notice_minor The internal state associated
Removed from the system. with the specified command ID
is removed from the system.
The content query command
with the given ID will fail.
176
Table 103 Content Management Messages (Continued)

Number of URLs/Regexes Notice_minor The message displays the
for Command ID <cmd ID>: number of URLs/Regexes that
<number of URLs> are being processed for the
specified command.
URL List <cmd ID> <URL Notice_minor The message lists all URLs and
number> <URL> their positions in the URL list
for the command specified by
the <cmd ID>.
Number of Device IDs for Notice_minor Displays the number of SG
Command ID <cmd ID>: appliances that are being used
<number of devices> to process the specified
command.
Device ID List <list ID> Notice_minor The message shows each SG
<device ID> appliance and its position in the
specified device ID list.
Command ID: <cmd ID> Notice_minor The message displays the CLI
Device ID: <device ID> command issued to the
Command: <command specified SG appliance and the
string> Response: associated response. If the
<response string>
response is an error, the
message is logged as a warning.
Command ID: <cmd ID> Notice The specified command is
Command accepted. recognized as valid.
Command ID: <cmd ID> Notice The command is executed
Command completed. successfully.
cmd starting (pid = Notice This message is generated every
<Process ID>) time Content Manager is
started.
cmd exiting (pid = Notice Content Manager is terminated.
<process ID>)
Command ID: <cmd ID> Warning The message displays the CLI
Device ID: <device ID> command issued to the
Command: <command specified SG appliance and the
string> Response: associated error response. If the
<error>
response is not an error, the
message is logged at the
notice_minor level.
Command ID: <cmd ID> No Warning No SG appliances available for
candidate devices found the execution of the command.
for this command. Make sure the group has SG
appliances in it.
177
Table 103 Content Management Messages (Continued)

Command ID: <cmd ID> Warning This message indicates that a
Device ID <device ID> is command was issued to an SG
not connected appliance that was not
connected to the domain or not
functional. If the command is of
query type, it is terminated
immediately. If the command is
of long running type, such as
distribute or revalidate, then the
command is buffered for the
configured time.
Command ID: <cmd ID> Warning Invalid SG appliance/Group
Device/Group ID <device/ ID. This happens if the device/
group ID> not found Group record was removed
while the Content Manager
waited for the urls-from
command to complete.
Command ID: <cmd ID> URL Warning Download of a urls-from
List download not target failed. The reason for the
successful failure is included in the
message, if possible.
Command ID: <cmd ID> the Warning A command with the specified
device went down. <cmd ID> is actively operating
on the SG appliance.
Command ID: <cmd ID> Warning The URL specified in the CLI
Invalid URL/Regex command or the URLs/Regexes
dropped in the file downloaded by the
urls-from command are
invalid.
Table 104 LCD Panel Messages

Processing lock/change/ Notice_minor This message is generated
save of ip config: when you change the network
ipaddr: <ip address>; settings in the configuration
netmask: <subnet mask> subsystem. The message
dns: <dns address>
displays the configuration
gateway: <gateway>
information that the LCD
Panel Manager tries to set in
the config database, such as IP
address, subnet mask, DNS IP
address and default gateway
IP address.
178
Table 104 LCD Panel Messages (Continued)

LCD ready. Notice LCD Panel Manager has
successfully connected to the
configuration subsystem and
initialized the LCD panel.
Failed write because Warning You have to get the
could not get config lock configuration lock from the
user who owns it currently, to
change the configuration
through the LCD.
Failed write because Warning Configuration subsystem was
configuration was changed modified while editing IP
by another user address information. Retry the
operation through the LCD.
When LCD Panel Manager
saves IP address information,
unsaved configuration
information, if any, is also
saved. Make sure the
configuration changes are
saved, when the IP address
information is changed
through the LCD Panel.
Table 105 SG Appliance Communication Messages

Device <device ID>: Notice Director is attempting to establish
attempting connection connection with the specified SG
using ssh. appliance using SSH.
Device <device ID>: Notice Director is attempting to establish a
attempting connection Telnet connection with the
using telnet. specified SG appliance.
Device <device ID> Notice Director has established connection
connected. with the specified SG appliance.
Device <device ID>: Notice Director lost connection with the
disconnected, Reason: specified SG appliance. The reason
<error> is stated.
Device <device ID>: could Notice Communication Manager
not send bytes attempted to write commands to
successfully the specified ProxySG appliance
and failed.
Device Communication Notice This message is generated every
Daemon online time the Communication Manager
starts up.
179
Table 105 SG Appliance Communication Messages (Continued)

Device Communication Notice This message is generated when
Daemon exiting... the Communication Manager exits
and the connection between the SG
appliance and Director is lost.
Device <device ID>: Warning The specified SG appliance has a
Incompatible device version that Director does not
version <response> support. The version of the given
SG appliance is also displayed in
the message.
Device <device ID>: Warning You have entered an incorrect
enable password failed. enable password. Setting an enable
password to enter Configuration
mode is optional. You can reset the
password on the SG appliance or
Director.
Pagination prompt Warning When Director detects a pagination
detected. Resetting the prompt in the CLI, Communication
connection. Manager resets the connection, in
order to break out of the pagination
prompt.
Device <device ID>: Did Warning This message is generated when
not get response for the Director does not receive a
command <CLI command> for response from the SG appliance for
past <time> seconds the specified command. Number of
seconds passed since Director sent
the request is also listed.
Device <device ID>: RSA Warning This message is generated when
authentication failed, you enter an incorrect RSA key. The
response <error> SSH client response is also
displayed.
Device <device ID>: SSH Warning This message is logged when the
authentication failed, SSH client cannot establish a
response <error> connection between the specified
SG appliance and Director.
Device <device ID>: Warning This message is generated when
authentication failed, the Telnet client fails to establish a
password incorrect. connection between the specified
SG appliance and Director. The
reason could be an incorrect
password or login name.
Device <device ID> : Warning Director cannot establish an SSH
Couldnt fork SSH process connection with the SG appliance.
It is because a larger number of
devices are connected to the
Director than it can support.
180
Table 105 SG Appliance Communication Messages (Continued)

Device <device ID>: Warning Director cannot establish a Telnet
Couldnt fork Telnet connection with the SG appliance.
process It is because a larger number of
devices are connected to the
Director than it can support.
Device <device ID>: Did Warning Director is attempting to get a
not get response while response from the specified SG
trying to connect for appliance. Time elapsed is also
past <seconds> seconds displayed.
Table 106 Command Line Interface Messages

Operation aborted by Notice_minor This message is logged when you
user. cancel a command or you enter
<Ctrl>c.
Processing command: Notice_minor You pressed <Ctrl>d. As a result,
<Ctrl+D> Director is closing the current
session. <Ctrl>d quits the CLI, when
done on an empty line from Enable
mode.
Processing a secure Notice_minor This message is generated when a
command... command, with sensitive
information such as passwords or
licenses, is processed.
Processing command Notice_minor The command you entered and the
<error> <command> error are listed.
Processing command: Notice_minor The command with the specified ID
<cmd ID> is recognized and being processed.
CLI launched Notice This message is generated every
time you login to CLI.
CLI exiting Notice You are logged out of CLI.
Automatically logged Notice You are logged out of the CLI
out due to keyboard session because there was no user
inactivity. activity for 15 minutes.
Connection to host Notice You are disconnected from Director
lost... because there was no user activity
for the past 30 minutes.
Failed to enter enable Notice This message is logged when you
mode because privilege tried and failed to enter Enable
level was too low mode. You are limited to the
privilege level the administrator has
assigned you.
181
Table 106 Command Line Interface Messages (Continued)

User <user name> tried Notice A user with the specified user name
to enable and entered failed to enter the Enable mode. The
wrong password failure could be due to a low
privilege level or incorrect
password.
Entering enable mode Notice You have left Standard mode, which
is the lowest privilege level and
entered a higher privilege level.
Leaving config mode Notice You have left Configuration mode
and entered Enable mode.
This message is also logged when
you are logged out of the
Configuration mode due to user
inactivity.
Failed to enter config Notice This message is generated when you
mode because another fail to enter the Configuration mode
user had the lock because the configuration lock can
only belong to one person at a time.
You can retrieve the lock using the
configure terminal force
command.
Entering config mode Notice The message is generated when you
enter the highest privilege level,
which is Configuration mode.
Leaving enable mode Notice The message is generated when you
leave Enable mode to enter
Standard mode, which is the lowest
privilege level.
Table 107 Process Manager Messages

Received TERM signal Notice Process Manager receives a TERM
signal when you make certain
configuration changes. The signal is
considered a shutdown command.
Processes managed by Process Manager
handle TERM signal by shutting down
gracefully.
182
Table 107 Process Manager Messages (Continued)

Received HUP signal Notice HUP signal is received when you make
certain configuration changes. All
managed processes shut down in the
normal manner. Then configuration
information is read again from the
configuration file on disk and all
enabled managed processes are started
again.
Received SIGUSR1 Notice Process Manager handles a SIGUSR1 by
writing a text dump of its internal state
to syslog. SIGUSR1 is a user-defined
signal.
Received SIGUSR2 Notice Process Manager checks for any core
files that might have been generated
when it receives SIGUSR2.
Disconnected from Notice You are disconnected from
config daemon Configuration Manager.
This message is also logged when
Director is rebooted or shutdown.
Connected to config Notice You are connected to Configuration
daemon Manager.
<Process> terminated Notice The specified process is terminated in
response to the TERM/KILL signals
sent by Process Manager.
<Process> started Notice This message is generated every time a
process starts up.
<Manager> will start Notice Process Manager waits for the specified
in <milliseconds> ms number of milliseconds before starting
the process. This setting determines the
order in which the processes start when
Director is booted. The startup_delay
parameter determines the possible
delays. The process should be enabled
for the startup_delay to have the effect.
You enable a process by pm process
<process name> enable command
from Configuration mode.
Unexpected set-reply Warning This message is generated when
code <code>, text Process Manager receives an
<reply text> unexpected reply from Configuration
Manager.
183
Table 108 Job Messages

Executing Job <Job ID> Notice_minor The specified job has started to
execution <execution execute.
instance>
Job: <job ID> execution Notice This message is logged every

issued <cmd ID> commands, time the Job Manager receives a
now exiting signal while issuing commands.
Job <job ID> execution Notice The output of all the commands
<execution instance> <cmd that make up the job are
ID> command. Output displayed.
<output>
Received a signal: Notice This message is generated

<signal number> when a signal is received by the
Job Manager. The signal
number is also specified in the
message.
Job <job ID> execution Notice The specified job is completed.
<execution instance>
finished running
System time changed, Notice This message is logged when

recomputing job run time. the system clock changes and
the next running time is
recomputed.
Cancelling job: <job ID> Notice A job that is currently executing
or already executed is
cancelled.
Executing Job <job ID> Notice The job with the specified ID
execution has begun execution.
Can't delete job. Notice The job that you tried to delete
Currently executing. is currently running. It is
deleted after the execution is
completed.
Job was marked for Notice The job is deleted. It was
deletion, so deleting. marked for deletion when it
was running.
Couldn't execute Notice The specified job could not be
Job: <job ID> executed.
Received a SIGTERM, Notice TERM signal could be sent by a

exiting. user who wants to force the Job
Manager to shut down.
Job ID: <job ID> Notice The message notifies you if the
is_enabled: <true/false> specified job is enabled. The job
job type: <type> type is also included in the
message.
184
Table 108 Job Messages (Continued)

time-of-day list follows Notice The job is automatically
id: <job ID> hrs:<hour> executed at all the specified
mins:<minute> times on all the specified days
secs:<seconds> of the week, within the
constraints of the absolute start
and stop time/date. This job
type has recurrence capability.
last_run_time: <time> Notice This message gives details
next_run_time: <time> about the last-run-time and the
current_weekday: <day of next-run-time of the job. It also
the week> informs you whether the job is
currently executing.
date-time-pairs list Notice The job is performed only once
follows at the exact date and time
id: <job ID> date-time: specified. This job type has no
<date, time> recurrence capability.
Table 109 Configuration Messages

Breaking config lock Notice You have not made any configuration
due to inactivity on changes for the past 15 minutes, so
session cli <session you are logged out of Configuration
number> mode.
Tried to create Warning A workgroup name is an arbitrary
invalid name: ASCII string up to 31 alphanumeric
<workgroup name> characters long.
Tried to create Warning The workspace name you tried to
invalid name, too long create is more than 31 characters long.
Found suspicious file Warning This message is logged when a bad
<filename> with spec Director image file is found.
<spec>
File <filename> is not Warning The configuration file in use is invalid.

a valid config file.
File <filename> is not Warning The specified configuration file does

in a supported config not have the right format.
file format.
Couldn't load config Warning The specified configuration file is

file <filename>, invalid.
inconsistent file
size
'admin' login and Warning This message appears when you reset
'enable' passwords Admin and Enable passwords.
reset
185
Table 109 Configuration Messages (Continued)

Workgroup \default\ Warning You tried to delete the workgroup
can not be deleted. called default. Director is shipped
with default as its default
workgroup. You can modify the
settings of the default workgroup but
you cannot delete the default
workgroup itself.
<value> is an invalid Warning Workgroup priorities are set between
workgroup priority, 0 and 4. The highest priority level is 0.
the valid range is The default priority level assigned to
<0..4> content is 4.
Table 1010Configuration Management Messages

CCD lost connection Notice_minor Director lost connection with the SG
to device <device appliance.
ID>
Device <device ID> Notice_minor This message is received when the SG

is now online. appliance is reconnected to Director.
Help Device set to Notice_minor This message is generated when you
<device ID> designate a Help Device using the
remote-config help device
command. You can set a Help Device
that can provide context-sensitive
help and command completion. You
can also save the Help Device for
future references. The Help Device is
set up until cleared.
Help Device cleared Notice_minor This message is generated when you
enter the no remote-config help
device command. You have cleared
the Help Device. The command help
is no longer available.
Device <device ID> Notice The specified SG appliance has
completed command(s) completed the execution of the listed
<cmd ID> commands.
Profile
Profile execution Notice_minor This message indicates if the backup
backup step complete during profile execution was a
for device <device success. Backups for profiles are
ID> either created automatically prior to
<success | failure> each profile application or explicitly
by request. They are stored in
Director.
186
Table 1010Configuration Management Messages (Continued)

Importing profile Notice_minor This message notifies that Director is
<profile ID> from importing the profile with the given
<device ID> ID from the specified SG appliance.
Profile execution Notice_minor This message is generated when
restore-defaults Director executes the restore-
complete for device defaults keep-console
<device ID> command, prior to applying the
profile. This command resets the
specified SG appliances
configuration, except IP connectivity.
Failed to import Notice The profile could not be pulled from
profile <profile ID> the specified SG appliance.
from device <device
ID>
Profile execute Notice This message is generated when the

failed to reboot specified SG appliance cannot be
device <device ID> automatically rebooted after the
restore-defaults keep-
console command is issued. A
profile execution is complete when
the SG appliance is automatically
rebooted after the profile is applied to
it.
Profile execution Notice After a profile is applied to an SG
rebooting device appliance, the SG appliance is
automatically rebooted.
Profile execution Notice This message notifies that the profile
reboot command execution reboot command is
complete. executed successfully. The SG
Device <device ID> appliance is rebooted and back online
is back on line with the new profile.
Profile execution Notice Director has applied the license key to
licensing applied to the specified SG appliance through a
<device> profile execution. The licenses get
applied automatically with the
profile.
Profile Notice The profile configuration commands
configuration are applied to the specified SG device.
applied to device
<device ID>
Overlay
187

Applying overlay Notice_minor This message is logged when you
<overlay ID> to issue the remote-config overlay
<keyword> <device execute command. Director has
spec> sent the overlay with the given ID to
the SG appliances, specified by the
device spec.
Overlay push Notice Director has sent the overlay to the
complete for device specified SG appliance.
<device ID>
Backup
Beginning Notice_minor This message is generated when you
restoration of enter the remote-config backup
backup <backup ID> restore command to the specified
to <device ID> SG appliance. The backup restoration
process has begun.
Backup restore- Notice_minor This message is generated when
defaults complete Director executes the restore-
for device <device defaults keep-console
ID> command, prior to applying the
backed-up configuration. This
command resets the specified SG
appliances configuration, except IP
connectivity.
<device ID> device Notice_minor The message shows whether the
<Pinning |Unpinning> backed-up configuration of a
backup <backup ID> specified SG appliance is pinned or
unpinned. Director permanently
stores a certain number of backups
per SG appliance. The pin CLI
command makes the backup
permanent in the Director. The oldest
unpinned backup is purged to make
room for the latest backup.
Deleting backup Notice_minor The specified backup is deleted from
<backup ID> from the specified SG appliance either
device <device ID>: because it is the oldest unpinned
<reason> backup or because you manually
deleted it.
Beginning to make Notice_minor This message is generated when you
backup of <keyword> issue the remote-config backup
<device spec> command to the device/ device
group, specified by the device spec.
The process of taking the snapshot of
the specified configuration has
begun.
188

Backup restore Notice This message is logged when the
failed to reboot specified SG appliance cannot be
device <device ID> automatically rebooted after the
backup restoration. Backup
restoration is complete when the
backed-up configuration is applied to
the SG appliance and the SG
appliance is rebooted.
Backup restore Notice The SG appliance is automatically
rebooting device rebooted after the backed-up
<device ID> configuration is applied to it.
Backup restore Notice This message notifies that the
reboot command backup restore command is
complete. <device executed successfully. The SG
ID> is back on line. appliance is rebooted and back online
Backup configuration with the restored configuration.
restored to device
<device ID>
Rotating out backup Notice Backups are time-stamped and

file: <backup ID> rotated out on a first-in, first-out basis
after the number of allowed backups
per SG appliance reaches the
configured maximum. You can
prevent any specific backup from
being rotated out by pinning it.
Ignoring backup file Warning The remote-config backup
<directory, backup command generates two files.
ID> with no meta
One of them contains the CLI
information.
commands that reflect the backed-up
configuration. The other file stores
the meta-information about the
backup, such as whether it is pinned
or not, etc. The given warning
message is logged when a backup file
without a corresponding meta
information file is found. In that case,
the backup file is not applied to the
SG appliance. It happens when the
file is manually deleted or when the
Configuration Manager crashes after
writing the backup file but before
creating the meta information file.
189
Table 1011Health Monitoring Messages

Fetch dashboard stats Notice Collection of statistics for the dashboard
enabled/disabled was enabled/disabled
Device <id> has invalid Warning The device serial number older
serial number <serial- platforms must be 10 digits.
number>. Must be 10
digits
Could not refresh state Warning An error was encountered trying to

for device/group refresh the health state of the device/
group.
Change status for device Notice Change the state of an alert, for example
<id>/<alert-id> to <new- from unacknowledged to
state> acknowledged.
Reached maximum number Warning Reached the maximum number of alerts
of alerts, deleting (5000), deleting the oldest.
oldest
Received an alert Warning An error was detected in the alert

without a description received from a device.
Health state for group Notice The health state for a group changed.
<id> changed from <old-
state> to <new-state>
Health state changed for Notice

device <id> from <old-
The health state for a device changed
state> to <new-state>"
Stopped snmp trap Notice Stop listening for traps.

listener
Start snmp trap listener Notice Start listening for traps.

found no matching Notice Received an alert for a device that is not
devices, drop alert managed by this Director.
CLI Informational and Error Messages

The informational and error messages that follow are those you might see while
using the CLI. For error messages on:
user problems: see Table 1012 on page 191.
Director management node front panel: see Table 1013 on page 192.
time management: see Table 1014 on page 192
SNMP: see Table 1015 on page 193.
CLI help commands: see Table 1016 on page 193.
configuration mode: see Table 1017 on page 194.
configuring your devices: see Table 1018 on page 195.
190
group management: see Table 1019 on page 195.

logging messages: see Table 1020 on page 196.
Director image file management: see Table 1021 on page 196.
content management schedules: see Table 1022 on page 197.
password authentication: see Table 1023 on page 197.
setting up RADIUS or TACACS+ servers: see Table 1024 on page 198.
Table 1012User Management Error Messages
Error Message Description

Usernames and Passwords
Your account on this system was The administrator has deleted your account.
just deleted, logging off.
The username <username> is A few usernames are reserved for Blue Coat
reserved for internal use. internal use. Each username on the system
must be unique. Choose another username.
Wrong password. If you forget your admin or enable password,
you can clear the old passwords by using the
password reset script.
Your user account does not have Standard privileges are level 1.
the required privilege to enter
Enable privileges are level 7.
<Standard | Enable|
Configuration> mode. Configuration privileges are level 15.
You are limited to the privilege level the
administrator assigned you.
Your privilege level has been You are limited to the privilege level the
lowered to <privilege level>. administrator assigned you.
User <username> does not exist. This message is displayed when you try to log
on to a machine using a username that does
not exit. Either you mis-typed the username or
the name has been deleted from the system.
User <username> already exists. This occurs when you try to create a user with
a username that is already in the system. Each
username must be unique.
Bad privilege value <privilege The privilege value should either be 1 (for
level> for user <username>. standard mode), 7 (enable mode), or 15 (for
Must be <1,7,15>. config mode) for this user.
No password given for enable. You have not set a password to enter Enable
mode.
Username can be at most 8 The username cannot be more than eight
characters. characters long.
191
Table 1012User Management Error Messages (Continued)

Username can contain only You cannot create a username with spaces or
alphanumeric characters. wild cards, forward or backward slashes,
brackets, or periods. It also must start with a
letter.
User <username> is not allowed You do not have sufficient privileges to make
to delete this user. this change.
User <username> is not allowed You do not have sufficient privileges to make
to change settings for this this change or you have not entered enable/
user. config modes.
User Directory Management
Home dir must be <= 32 chars The name of the users home directory cannot
for user exceed 32 characters.
Invalid home dir: <home The path of the home directory cannot be
directory> determined.
Table 1013LCD Error Messages
PIN should be 4 digits PIN is a four digit number.
Table 1014Time Management Error Messages
Clock
Not a valid timezone: The time zone is not a valid entry. Select another
<timezone> value. For more information on the format, refer
to the Blue Coat Director Command Line Interface
Reference.
Not a valid date string Enter the date in yyyy/mm/dd format.
Not a valid time string Enter the time in hh:mm[:ss] military format.
NTP
Cannot have an ntp peer or Local refers to the local Director management
server with a local IP node. You must synchronize the local time with
address an external NTP peer or server.
NTP version must be between 1 This refers to the version supplied with an ntp
and 4 peer or ntp server command.
ntpd already running, cannot You issued the ntpdate hostname command
do ntpdate when the NTP server is already running.
Stop the NTP server by typing no ntp enable.
Run ntpdate hostname.
Type ntp enable.
192
Table 1014Time Management Error Messages (Continued)
Cannot ntpdate to a local IP You issued the ntpdate hostname command

address with an IP address that is the same as one of the
IP addresses of the Director machine. You must
synchronize the local time with an external NTP
peer or server.
No server suitable for You issued the ntpdate hostname command
synchronization found with an invalid server name. Alternatively, the
server cannot be reached or contacted.
Table 1015SNMP Error Messages
Invalid host <hostname> You entered either an invalid hostname or an

specified invalid IP address. Alphanumeric characters,
dash ('-') and dot ('.') are allowed in a hostname.
Invalid mask length Requires a correct mask value in the format
resembling 255.255.255.0 or a mask length
such as /24.
Table 1016CLI Help Error Messages
Extraneous parameter The words that the command is rejecting are not
<parameters> would be recognized. Type the command to that point
ignored. again and enter ?.
Operation timed out. When a network connection does not respond
within a reasonable time frame, due to network
problems, this message is displayed. It also
happens when Director is waiting for response to
a command and none is forthcoming.
Type device? for help This help message (or a variation) appears when
Unrecognized command you enter invalid commands.
abcdef
Type ? for help
Extraneous parameter You have typed the command correctly, but you
<parameter> would be also entered an invalid command along with it.
ignored. You can redo the command, correcting the
extraneous parameters.
Ambiguous command 's'. When you enter a valid command with invalid
Type 'show s?' for a list of arguments, you are asked to type the ? after the
possibilities. valid part of it for a set of valid options.
193
Table 1017Configuration Management Error Messages
The configuration lock is not This is a result of the show configuration

currently held by anyone. lock-holder query. If you do not use the
Director for 15 minutes, the lock is released.
Your configuration lock was Only one person can hold Directors
broken by another user. configuration lock at any time. Users can
request that the lock be given to them.
No configuration activity for You have made no configuration changes for
15 minutes, breaking lock. the past 15 minutes. You are now in Enable
mode.
No keyboard activity for 30 You are disconnected from Director because
minutes, logging out. you did not use Director for the past 30
minutes.
Not a valid IP address: <IP The IP address you entered is invalid. Check
address> the IP address.
No requests are currently You asked Director to execute a request, but it
pending. could not find the any requests.
Image verification failed. The image fetch or image verify command
was unable to verify that the image file you
downloaded to your Director management
node was a valid image file and that its
internal checksum matched the files contents.
(image verify is only used when you do not
use the CLI to download a Director image
file.)
CLI Modes
Invalid date <date>. Please Director only recognizes dates and times
enter it in yyyy/mm/dd format. entered in the correct format. The valid format
for date is shown in the message.
Lost contact with configuration This message is displayed when Director is
subsystem, attempting busy.
reconnect...
Unable to connect to Director is busy, or the configuration

configuration subsystem. subsystem is not enabled. (If the configuration
subsystem is not enabled, reboot Director.)
ARP
arp command failed to remove The no arp IP_address command failed.

<IP address>
arp command failed to add <IP The arp IP_address hardware_address

address> command failed. Check the addresses you
entered.
194
Table 1017Configuration Management Error Messages (Continued)
Host Names
No valid hostname supplied. The command you entered requires a
hostname to execute.
Hostname: Could not set The hostname is not valid. A possible reason
hostname to <hostname> is that the hostname had illegal characters in
it. Alphanumeric characters, dash ('-') and dot
('.') are allowed in a hostname.
Table 1018SG Appliance Management Error Messages
device <Device ID> does not You entered an invalid device ID.
exist.
An SG appliance must be registered with Director
before it can be used.
<ID3> has not been defined You must add the SG appliance record
as a device information to the Director management node
before attempting to connect to it.
Device ID contains invalid An SG appliance ID cannot contain the invalid
characters ({,}) or $ characters contained in the error message.
Device IDs can only be 250 The maximum length of any SG appliance ID is
characters long. 250 characters.
For the device address Only a valid hostname, such as
please enter a hostname www.bluecoat.com, is accepted. Alphanumeric
(e.g. www.bluecoat.com) characters, dash ('-') and dot ('.') are allowed in a
hostname.
There is no registered You entered an invalid SG appliance IP address or
device with address <IP you have not registered the device. Note that an
address>. SG appliance must be registered with Director
before it can be used.
Table 1019Group Management Error Messages
Group <group ID> does not exist. You entered an invalid group ID when
attempting to do content management
commands. You must create the group/record
on the Director management node before you
can use it.
<group ID> has not been defined You are attempting to manage content on a
as a group. group you have not defined as a group to
Director.
195
Table 1019Group Management Error Messages (Continued)
There are no groups configured. The Director management node cannot list
any groups assigned to it because you have
not created any.
Group IDs can only be 250 When creating a new group, the maximum
characters long. length of any group ID is 250 characters.
Group <group name1> cannot be a Groups cannot be parents of each other.
parent of group <group name2>
because <group name2> is
already an ancestor of <group
name1>.
A group cannot be a parent of You must add the child or nested group to the
itself. parent group. You cannot add a parent to a
child.
Table 1020System Logging Error Messages
Invalid priority <log level> You entered an invalid logging priority level.
Director only accepts the terms err, warning,
notice, and notice_minor as valid logging
levels. It does not accept level numbers.
Table 1021Director Image File Error Messages
Not a valid image file: You entered an invalid software Director image
<local spec> filename. Use the correct syntax for the image file.
local_spec is the specified file. Filenames of
image files are case-insensitive.
File does not exist: <local You entered a non-existent software Director
spec> image filename. Be sure to use the correct syntax
for the image file.
Failed to install image The image fetch command was unable to install
the image file you downloaded to your Director
management node.
Image does not contain a The image fetch command was unable to verify
valid image. that the image file you downloaded to your
Director management node was a valid image file
and that its internal checksum matched the files
contents.
Could not find attribute The Director image file is corrupted or does not
<manifest attribute> in contain all the expected information. This image
manifest file file cannot be installed.
Unable to set next boot The image boot command failed.
image
196
Table 1021Director Image File Error Messages (Continued)
Invalid remote file spec: The filename or the syntax is incorrect. The error
<remote spec> Must be http:/ message provides examples of correct usage.
/server[port]/[dir/]file or
ftp://user:password@server/
[dir/]file
Failed to download file The file was not downloaded. Possible reasons: the
<remote spec> server was down, you mistyped the URL you
wanted to download.
Failed to extract manifest The image is corrupted or does not contain all the
from downloaded file <file expected information.
spec>
Failed to move/delete file You can get this message for a variety of reasons:
the disk is full, permissions are not correct, the file
was attempting to overwrite a file that is read only.
Table 1022 Job Management Error Messages
Usage Description
Invalid day <day>. Valid days are You must enter the days of the week in a
Sun, Mon, Tue, Wed, Thu, Fri, or Sat. format Director understands: For example,
mon, not Monday.
For the date and time, please enter a yyyy/mm/dd and hh:mm[:ss] are the valid
date in yyyy/mm/dd format between formats for job types.
1970/1/1 and 2038/1/18 followed by a
time (hh:mm[:ss]).
Schedule IDs can only be 250 The maximum length of any job ID is 250
characters long. characters.
Report generation was cancelled since You made a request for a job report and while
the job was deleted the request was being processed, the job was
deleted.
Table 1023Authentication Error Messages
Usage Description
Minimum key size is 512 You tried to generate an SSH host key with a
key size less than 512, the minimum key size.
The default is 1024.
Maximum key size is 32768 You attempted to generate an SSH host key
with key size greater than 2048, the maximum
key size. The default is 1024.
The SSH server cannot be You have not set up SSH on your Director
started until a host key is management node.
generated. Please use the
'ssh server hostkey rsakey
generate' command.
197
Table 1023Authentication Error Messages (Continued)
Usage Description
No RSA key found for device ID You have not set up SSH/RSA for the SG
<device ID> appliance. Generate an RSA key for the device
before connecting through SSH/RSA.
Invalid public key Make sure that you copied the entire public key
when you used the ssh client user
username authorized-key rsakey
command.
authtype values can only be When authenticating a password, you have two
(rsa, simple) valid options: RSA, which includes a public
and private key; and simple password
authentication, which is less secure than RSA.
Table 1024RADIUS Server Error Messages
Usage Description
Not a valid hostname: The hostname is not valid. Hostname should

<hostname> be a one word with no illegal characters in it.
Alphanumeric characters, dash ('-') and dot ('.')
are allowed in a hostname.
Too many radius hosts. Have There can be no more than 10 RADIUS hosts.
<number>, max is <number>
Table 1025Miscellaneous
Usage Description
protocol values can only be Connection to Director to any of the SG

(telnet, ssh) appliances must be via the Telnet or SSH
protocols. Other connection protocols are not
supported.
For the Web configuration port, The default Web configuration port is 8082.
please enter an integer between This value normally does not have to be
0 and 65535 changed.
A name server (or default The only format that Director understands is
gateway) must be an IP address the dotted-quad format. That is, all IP
in dotted-quad format (e.g. addresses should be of the format
10.25.36.47) 10.25.36.47.
A domain name must be a Do not attempt to use an IP address for a

hostname (e.g. domain name. Domain name should be of the
www.bluecoat.com) format specified in the message.
198
This appendix describes how to administer Director using the CLI. The
following table describes common administration tasks and where to go to get
more information.
Table A1 Common Director Administration Tasks
To... Go to...
Change Director Defaults "Changing Director Defaults" on page 199
Set up users "Setting Up Users" on page 200
Authenticate users "Authenticating Users" on page 204
Change the connection "Determining the Connection Protocol" on page 209

protocol for Director
Set SNMP traps and levels "Using the SNMP Server" on page 213
Reboot Director "Rebooting Director" on page 213
Shut down Director "Shutting Down Director" on page 214
Upgrade the Director to a "Upgrading Director" on page 214

new image
Downgrade to an earlier "Downgrading to an Earlier Version of Director" on

Director image file page 221
Archive and restore "Managing Director Configuration" on page 223

Director configuration
Authenticating Director "director (config) # reload Connection closed by foreign

using Appliance host." on page 228
Certificates
Changing Director Defaults

Defaults for Director administration are:
Adding user accounts to Director: Admin with no password is the default
and the only user account. If others will use Director and you do not want
them to have administrator privileges, you should add user accounts. See
"Creating Local User Accounts" on page 200 to add other user accounts to
the Director management node.
Changing security options from local to RADIUS or TACACS+: Local is the
default and is required. See "Authenticating Users" on page 204 for more
information.
199
Changing the connection protocol and authentication: SSHv2 with simple

password authentication is the default. You can add RSA authentication for
more security or use Telnet. See "SSH" on page 209 for more information.
Adding Access Lists: These must be configured for each interface. See
"Managing Security Through Access Lists" on page 211.
Enabling FTP and SNMP The default for each is disabled. See "Using Telnet
and FTP Servers" on page 212 and "Using the SNMP Server" on page 213 for
more information.
Setting Up Users
The username commands allow you to create local user accounts on the Director
management node. After the usernames are created, you can change the
workgroup to further control the users on the system.
Creating Local User Accounts

The default account is admin, with no password. This is probably the account you
want to use to administer Director itself. Another account, monitor, also exists by
default on Director. It is meant to allow someone to view configuration changes to
the system.
You can create other accounts with different privileges and require users to use
one of those accounts instead of admin. (If you do decide to create user accounts
on Director, put a password on the admin account to prevent users from logging
on with full privileges.)
The user accounts you create can be as secure as you want them, from no
password to restricting users to one of the modes: Standard, Enable, or
Configuration. Restricting users to one of the modes is called setting the privilege
level. All user accounts, by default, have all privileges.
If the privilege level is:
1: Standard mode only is available, meaning that you can view Director logs
and the results of commands but you cannot change them.
7: Standard and Enable modes are available, meaning you can do one-time
tasks, but cannot schedule repeating tasks or configure devices or device
groups.
15 (the default): All three modes are available, including Configuration mode,
the most powerful. You can schedule jobs, manage content, and manage users.
You can also make permanent changes to Director configuration.
If the privilege level is changed during a session, the new privileges take effect
immediately.
The username commands create local user accounts on the Director management
node only. They do not affect the accounts on remote authentication servers.
200
Note: If you create a password on the Director management node for local user
accounts, that password is kept in a local password file. However, if you have
users logging in remotely or through unsecured terminals, you can require an
additional level of authentication. For more information, see "Authenticating
Users" on page 204.
For more information on creating usernames, refer to the Blue Coat Director
To set up a user account on the Director management node with privilege

restrictions:
1. At the (config) command prompt, set the username and password. Note that
only the first eight characters of the username and password are validated.
Director (config)# username username
Director (config)# username username password 0 | 7 password
where 0 indicates the password to be entered is in plaintext, and 7 indicates

the password to be entered is encrypted.
2. Set the privilege level.
Director (config)# username username privilege 1 | 7 | 15
where 1 means that the user cannot enter the Enable mode, 7 indicates that the
user cannot enter Configuration mode, and 15 indicates that the user has full
administrative privileges.
3. View the users on the system.
Director (config) # show usernames
Username admin
maximum permitted privilege level 15
in Workgroup "default"
Username monitor
Username test1
Note: Every user is automatically assigned to Workgroup Default. To change

the workgroup assignment, continue with the next section.
4. Save the configuration.

Director (config)# write memory
Managing Users Who Manage Content

You can place users who are issuing content management commands to devices
into workgroups and use the workgroups to limit the devices they can use, the
time they can send commands, or limit the priority level (importance) they can
assign to content.
201
Director ships with a workgroup called default, and all Director users are members
of the group until they are re-assigned to a new workgroup. If the new workgroup
is deleted, members of that group are re-assigned to the default group.
You can modify the settings of the default workgroup but you cannot delete the
default workgroup itself. By default, all users can schedule any content
commands at any time to any SG appliance, and can set the priority level of
content to any setting between 0 and 4. (Zero is of greater importance than 4.)
Any jobs that are scheduled for a stated time are enforced using the permissions
of the default workgroup, no matter which workgroup the user belongs to.
The workgroup commands are only effective if Director users have differing
privilege levels. It is meant for users who are managing content on Director, not
managing Director itself. Only the Director administrators should have level 15
privileges with no restrictions.
You can only create and manage workgroups through the Director CLI. Note,
however, that all users, including those who work exclusively with the Director
Management Console, are assigned to the default workgroup unless they are
moved to another workgroup, and are subject to the rules of the workgroup
where they are assigned.
Note: You can move users from the default workgroup to other workgroups. You
cannot add new user accounts to Director through the workgroup commands.
Follow these steps to create a workgroup and add rules and users
1. At the (config) command prompt, create a workgroup and give it a
meaningful name.
Director (config) # workgroup workgroup_id create
where workgroup ID is an alphanumeric string that is a descriptive name,

such as sales.
2. (Optional) Enter the workgroup submode, which allows you to use workgroup
commands without having to type workgroup workgroup_id before each
command.
Director (config) # workgroup sales
Director (config workgroup sales) #
3. (Optional) Add a comment to the workgroup.

Director (config workgroup sales) # comment comment
4. Set a minimum priority level for content managed by the users in the
workgroup.
Users are unable to make content more important (have a higher priority)
than the minimum level you have set. The range is between 0 and 4, with 0
meaning that users have no restrictions on setting the importance of content in
the SG appliances. Negating this command returns priorities to the default, 0,
which is the highest priority.
202
Director (config workgroup sales) # min-priority priority integer
5. Set up time limit rules for the workgroup to enable or disable the time-limits
range.
a. Time-limits type: The default is disallow, meaning that if no time
limits are set, all users can manage content at any time. Before you set
a time range, change the time limit type to allow to restrict users to
predefined times.
Director (config workgroup sales) # time-limits type allow |
disallow
b. Time limits. The default is that no time limits are set, allowing all users
to manage content at any time. If the time-limits type is allow, setting a
time limit prevents users from sending content management
commands outside of the time limits established. If time limits are
established and the time-limits type is disallow, users cannot manage
content during the specified time, but can manage content at other
times.
Director (config workgroup sales) # time-limits range hh:mm:ss-
hh:mm:ss
where the time is set using the 24-hour clock.

6. Set up SG appliance rules for the workgroup.
a. Set up a device-limits typeallow or disallowto enable or disable
SG appliance lists on the workgroup. The default is disallow, meaning
that access to all SG appliances is unrestricted by all users in this
workgroup. Before you add SG appliances to the workgroup, change
the device-limits type to allow.
Director (config workgroup sales) # device-limits type allow |
disallow
b. Limit SG appliances that workgroup users can access. If the list exists,
only SG appliances and groups on the list can be accessed by members
of the workgroup.
If the group ID or device ID record does not exist, it is not created. An
error message is generated instead.
Director (config workgroup sales) # device-limits keyword device
spec
where keyword is all, device, addr-device, or group, and device spec

indicates the following rules:
all refers to all devices.
device must be followed by a device ID.
addr-device must be followed by a hostname/IP address.
group must be followed by a group ID. Do not use an IP address.
7. Add users to the new workgroup.
203
This removes users from the default workgroup, since users can belong to
only one workgroup at a time. If the workgroup is later deleted, users are re-
assigned to the default workgroup. (If you delete a workgroup, assign the
workgroup members to other groups beforehand, unless you want the
workgroup members re-assigned to the default group.)
You cannot use this command in workgroup submode.
Director (config workgroup sales) # exit
Director (config) # username username workgroup member workgroup ID
8. View the workgroup you created:

Director (config) # show workgroup workgroup_name
Workgroup workgroup_name:
Comment: this is a test
Minimum Priority: 4 (lower number has more priority)
Device-limits Type: allow (to send content commands to these following
Groups
& Devices:)
All Device-Groups and Devices
Time-limits Type: allow (to send content commands during these time
ranges:)
Time ranges for this Workgroup:
07:00:00-17:00:00
9. View the usernames to see which users are in which group:

Director (config) # show usernames
Username admin
Username monitor
in Workgroup "test1"
Username test1
in Workgroup "test1"
10. Use the write memory command to permanently save your changes.
Director (config) # write mem
Authenticating Users
Possible authentication methods are Remote Authentication Dial-In User Service
(RADIUS), Terminal Access Controller Access Control System Plus (TACACS+),
and local. Local authentication is required. RADIUS and TACACS+ are optional.
To configure RADIUS authentication, continue with the next section; to configure
TACACS+ servers, skip to "Configuring TACACS+" on page 208.
Note: Because Director supports authentication using RADIUS/TACACS+, the

remote usernames do not need to be configured on Director. Usernames and
passwords for remote users, however, are restricted to 16 bytes. If the username is
longer, the authentication/login attempt fails.
204
Configuring RADIUS
If the authentication request consists of the service-type as framed, RADIUS sends
back the attributes for the user in the authentication response. These attributes
can be used for authorization.
Director assigns a privilege level to match the service-type value on RADIUS.
Only the service types that are configured here are supported; access to Director is
denied if the service types do not match the mapped service types in the
configuration.
Director has three privilege levels:
Login (level 1)
Enable (level 7)
Config (level 15)
Each service type you want supported must be mapped to one of the above
privilege levels. Only three service types can be supported, one for each Director
privilege level. All other service types are ignored. If the service type found in the
mapping does not match one of the configured service types, the privilege of the
user cannot be decided and the login is rejected.
By default or on a new system, the following services types are mapped:
RADIUS Service Type Director Mapping
Login Login
NAS-Prompt Enable
Administrative Configuration
You do not need to configure service types on Director unless you want to change
the default mappings.
Note: If the service type is set to Framed, Outbound, or Authenticate-Only, or not set
at all, you will get a Login incorrect error message even if the supplied username
and password are valid.
To configure RADIUS server setup on Director:

1. At the (config) command prompt, specify the types of authentication you
will use.
Director (config)# aaa authentication login default local [radius
tacacs]
While local must be specified, you can specify one, neither, or both of the
other two authentication methods. The search is done in the order specified in
the aaa authentication command. Note that if you are using RADIUS only,
you do not need to configure TACACS+.
2. Enter the following commands to configure global settings for RADIUS
servers:
205
Director (config)# radius-server key password

Director (config)# radius-server request-stype
integer_between_1_and_11
Director (config)# radius-server response-stype
integer_between_1_and_11 \ privilege 1 | 7 | 15
Director (config)# radius-server retransmit integer
Director (config)# radius-server timeout integer
where
key password Sets the authentication and encryption key for
RADIUS servers. Note that this is not a key, such as an
SSHv2 key, but a password.
The key cannot have a question mark in it (such as
xyz?) unless you first disable Director CLI help.
request- 1 - 11 Sets the RADIUS request service type. The integer
stype stands for the service type, which can be one of the
following:
1. Login
2. Framed
3. Callback Login
4. Callback Framed
5. Outbound
6. Administrative
7. NAS Prompt
8. Authenticate Only
9. Callback NAS Prompt
10.Call Check
11.Callback Administrative
response- 1 - 11 Links the RADIUS response service type and privilege
stype level. Director privilege levels are 1 (Standard mode),
7 (Enable mode), and 15 (Configuration mode). The
service types must be linked to one of the Director
levels.
retransmit integer Sets the number of retries allowed for connection to
the RADIUS servers.
timeout integer Sets the timeout value. It should be of the format nnh
nnm nns, where nn is the number, h is the hour, m is the
minute, and s is second, such as radius-server
timeout
05h 30m 10s.
3. Enter the following commands to configure a RADIUS server and override

the global defaults. If you do not need to overwrite the defaults, you do not
need to set them.
206
Director (config)# radius-server host hostname_or_device_id

Director (config)# radius-server host hostname_or_device_id acct-port
\ port-number
Director (config)# radius-server host hostname_or_device_id auth-port
\ port-number
Director (config)# radius-server host hostname_or_device_id key
password
Director (config)# radius-server host hostname_or_device_id request-
stype \ integer_between_1_and_11
Director (config)# radius-server host hostname_or_device_id response-
stype \ integer_between_1_and_11 privilege 1 | 7 | 15
Director (config)# radius-server host hostname_or_device_id retransmit
integer
Director (config)# radius-server host hostname_or_device_id timeout
integer
where
acct-port port- The default is 1813.
number
auth-port port-number The default is 1812.

key Overrides the global setting for RADIUS
servers for this system only. If you need to
change the key, you must also set the auth-
port number.
request-stype Overrides the global setting for RADIUS
servers for this system only.
response- Overrides the global setting for RADIUS
stype servers for this system only.
retransmit Overrides the global setting for RADIUS
timeout Overrides the global setting for RADIUS
4. View the configuration of the RADIUS servers.

Director (config) # show radius
Radius server configuration:
Global timeout: 19800 seconds
Global number of retransmission attempts: 5
Global key: test1
Global request-stype: 3
Global privilege-response mapping:
Privilege 1 :
Privilege 7 :
Privilege 15 : 3
Server 10.25.36.47:
Accounting port: 1813
Authorization port: 1812
Timeout:
Number of retransmission attempts:
Key:
request-stype:
207
privilege-response mapping:
Privilege 1 :
Privilege 7 :
Privilege 15 :
Director (config) #
Configuring TACACS+
1. At the (config) command prompt, specify the types of authentication you
will use.
Director (config)# aaa authentication login default local [radius
tacacs]
While local must be specified, you can specify one, neither, or both of the
other two authentication methods. The search is done in the order specified in
the aaa authentication command. Note that if you are using TACACS+ only,
you do not need to configure RADIUS.
2. Enter the following commands to configure global TACACS+ server settings:
Director (config)# tacacs-server key password
Director (config)# tacacs-server timeout integer
where
password sets the authentication and encryption key for TACACS+ servers. Note that this
is not a key, such as an SSHv2 key, but a password.
timeout integer sets the timeout value. It should be of the format nnh nnm nns,
where nn is the number, h is the hour, m is the minute, and s is second, such as
radius-tacacs timeout 05h 30m 10s.
3. Enter the following commands to configure the TACACS+ server:

Director (config) # tacacs-server host hostname_or_device_id key
password
Director (config) # tacacs-server host hostname_or_device_id port
port-number
Director (config) # tacacs-server host hostname_or_device_id single-
connection
Director (config) # tacacs-server host hostname_or_device_id timeout
integer
where
key password Sets the authentication and encryption key for

TACACS+ servers. Note that this is not a key, such as
an SSHv2 key, but a password.
port port- The default is 49. You do not need to use the port
number option unless you want to use a different port-
number.
single- Sets single-connection mode for this server. The
connection default is yes.
208
timeout integer Sets the timeout value. It should be of the format nnh
nnm nns, where nn is the number, h is the hour, m is
the minute, and s is second, such as radius-server
timeout
05h 30m 10s.
4. View the TACACS+ server configuration:

Director (config)# show tacacs
TACACS+ server configuration:
Global key: test2
Global timeout: 16200 seconds
Server 10.9.17.159:
Port: 49
Timeout: 9000 seconds
Key: test3
Single connection: yes
5. Confirm that all the methods of authentication were set up.

Director (config)# show aaa authentication login
Authentication methods:
1. local
2. radius
3. tacacs+
Note: TACACS+ users are allowed full authentication privileges, but

authorization is not supported with TACACS+. Authorization is only
supported for local and RADIUS.

Determining the Connection Protocol

Director allows you to connect SG appliances to the Management Console and
management node through the SSH v2 Simple or SSH/RSA protocols. Director
uses SSHv2 by default.
Note: If you use SSHv2 to connect to the SG appliance or to the Director

Management Console, no additional configuration is needed, since both Director
and the SG appliance use SSHv2 as the default connection protocol.
SSH
For Director, Blue Coat allows you to connect through:
SSHv2 and simple password authentication (the default)
SSHv2 and RSA authentication
209
Blue Coat strongly recommends you use SSH/RSA to communicate between both
the Director Management Console and the management node and Director and
an SG appliance. SSH/RSA provides the most secure connection protocol.
To generating an SSH-RSA Key for communication between the management

node and the management console:
1. From the (config) prompt, enter the following commands:
Director (config) # ssh server hostkey rsakey generate sshv2

To add an SSH-RSA key from a known host:

To set up SSH and RSA, you must generate a keypair using the ssh-keygen -t
utility on a UNIX system. Identities created using other utilities are not
supported, and Blue Coat does not currently support password-encrypted
identity files. After the key is created, copy the public key to the clipboard.
Note:The maximum key size is 1024 bits, and trailing newline characters must be
removed from the key before it is imported.

Director (config)# ssh server knownhost host_name_or_IP_address rsakey
key_size exponent extremely_long_list_of_numbers_you_copied_from_the_
knownhost_keypair_file
where
knownhost knownhost is a host known to Director. By adding a knownhost
key to Director, Director only connects to hosts it knows about.
Then, if the key on the knownhost changes, Director refuses to
connect to that device until the new knownhost key is added to
Director.
hostname or The ID of the device.
IP_address
rsakey Add or change a known host public key for the specified user.
length The length of the key, generally 1024.
exponent The exponent of the key, generally 35.

To set authentication options:

1. From the (config) prompt:
Director (config)# ssh server auth allowpassword | allowrsa
210
where allowpassword permits users to authenticate using a password and

allowrsa permits users to authenticate using RSA.

Managing Security Through Access Lists

Access lists allow you to manage security on your network more efficiently. You
can mark all packets from a certain network to be dropped, or you can disable
certain services (protocol/port combinations) for a particular interface. Access
lists are configured per interface, and, if they are present, Director checks all
incoming/outgoing packets.
Since Blue Coat assumes there is some overlap among rules in the same access-
list, these lists are not checked for contradictions.
Follow these steps to create an access-list and apply rules to it.
1. At the (config) command prompt, create an access list name.
Director (config)# access-list access-list_id
Note: This also puts you into the access-list submode, which allows you
to use access-list commands without having to type access-list
access-list_id before each command. To edit a different access-list, just
enter the new access-list name.
Director (config acl ID)# access-list new_id
2. Create rules to filter protocols and users.

Syntax for the access-list commands are:
access-list-name {permit | deny | reject} protocol {any | snetaddr |
smask | host saddr} {any | dnetaddr dmask | host daddr} [log]
where snetaddr, smask, and saddr refer to the subject machines, and dnetaddr,
dmask, and daddr refer to the destination machines.
a. Create an optional comment to be applied to the next rule you enter.

Director (config acl new_id)# comment optional_comment
b. Allow everyone to browse the Web.

Director (config acl new_id) # permit ip any any
c. Select redirect as the ICMP type.

Director (config acl new_id) # permit icmp any any redirect
If you do not specify a type, all ICMP message types match the rules.
d. Eliminate browsing privileges for a specific group:
Note: The network mask entered is of format 0.0.255.255, the opposite

from the way netmasks are used in normal interface address
configuration.
211
Director (config acl new_id) # deny tcp eq www 10.1.2.0 0.0.0.255 \

0.0.0 255.255.255.255
For more information on setting up access lists, refer to the Blue Coat Director
1. Save the changes.
Director (config acl new_id)# exit
2. View the access-list to be sure the rules are there. Each rule is numbered.
Director (config)# show access-list new_id
Access-list jf, type filter:
0: permit 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ip
1: deny 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 tcp
2: permit 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 icmp
redirect
3: deny 10.1.2.0 0.0.0.255 0.0.0.0 255.255.255.255 tcp eq www
Using Telnet and FTP Servers

Director allows you to enable and disable the Telnet server on the Director
management nodes. The default is disabled for each connection to increase
security on Director. Telnet allows the Management Console to connect to
Director using Telnet protocol as well as SSH.
FTP allows you to upload URL lists to Director, which Director can then use to
start content commands such as content distribute urls-from file:///.
Telnet allows the Management Console to connect to Director using Telnet
protocol as well as SSH.
To enable Telnet and Telnet servers:

1. At the (config) command prompt, enable FTP and Telnet connections.
Director (config)# ftp-server enable
Director (config)# telnet-management enable

To disable FTP and Telnet servers:

1. At the (config) command prompt, disable the FTP or Telnet server.
Director (config)# no ftp-server enable
Director (config)# no telnet-management enable

For more information on Director CLI commands to manage FTP and Telnet
server connections, refer to the Blue Coat Director Command Line Interface Reference.
Note: Telnet disconnects after three invalid attempts to connect. There also might
be a time lag before Telnet reports on device status.
212
Using the SNMP Server

Director allows you to enable and disable SNMP server connections on the
Director management nodes. You can also set the:
Read-only community name
If a community name is specified, this community name overrides the setting
of the snmp-server traps default-community, which is public. To clear this
override without removing the host from the list, reissue the snmp-server
host command without a community name. Community names should not
have any spaces.
Contact string
Specific hosts to receive SNMP notifications
Location string
Certain SNMP trap options
Certain SNMP inform options
Director supports MIB-II RFC1213.
To enable the SNMP server:
1. At the (config) command prompt, enable SNMP connections.
Director (config)# snmp-server enable

Note: If you do not save the configuration by entering the write memory
command, the changesyou made are not permanent and are lost at the next
reboot.
To disable the SNMP server:

1. At the (config) command prompt, disable SNMP server connections.
Director (config)# no snmp-server enable
2. Disable all authtraps, inform and SNMP traps.

Director (config)# no snmp-server enable authtraps
Director (config)# no snmp-server enable inform
Director (config)# no snmp-server enable traps

For more information on Director CLI commands to manage the SNMP server
connections, refer to the Blue Coat Director Command Line Interface Reference.
Rebooting Director
Enter the following command to reboot the system:
Director (config) # reload
213
You will receive the following confirmation message:

Connection closed by foreign host.
Note: During the reboot process, the configd and CLI can shutdown in any order.
If the configd shuts down first, the CLI identifies the connection loss and logs the
message.
Shutting Down Director

To shut down the Director, use the reload halt command. Do not disconnect the
power cable (or switch off the SG 800 appliance) to shut down Director.
Disconnecting the power cable can lead to unexpected failures and database
corruption.
To shut down Director:

1. Connect to the Director serial console.
Note: You can also connect to the CLI through SSH but you will not get a
system messages indicating that it is safe to power down the Director.
2. Enter the following command to shut down Director:

Director # reload halt
or
Director # reload halt force
Use the reload halt force command if you do not want to save any
configuration changes.
3. Unplug Director when the serial console indicates that it is safe to do so:
Director 510: The hardware LCD panel goes blank and powers down. The
serial console displays Power down.
Director 800: The hardware LCD panel goes blank. The serial console displays
'
The operating system has halted
Please press any key to reboot
Upgrading Director
You can upgrade Director hardware to the latest image of Director. Upgrading the
image is a three-step process: creating an archive of the current configuration,
downloading the image file to the Director management node, and installing the
image on the management node. The software upgrade process for the Director
800 is different than for the Director 510. See "Director 800 and 510 Upgrade
Differences" on page 215 for more information.
Note: This procedure must be done through the command line. You cannot use
the Management Console to upgrade Director.
214
Upgrade Recommendations
Before upgrading Director, do the following:
Archive the current Director configuration. Follow the procedure described in
"Archiving and Restoring the Entire Director Configuration" on page 225.
Use the write memory command to permanently save any changes you made
to the configuration. As part of the upgrade procedure, Director is rebooted,
meaning that any changes not made to permanent memory before the reboot
are lost.
Upgrading the Director 800 or Director 510

To upgrade a Director 510, read "Director 800 and 510 Upgrade Differences" on
page 215 and "Upgrading Software on the Director 510" on page 217.
To upgrade a Director 800, read "Upgrading a Director 800" on page 219.
Director 800 and 510 Upgrade Differences

The Director 510 runs on Linux instead of NetBSD. As a result, changes have been
made to Director upgrade/downgrade behavior. These changes are discussed in
the following sections.
Determining the Platform Version

To determine if your Director platform is a 510 or an 800, enter the following
command in the Director CLI:
Director (config) # show upgrade-package
If your Director is a 510, the command displays the available upgrade packages
and the current 'show version' output.
If your Director is an 800, the CLI displays the following error: Unrecognized
command 'upgrade-package'.
Director 510 Upgrade/Downgrade Changes

The Director 510 uses SGME upgrade packages (.tgz files), and not images (as on the
Director 800), to upgrade the system software. The Director 510 supports SGME
5.1.3.1 and later. SGME 4.2.3.x is not supported on the Director 510 but is
supported on the Director 800.
Note: The image command is not present on the Director 510; it has been replaced by
the upgrade-package command. See "Upgrading Software on the Director 510" on page
217 for more information.
When a user installs an upgrade package, Director takes a snapshot of the currently-
running operating system and preserves it for downgrading purposes. This re-packaged
operating system is the only release that users can downgrade to. The installation/
snapshot process overwrites any existing operating system that was previously re-
packaged.
The differences between the 510 and 800 Director upgrade/downgrade process are
described in the following table.
215
Table A2 Upgrade/Downgrade Differences
Task Director 510 (Linux) Director 800 (NetBSD)
Users can upgrade to Yes. Yes.

a newer release
Users can downgrade No. Yes.

to arbitrary releases Director stores only one Director stores multiple image
release (the previously- versions.
running release) for
downgrading.
Users can install No. Yes.

multiple releases When an upgrade package Multiple images can be saved
is installed, Director takes a and rolled back to.
snapshot of the currently-
running release and saves it
for rollback purposes.
Example
An administrator wants to upgrade a system that is running 5.1.3.1. The
administrator installs a 5.1.4.2 upgrade packageduring the installation, the
5.1.3.1 release is re-packaged. If the administrator later decides to install a 5.1.4.7
patch release, the administrator must remember that the saved 5.1.3.1 repackage
will be overwritten when 5.1.4.1 is repackaged and saved.
Note: The 5.1.4.7 release described in the this example is hypothetical and is meant only
to illustrate the upgrade process. See "Upgrading a Director 800" on page 219for the
current Director 800 upgrade path.
Table A3 Normal upgrade path
Installed Release Rollback Release
5.1.3.1 None
Upgrade to 5.1.4.1 5.1.3.1
Upgrade to 5.1.4.7 5.1.4.1 (5.1.3.1 is

automatically deleted)
Example (continued)
Because 5.1.3.1 was a stable release, the administrator would like to be able to
downgrade to it after installing 5.1.4.7. To do this, the administrator must
downgrade from 5.1.4.1 to 5.1.3.1 before installing the 5.1.4.7 patch release. Then,
when the administrator installs 5.1.4.7, the 5.1.3.1 release is re-packaged (and the
5.1.4.1 snapshot is overwritten).
216
Table A4 Upgrade path to ensure rollback to 5.1.3.1
Installed Release Rollback Release
5.1.3.1 None
Upgrade to 5.1.4.1 5.1.3.1
Downgrade to 5.1.3.1 5.1.4.1
Upgrade to 5.1.4.7 5.1.3.1
Upgrading Software on the Director 510

The following list describes the high-level software upgrade process for the
Director 510:
Download the .tgz package file.
Install the package file.
At this point, the required re-package of the current running system is created.
You can downgrade only to this re-package.
Reload or reboot the system.
Important: Before performing any software upgrade, back up the appliance

configuration.
To obtain the Director image file:

1. Connect to the Blue Coat download site.
https://download.bluecoat.com/release/SGME/index.html
2. Fill out the software license form.

3. Click the Submit button.
The e-mail with the URL link should be sent to you immediately.
4. Review the release notes by clicking on the release notes in the SG
Management Edition pane on the right-hand-side of the download site.
5. Click on the link sent to you and copy the .zip file to your desktop.
6. Copy the dir image to a Web server that Director can access. (The idir image is
used for re-manufacturing the Director system.)
To install the upgrade package on the Director management node:

1. At the (config) command prompt on Director, download the upgrade-
package by pasting the dir files URL and adding the Blue Coat username and
password.
Director (config) # upgrade-package fetch complete_path_of_upgrade-
package_.tgz_file
For example: http://releases.upgradedirector.com/director-5.1.3-

1772.tgz.
217
Enter the upgrade package URL in one of the following formats:

http://<hostname[:port]>/<path>
https://<hostname[:port]>/<path>
ftp://<hostname>/<path>
scp://<hostname>/<path>
Specifying a username and password in the URL is not supported.
1. OptionalVerify the installation package (this command is useful if you did not use
the CLI to copy the upgrade package to local disk).
Director (config) # upgrade-package verify filename
2. Install the new Director image file you just downloaded.

Director (config) # upgrade-package install filename
During installation, a snapshot of the current OS version is packaged and

saved so you can roll back to it later. The SG appliance reboots.
3. Verify Director booted from the correct image file by re-connecting to Director
and using the show version command.
ssh -l username IP_address_of_management_node
Director > show version
System version: 5.1.1.1
Build date: 2006/08/07 19:46:53
Build number: 26653
Build version: #26653 2006.08.07-194653
Serial number: 0000000000
Related CLI Commands for Upgrading the Director 510

On the new Director, the image command has been replaced by the installation
command upgrade-package. The syntax of the upgrade-package command is as
follows:
Director (config) # upgrade-package delete filename
Deletes the specified upgrade-package.

Director (config) # upgrade-package fetch url username password
Retrieves the upgrade-package from the specified location, places it on the local disk
with the identical filename, and verifies that it is a valid system upgrade-package.
Enter the upgrade package URL in one of the following formats:
http://<hostname[:port]>/<path>
https://<hostname[:port]>/<path>
ftp://<hostname>/<path>
scp://<hostname>/<path>
Specifying a username and password in the URL is not supported.

Director (config) # upgrade-package install filename
Installs the specified upgrade package. During installation, a snapshot of the

current OS version is packaged and saved so you can roll back to it later.
Director (config) # upgrade-package rollback
218
Revert to the previously installed system.

Director (config) # upgrade-package verify filename
Verifies the validity of the specified upgrade package. Because the upgrade-package
fetch command verifies the upgrade package, this command is useful only if you did
not use the CLI to download the upgrade package.
Upgrading a Director 800

To upgrade a Director 800, you must obtain the upgrade package and then install
the image file on the Director management node.
To obtain the Director upgrade package:

1. Go to the Blue Coat download site.
http://download.bluecoat.com/release/SGME5/index.html
2. Using a browser, navigate to http://download.bluecoat.com/release/

SGME5/index.html# and follow the instructions to receive the download link.
3. Review the release notes by clicking on the release notes in the Blue Coat SG
Management Edition pane on the right-hand-side of the download site.
4. Click on the link sent to you and copy the .zip file to your desktop.
5. Copy the dir image to a Web server that Director can access. (The idir image is
used for re-manufacturing the Director system.)
To install the image file on the Director management node:

1. At the (config) command prompt on Director, download the new image file
by pasting the dir files URL and adding the Blue Coat username and
password.
Director (config) # image fetch complete_path_of_image_file username
your username
Password:
Image downloaded OK.
Image verifies OK.
Director (config) #
Note: When /sys is full, the image fetch command might fail with an
incorrect error message: % Failed to download file: Failed writing
body.
You can delete extra image files with the image delete filename command.
2. Run the show image command to see the correct name of the new Director
image file.
Director (config) # show image
Install packages on the system:
(none)
219
File dir-x-4.0.0.0-021930.img:
OS type: dir
Release: 4.0.0.0
Number: 021930
Size: 23734224 bytes
Platform: x
File dir-x-3.2.1.0-020834.img:
OS type: dir
Release: 3.2.1.0
Number: 020834
Platform: x
Free space remaining: 1.7 gigabytes
Note: The message: Install packages on the system: (none) is benign and
does not indicate that the Director image file was not successfully
downloaded.
3. Change the boot image to the new Director image file you just downloaded.
Director (config) # image boot copy_and_paste_new_image_name
4. Save the changes. If you dont save the changes, the system will reboot to the
previous Director image file.
Director (config) # write memory
5. Reboot the system.

6. Verify Director booted from the correct image file by re-connecting to Director
and using the show version command. The result should contain the same
version information as show boot command.
ssh -l username IP_address_of_management_node
Director > show version
System version: 3.2.1.0
Build date: 2004/03/16 14:04:27
Build number: 20834
Build version: #020834 2004.03.16-140427
Director >
Upgrade Changes
During upgrade, a single configuration file is split into multiple files
containing individual overlays and profiles. All of these files are encrypted
and cannot be directly manipulated.
A new command, config destroy-old-files, is provided to allow you to
delete the insecure files (stored in plaintext). This command should not be
used if you ever plan to downgrade to an earlier version, because it destroys
all old configuration and backup files, leaving you with no easy way to access
the downgraded system.
220
Destroying Old Configuration Files After an Upgrade

Important:This command should only be used if you do not plan to ever
downgrade your system.
The destroy-old-files command is designed to make your system more secure

by deleting configuration files that store information in plaintext. However, after
this is done, any downgrade to an earlier version is done without the
configuration files and backups that previously were created in that release.
Configuration files are stored in three locations, depending on the version of
SGME:
3.x: /sys/config and /local/backups
4.x: /sys/encrypted-config/ and /local/encrypted-backups/
5.x: /sys/v5-config and /local/encrypted-backups/
Note: This is a global command, deleting all files in /sys/config/, sys/

encrypted-config, /local/backups/, and /local/encrypted-backups for SGME
3.x and 4.x. SGME 5.x files are not affected.
To destroy all configuration files from previous versions:

Director (config) # config destroy-old-files
Destroying old files makes them unavailable to downgraded systems.
Proceed to destroy? (yes or no) yes
Destroyed old files.
2. Do not save these changes. That is, do not use the write memory command.
3. Reboot Director.
Connection to Director closed.
Downgrading to an Earlier Version of Director

You can downgrade to any version of SGME 2.1.09 or higher that is already on
your system, but you start with an empty configuration file except for the IP
address settings.
1. To downgrade to an earlier version, view the Director image files on the
system using the show images command.
Director (config) # show images
Install packages on the system:
(none)
Installed images on the system:
File dir-x-2.1.00-002803.img:
OS type: dir
Release: 2.1.00
Number: 002803
Platform: x
221
File dir-x-2.1.06-PR-5-019709.img:
OS type: dir
Release: 2.1.06
Number: PR
Platform: x
File dir-x-2.1.9.0-020406.img:
OS type: dir
Release: 2.1.9.0
Number: 020406
Platform: x
File dir-x-3.2.1.0-021078.img:
OS type: dir
Release: 3.2.1.0
Number: 021078
Platform: x
2. Determine the version you want to downgrade to, and make that version the
bootable image by copying and pasting the filename.
Director (config) # image boot dir-x-2.1.9.0-0202406.img
Director (config) # write memory
If you do not save the version to boot to permanent memory before you
reboot, the image Director uses is the last image booted, not the one you just
made the bootable image.
3. Reboot the Director management node.
Restoring the Configuration Files

If you downgrade to 3.2.2.0, you can restore the configuration files and delete the
SGME 5.x configuration files.
Important: If you previously used the config destroy-old-files command, no

configuration files from any version lower than SGME 5.x are available. Files
removed through the config destroy-old-files command are irretrievable.
To restore SGME 3.x configuration files:

Director (config) # config restore-sgme3-files
Proceed to restore-sgme3 ? (yes or no) yes
Use "reload force" for this operation to complete.
2. Reboot Director.
Director (config) # reload force
Connection to Director closed.
222
Notes
When a downgrade is detected:
The configuration file is renamed based on its version.
New Director CLI commands are added to effectively do a show config on any
saved configuration database file. This can then be used to extract whatever
information the user needs into the new, blank configuration.
On a downgrade, the higher versions configuration file is saved, and a new
one is created with only the IP address settings.
If you attempt to later switch to the saved file (by default called something similar
to initial-1.0-79) you will receive critical messages and errors. To restore parts
of the configuration, use the command show config files initial and then
manually copy and paste the configuration.
Managing Director Configuration

You can save the Director management node configuration, upload it to a secure
location, download it, and restore the configuration.
Note: These procedures must be done through the command line. You cannot use
the Management Console to back up Director.
Saving the Director Management Node Configuration

You can save the active configuration either to disk or to a file. You can switch to
any saved configuration at a later time.
To save a configuration:
From the (config) prompt, enter the following commands:
Director (config) # configuration write
-or-
Director (config) # configuration write to filename
where:
write permanently saves the active configuration. (You can revert changes made
to the active configuration before they are saved to disk. After the changes have
been written to disk, you cannot revert them. To revert changes, use the
configuration revert command.)
write to saves the active configuration to a file and makes the file the active
configuration.
filename is the name of the configuration file.
Note: You can also save an empty configuration file that contains the
shipping defaults and, optionally, the IP addresses, through the
configuration new filename [keep-console] command.
223
To view configuration files already existing on the Director management node:

Director (config) # show configuration files
File 200-simple-config:
Size: 16.1 kilobytes
File 200-telnet-config-2.director:
Size: 16.1 kilobytes
File initial (active):
Size: 13 kilobytes
Free space remaining: 1.6 gigabytes
To Rename a Configuration File:

Director (config) # configuration move current_filename new_filename
Switching the Active Director Configuration

You can switch to a different Director configuration that is already on your system
at any time by entering:
Director (config) # configuration switch-to filename
The file becomes the active configuration. The running configuration (which is
not yet saved) is discarded. Subsequent write memory commands affect the new
configuration.
Note: The configuration switch-to command can cause an internal error on

some configurations if you switched to an empty configuration file.
Switching Director Configuration Between Management Nodes

Director configuration files are encrypted, making them much more secure. To
move a configuration file from one management node to another, use the archive
upload, download, and restore commands. For more information on these
commands, see "Archiving and Restoring the Entire Director Configuration" on
page 225.
Deleting Configuration Files

You can delete old configuration files.
If a file is deleted from the system, you can recover it, if you store it elsewhere.
You cannot do downgrades to systems that used a specific configuration file if the
configuration file is destroyed through the config destroy-old-files command).
For information on the config destroy-old-files command, see "Destroying Old
Configuration Files After an Upgrade" on page 221.
To Delete Unused Configuration Files from the System:

From the (config) prompt, enter the following command:
Director (config) # config delete config_filename
Note: you do not know the name of the configuration filename you want to
delete, enter config delete ? to see the list of files that can be deleted.
224
Archiving and Restoring the Entire Director Configuration

Use the archive command to back up and restore Director configuration files,
event logs, job reports, and SG appliance backups through the archive utility.
These backups can be archived to another server in the network as long as the
server is network-accessible to Director. You can create only one archive at a time.
You can create the following archive types:
archive allIncludes configuration, event log, device backup, and job report
backup data.
archive configIncludes the Director configuration files only. This archive
includes the device settings, network settings, profiles, overlays, and
scheduled job data.
archive device-backupIncludes device-backup data only. Device-backups
are backups of the SG appliance configuration that are stored on Director (as a
result of a one-time action or as part of a job that includes periodic backups of
device configuration). Director pulls the configuration of the devices and
stores them. The device-backups archive includes all the backups available
on Director.
archive event-logIncludes event log data only. The event log records the
/var/log/ messages, which are log files written by the syslog on the system.
Director components generate these syslog entries during runtime. The
archive event-log includes all of the /var/log/ files and the /local/log/
directory.
archive job-reportIncludes job report data only. Job reports list the CLI
commands that are executed (and errors that are encountered) when jobs are
run on the system.
Generally, archive all is recommended because it is the most comprehensive.

However, you can archive individual components separately, for example, to save
space (if some components change more often than others).
Note: The config archive commands are memory and disk intensive. A
temporary copy of the configuration is created before archival. Blue Coat
recommends that you purge unwanted backup and configuration files from the
Director before creating an archive.
The following procedure describes how to create an archive of Director

configuration files, save these files off of Director, and then restore the
configuration.
Important: This operation must be done through the command line. Director
backups cannot be created though the Director Management Console.
Before You Begin

Ensure that you have access to a Web server and permission to upload data to it.
225
Procedure Overview
Archiving and restoring a Director configuration is performed in three primary
stages:
Creating a public encryption key.
Creating an archive file.
Uploading the archive file.
Retrieving and restoring the configuration from an archive file.
Creating a Encryption Keypair

Because archives are encrypted, a public encryption key is required for archiving
Director files and a private encryption key is required for restoring them.
You can either generate a keypair or you can input an existing public key. You
must generate the key with the show keyword so that you can input it later. You
must also specify a pass phrase. The pass phrase is used to decrypt the private key
when you need to restore the archive on Director.
To create an archive file:

1. Open the Director Command Line Interface (CLI).
2. Enter enable mode.
director > enable
director #
3. Enter configuration mode.

director # config t
director (config) #
4. Create an encryption key.

director (config) # archive generate key keyname show
The show subcommand allows you to view and input the key.
5. View the archive key.
When prompted, enter a pass phrase. Write down the pass phrase. If you lose
the pass phrase, you will not be able to restore the archive. After entering the
pass phrase, press Enter.
director # show archive key keyname
Enter pass phrase here:
6. Copy the archive key and paste it into a text file.

Save the text file to a different system (not Director). You will need to input the
key before restoring the archive.
226
7. Input the archive key to verify it.

director (config) # archive input key keyname show
Important: Enter the private key only. Director accepts only the first key entered. If
you enter both, Director will not receive the private key and you will be unable to
restore your configuration. The private key contains both the private and public key.
8. Press Ctrl+D when you have entered the key. You are prompted for the pass
phrase you created earlier.
Creating the Archive

After you have created the keypair, create the configuration archive.
To create the archive:

1. Create the archive.
director (config) # archive all create archive_name key keyname
2. Verify that the configuration was archived.
director (config) # show archive all archive_name
Ensure that the archive name you specified is listed.
Uploading the Archive File

After creating the archive, you must upload it to a secure Web server so that you
can restore it later.
227
To upload the archive file to a remote Web server:

1. Upload the archive file.
director (config) # archive all archive_name upload hostname
The hostname is the destination where the archive file will be stored. The
following four types of upload formats accepted by Director:
http://hostname[:port]/path/
https://hostname[:port]/path/
ftp://hostname/path/
scp://hostname/path/
If the path ends with a directory name, it must end with / (a forward slash).
If your Web server is password protected, include the following command after
entering the hostname:
username username password password
2. Verify that you have successfully uploaded your archive file.

Open a Web browser and enter the IP address of the Web server into the address bar.
Check the intended location of your file and verify that it is now there.
Retrieving and restoring the Archive

The restore command takes an archive key as input. The archive key is required to
restore the key.
To retrieve and restore the archive:

1. Retrieve the archive file.
director (config) # archive all fetch archive_name hostname
2. Input the archive key that you generated earlier.
director (config) # archive input key keyname show
Copy the archive key from the text file and enter it at the prompt. Press Ctrl+D when
you have entered the key. You will then be prompted for the pass phrase you created
earlier.
3. Restore the configuration.
director (config) # archive all restore archive_name key keyname
If the archive was successfully restored, the file successfully extracted message
is displayed.
4. Reboot the system.
director (config) # reload
228
Blue Coat Systems, Inc. utilizes third party software from various sources. Portions of this software are copyrighted by their
respective owners as indicated in the copyright notices below.
The following lists the copyright notices for:
BPF
Copyright (c) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that: (1) source
code distributions retain the above copyright notice and this paragraph in its entirety, (2) distributions including binary code
include the above copyright notice and this paragraph in its entirety in the documentation or other materials provided with
the distribution, and (3) all advertising materials mentioning features or use of this software display the following
acknowledgement:
This product includes software developed by the University of California, Lawrence Berkeley Laboratory and its
contributors.
Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived
from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND WITHOUT
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
DES
Software DES functions written 12 Dec 1986 by Phil Karn, KA9Q; large sections adapted from the 1977 public-domain
program by Jim Gillogly.
EXPAT
Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Finjan Software
Copyright (c) 2003 Finjan Software, Inc. All rights reserved.
Flowerfire
Copyright (c) 1996-2002 Greg Ferrar
ISODE
ISODE 8.0 NOTICE
Acquisition, use, and distribution of this module and related materials are subject to the restrictions of a license agreement.
Consult the Preface in the User's Manual for the full terms of this agreement.
4BSD/ISODE SMP NOTICE
Acquisition, use, and distribution of this module and related materials are subject to the restrictions given in the file SMP-
READ-ME.
UNIX is a registered trademark in the US and other countries, licensed exclusively through X/Open Company Ltd.
MD5
RSA Data Security, Inc. MD5 Message-Digest Algorithm
Copyright (c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.
License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message-
Digest Algorithm" in all material mentioning or referencing this software or this function.
License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA
Data Security, Inc. MD5 Message-Digest Algorithm" in all material mentioning or referencing the derived work.
RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of
this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind.
THE BEER-WARE LICENSE" (Revision 42):
<phk@FreeBSD.org <mailto:phk@FreeBSD.org>> wrote this file. As long as you retain this notice you can do whatever you
want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-
Henning Kamp
Microsoft Windows Media Streaming
229
Copyright (c) 2003 Microsoft Corporation. All rights reserved.

OpenLDAP
Copyright (c) 1999-2001 The OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. Permission to copy
and distribute verbatim copies of this document is granted.
http://www.openldap.org/software/release/license.html
The OpenLDAP Public License Version 2.7, 7 September 2001
Redistribution and use of this software and associated documentation ("Software"), with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain copyright statements and notices,
2. Redistributions in binary form must reproduce applicable copyright statements and notices, this list of conditions, and the
following disclaimer in the documentation and/or other materials provided with the distribution, and
3. Redistributions must contain a verbatim copy of this document.
The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished by a version number. You
may use this Software under terms of this license revision or under the terms of any subsequent revision of the license.
THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND ITS CONTRIBUTORS `ÀS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
OPENLDAP FOUNDATION, ITS CONTRIBUTORS, OR THE AUTHOR(S) OR OWNER(S) OF THE SOFTWARE BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The names of the authors and copyright holders must not be used in advertising or otherwise to promote the sale, use or other
dealing in this Software without specific, written prior permission. Title to copyright in this Software shall at all times remain
with copyright holders.
OpenLDAP is a registered trademark of the OpenLDAP Foundation.
OpenSSH
Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland. All rights reserved
This file is part of the OpenSSH software.
The licences which components of this software fall under are as follows. First, we will summarize and say that all components
are under a BSD licence, or a licence more free than that.
OpenSSH contains no GPL code.
1) As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of
this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC
file, it must be called by a name other than "ssh" or "Secure Shell".
[Tatu continues]
However, I am not implying to give any licenses to any patents or copyrights held by third parties, and the software includes
parts that are not under my direct control. As far as I know, all included source code is used in accordance with the relevant
license agreements and can be used freely for any purpose (the GNU license being the most restrictive); see below for details.
[However, none of that term is relevant at this point in time. All of these restrictively licenced software components which he
talks about have been removed from OpenSSH, i.e.,
- RSA is no longer included, found in the OpenSSL library
- IDEA is no longer included, its use is deprecated
- DES is now external, in the OpenSSL library
- GMP is no longer used, and instead we call BN code from OpenSSL
- Zlib is now external, in a library
- The make-ssh-known-hosts script is no longer included
- TSS has been removed
- MD5 is now external, in the OpenSSL library
- RC4 support has been replaced with ARC4 support from OpenSSL
- Blowfish is now external, in the OpenSSL library
[The licence continues]
Note that any information and cryptographic algorithms used in this software are publicly available on the Internet and at any
major bookstore, scientific library, and patent office worldwide. More information can be found e.g. at "http://www.cs.hut.fi/
crypto".
The legal status of this program is some combination of all these permissions and restrictions. Use only at your own
responsibility. You will be responsible for any legal consequences yourself; I am not making any claims whether possessing or
using this is legal or not in your country, and I am not taking any responsibility on your behalf.
NO
WARRANTY
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE
EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
230
SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN

WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE
PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM
(INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED
BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
2) The 32-bit CRC compensation attack detector in deattack.c was contributed by CORE SDI S.A. under a BSD-style license.
Cryptographic attack detector for ssh - source code
Copyright (c) 1998 CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. Redistribution and use in source and binary
forms, with or without modification, are permitted provided that this copyright notice is retained. THIS SOFTWARE IS
PROVIDED `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI
S.A. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
RESULTING FROM THE USE OR MISUSE OF THIS SOFTWARE.
Ariel Futoransky <futo@core-sdi.com> <http://www.core-sdi.com>
3) ssh-keygen was contributed by David Mazieres under a BSD-style license.
Copyright 1995, 1996 by David Mazieres <dm@lcs.mit.edu>. Modification and redistribution in source and binary forms is
permitted provided that due credit is given to the author and the OpenBSD project by leaving this copyright notice intact.
4) The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public domain and distributed
with the following license:
@version 3.0 (December 2000)
Optimised ANSI C code for the Rijndael cipher (now AES)
@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
@author Paulo Barreto <paulo.barreto@terra.com.br>
This code is hereby placed in the public domain.
THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
5) One component of the ssh source code is under a 3-clause BSD license, held by the University of California, since we pulled
these parts from original Berkeley code.
Copyright (c) 1983, 1990, 1992, 1993, 1995
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS `ÀS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
6) Remaining components of the software are provided under a standard 2-term BSD licence with the following names as
copyright holders:
Markus
Friedl
Theo de
Raadt
Niels
Provos
Dug Song
Aaron
Campbell
Damien
Miller
Kevin
Steves
231
Daniel
Kouril
Wesley
Griffin
Per
Allansson
Nils
Nordman
Simon
Wilkinson
conditions are met:
THIS SOFTWARE IS PROVIDED BY THE AUTHOR `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
OpenSSL
Copyright (c) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.
http://www.openssl.org/about/
http://www.openssl.org/about/
OpenSSL is based on the excellent SSLeay library developed by Eric A. Young <mailto:eay@cryptsoft.com> and Tim J. Hudson
<mailto:tjh@cryptsoft.com>.
The OpenSSL toolkit is licensed under a Apache-style license which basically means that you are free to get and use it for
commercial and non-commercial purposes.
This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to
conform with Netscapes SSL.
This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following
conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL
documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson
(tjh@cryptsoft.com).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in
a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a
textual message at program startup or in documentation (online or textual) provided with the package.
conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This
product includes cryptographic software written by Eric Young (eay@cryptsoft.com)" The word 'cryptographic' can be left out if
the routines from the library being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include
an acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code
cannot simply be copied and put under another distribution license [including the GNU Public License.]
Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved.
conditions are met:
3. All advertising materials mentioning features or use of this software must display the following acknowledgment:
"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
232
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this
software without prior written permission. For written permission, please contact openssl-core@openssl.org.
5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior
written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software
developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)"
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software
written by Tim Hudson (tjh@cryptsoft.com).
PCRE
Copyright (c) 1997-2001 University of Cambridge
University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714.
Written by: Philip Hazel <ph10@cam.ac.uk>
Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely,
subject to the following restrictions:
1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
2. Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel,
and copyright by the University of Cambridge, England.
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
PHAOS SSLava and SSLavaThin
Copyright (c) 1996-2003 Phaos Technology Corporation. All Rights Reserved.
The software contains commercially valuable proprietary products of Phaos which have been secretly developed by Phaos, the
design and development of which have involved expenditure of substantial amounts of money and the use of skilled
development experts over substantial periods of time. The software and any portions or copies thereof shall at all times remain
the property of Phaos.
PHAOS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED
WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, REGARDING THE SOFTWARE, OR ITS
USE AND OPERATION ALONE OR IN COMBINATION WITH ANY OTHER SOFTWARE.
PHAOS SHALL NOT BE LIABLE TO THE OTHER OR ANY OTHER PERSON CLAIMING DAMAGES AS A RESULT OF THE
USE OF ANY PRODUCT OR SOFTWARE FOR ANY DAMAGES WHATSOEVER. IN NO EVENT WILL PHAOS BE LIABLE
FOR SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF ADVISED OF THE POSSIBLITY OF SUCH
DAMAGES.
RealSystem
The RealNetworks RealProxy Server is included under license from RealNetworks, Inc. Copyright 1996-1999, RealNetworks,
Inc. All rights reserved.
SNMP
Copyright (C) 1992-2001 by SNMP Research, Incorporated.
This software is furnished under a license and may be used and copied only in accordance with the terms of such license and
with the inclusion of the above copyright notice. This software or any other copies thereof may not be provided or otherwise
made available to any other person. No title to and ownership of the software is hereby transferred. The information in this
software is subject to change without notice and should not be construed as a commitment by SNMP Research, Incorporated.
Restricted Rights Legend:
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013; subparagraphs (c)(4) and (d) of the Commercial
Computer Software-Restricted Rights Clause, FAR 52.227-19; and in similar clauses in the NASA FAR Supplement and other
corresponding governmental regulations.
PROPRIETARY NOTICE
This software is an unpublished work subject to a confidentiality agreement and is protected by copyright and trade secret law.
Unauthorized copying, redistribution or other use of this work is prohibited. The above notice of copyright on this source code
product does not indicate any actual or intended publication of such source code.
STLport
Copyright (c) 1999, 2000 Boris Fomitchev
This material is provided "as is", with absolutely no warranty expressed or implied. Any use is at your own risk.
Permission to use or copy this software for any purpose is hereby granted without fee, provided the above notices are retained
on all copies. Permission to modify the code and to distribute modified code is granted, provided the above notices are retained,
and a notice that the code was modified is included with the above copyright notice.
The code has been modified.
Copyright (c) 1994 Hewlett-Packard Company
Copyright (c) 1996-1999 Silicon Graphics Computer Systems, Inc.
Copyright (c) 1997 Moscow Center for SPARC Technology
233
Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted
without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission
notice appear in supporting documentation. Hewlett-Packard Company makes no representations about the suitability of this
software for any purpose. It is provided "as is" without express or implied warranty.
notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability of this software for
any purpose. It is provided "as is" without express or implied warranty.
notice appear in supporting documentation. Moscow Center for SPARC Technology makes no representations about the
suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
SmartFilter
Copyright (c) 2003 Secure Computing Corporation. All rights reserved.
SurfControl
Copyright (c) 2003 SurfControl, Inc. All rights reserved.
Symantec AntiVirus Scan Engine
Copyright (c) 2003 Symantec Corporation. All rights reserved.
TCPIP
Some of the files in this project were derived from the 4.X BSD (Berkeley Software Distribution) source.
Their copyright header follows:
Copyright (c) 1982, 1986, 1988, 1990, 1993, 1994, 1995
conditions are met:
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:
This product includes software developed by the University of California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS `ÀS IS'' AND ANY EXPRESS OR IMPLIED
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
Trend Micro
Copyright (c) 1989-2003 Trend Micro, Inc. All rights reserved.
zlib
Copyright (c) 2003 by the Open Source Initiative
This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any
damages arising from the use of this software.
ICU License - ICU 1.8.1 and later COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1995-2003 International Business
Machines Corporation and others All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice
appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting
documentation. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS
INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL
DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH
THE USE OR PERFORMANCE OF THIS SOFTWARE. Except as contained in this notice, the name of a copyright holder shall
not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written
authorization of the copyright holder
The PHP License, version 3.01 Copyright (c) 1999 - 2006 The PHP Group. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following
conditions are met:
3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written
permission. For written permission, please contact group@php.net.
234
4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written
permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP"
instead of calling it "PHP Foo" or "phpfoo"
5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a
distinguishing version number.
Once covered code has been published under a particular version of the license, you may always continue to use it under the
terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license
published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code
created under this License.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
"This product includes PHP software, freely available from
<http://www.php.net/software/>".
THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM `ÀS IS'' AND ANY EXPRESSED OR IMPLIED
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--------------------------------------------------------------------
This software consists of voluntary contributions made by many individuals on behalf of the PHP Group.
The PHP Group can be contacted via Email at group@php.net.
For more information on the PHP Group and the PHP project, please see <http://www.php.net>.
The Zend Engine License, version 2.00 Copyright (c) 1999-2002 Zend Technologies Ltd. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following
conditions are met:
3. The names "Zend" and "Zend Engine" must not be used to endorse or promote products derived from this software without
prior permission from Zend Technologies Ltd. For written permission, please contact license@zend.com.
4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given
a distinguishing version number. Once covered code has been published under a particular version of the license, you may
always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any
subsequent version of the license published by Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to
modify the terms applicable to covered code created under this License.
5. Redistributions of any form whatsoever must retain the following acknowledgment:
"This product includes the Zend Engine, freely available at
http://www.zend.com"
6. All advertising materials mentioning features or use of this software must display the following acknowledgment:
"The Zend Engine is freely available at http://www.zend.com"
THIS SOFTWARE IS PROVIDED BY ZEND TECHNOLOGIES LTD. `ÀS IS'' AND ANY EXPRESSED OR IMPLIED
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ZEND TECHNOLOGIES LTD. BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
TSRM (Thread Safe Resource Manager) license. Copyright (c) 1999, 2000, Andi Gutmans, Sascha Schumann, Zeev Suraski.
All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Neither name of the copyright holders nor the names of their contributors may be used to endorse or promote products derived
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS `ÀS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Regex. Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved.
235
This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University
of California.
Permission is granted to anyone to use this software for any purpose on any computer system, and to alter it and redistribute it,
subject to the following restrictions:
1. The author is not responsible for the consequences of use of this software, no matter how awful, even if they arise from flaws in
it.
2. The origin of this software must not be misrepresented, either by explicit claim or by omission. Since few users ever read
sources, credits must appear in the documentation.
3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. Since few
users ever read sources, credits must appear in the documentation.
4. This notice may not be removed or altered.
libgd
Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 by Cold Spring Harbor Laboratory. Funded under Grant P41-
RR02188 by the National Institutes of Health.
Portions copyright 1996, 1997, 1998, 1999, 2000, 2001 by Boutell.Com, Inc.
Portions relating to GD2 format copyright 1999, 2000 Philip Warner.
Portions relating to PNG copyright 1999, 2000 Greg Roelofs.
Portions relating to libttf copyright 1999, 2000 John Ellson (ellson@lucent.com).
Portions relating to JPEG and to color quantization copyright 2000, Doug Becker and copyright (C) 1994-1998, Thomas G. Lane.
This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more
information.
Portions relating to WBMP copyright 2000 Maurice Szmurlo and Johan Van den Brande.
Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application,
provided that this notice is present in user-accessible supporting documentation._
This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not
to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the
library. Credit must be given in user-accessible documentation.
This software is provided "AS IS."_ The copyright holders disclaim all warranties, either express or implied, including but not
limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying
documentation.
Although their code does not appear in gd 2.0.1, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue
Software Corporation for their prior contributions.
236
Index
A SG appliance, creating 80
admin user, explained 200 SG appliance, deleting 84
administrator activity logging backup-restore
about 123 output limits 28
configuring 124 backups 87
configuring syslog 124
enabling TACACS+ 124 C
job logging format 126 CLI
message format 123 Director configuration 20
profile/overlay/backup logging format. 125 error messages 190
setting the logging level 124 authentication 197
setting up 123 devices 195
TACACS+ 123 help 193
alerts host names 195
about 118 listed 191
acknowledging 120 logging 196
comments 120 RADIUS 198
customizing views 119 user directory 192
managing 118 usernames and passwords 191
appliance certificates 62 FTP
archive server connections, configuring 212
configuration output limits 28 server connections, disabling 212
ARP overview 16
troubleshooting 194 privilege level, setting 200
audience 9 troubleshooting 194
authenticating Director 62 user account
authentication commands managing 200
error messages 197 configuration
authentication methods 23 files, destroying 221
authentication port 32 files, renaming 224
authentication profiles files, viewing 224
RSA 34 managing 223
simple 34 saving 223
authentication, device. See device authentication. switching files 224
62 configuration files
deleting 224
B encrypted 224
backup restoring to previous version 222
pinning SG configurations 82 switching between management nodes 224
restoring SG appliance 83 upgrade behavior 220
SG appliance, comparing 84 configuring devices 29
237
connecting, first time 21 downgrading 221

content Enable Mode Password 33
distributiing URLs 104 first time connection 21
distribution, about 103 initial connection properties 22
querying 110 jobs
validating URLs 108 naming 89
Content Sync Module 17 scheduling 91
CSM 17 Manage Device Page 121
Management Console overview 16
D monitoring
Dashboard 17 overview 115, 123
device monitoring group and device status 116
edition or model 117 Monitoring tab 116
device authentication overlays
appliance certificates, about 62 naming 51
overview 62 Refreshables 51
device error messages 195 overview 13, 14
device statistics profiles
viewing 121 applying 46
device status 116 naming 45
devices settings 43
adding 29 standby 147
IDs 32 upgrade changes 220
naming 32 viewing device edition 117
diff utility viewing device statistics 121
using in CLI 47 viewing group status 116
using in Management Console 47 Web port 32
Director Director management node
adding devices 29 RADIUS servers, configuring 205
alerts TACACS servers, configuring 205
acknowledging 120 Director redundancy. See standby 147
comments 120 document conventions 10
customizing views 119 document objectives 9
managing 118 downgrading Director
overview 118 limitations 223
authentication methods 23 procedure 221
authentication port 32
authentication profiles 34 E
authentication protocols 34 Enable mode commands
capabilities 14 image fetch, using 219
CLI overview 16 show image, using 219
configuring 20 Enable Mode Password 33
Dashboard 17 Enable password 22
device configuration 29 error messages
device IDs 32 ARP 194
device name 32 CLI 190, 191
238
Index
CLI help 193 about 87

clock 192 actions 90
host names 195 restrictions 93
LCD 192 customizing the job queue 97
LCD front panel 192 editing 96
SNMP 193 GUI actions 87
time, NTP 192 immediate 94
troubleshooting CLI 194 job report 95
user directory 192 naming 89
usernames and passwords 191 scheduling 91
setting up 88
F verifying 94
FTP verifying backup jobs 96
server connections configuring 212
server connections, disabling 212 L
LCD error messages 192
G local user accounts, creating 200
group status 116 logging
administrator activity 123
H error messages 196
health monitoring logging levels
Connected state 134 setting 124
Critical state 134
Director 129, 130 M
Disconnected state 134 Manage Device Page 121
general metrics 134 Management Console
license expiration 133 overview 16
licensing metrics 135 monitoring
modifying properties 138 configuring Director to send SGOS state traps
notification 136 143
OK state 134 Monitoring tab 116
requirements 130
state descriptions 134 N
status metrics 135 NTP, error messages 192
Warning state 134
O
I organization 9
image commands overlays
Director management node 217, 219 CLI, managing through 53
downloading 217, 219 deleting through Management Console 53
image fetch, using 219 executing through the Management Console
initial setup 20 53
initial setup tasks 19 managing through Management Console 50
naming 51
J output limits 28
jobs overview 50
239
Refreshables 51 RSA key, generating 210

SSH Simple 23
P SSH/RSA
ports generating key 210
authentication 20 SSH-RSA
privilege level, setting 200 configuring 23
profiles keypairs 36
applying 46 standby
comparing 47 about 147
deleting 47 Active backoff 154
naming 45 Active state 150
output limits 28 administrator actions 152
settings 43 breaking the standby pair 156
clock synchronization 148
R concepts 152
RADIUS configuration change recommendations 159
defined 204 configuring the pair 156
error messages 198 connectivity monitoring 153
servers, configuring 205 data mirroring 152
rebooting 87 failover 153
related documentation 11 failover assumptions 152
failure
S
jobs in process 165
schedule error messages 197
unsynchronized changes 165
security, managing through access lists 211
identity 158
SG appliance
implementation details 156
fully authenticating 35
Inactive state 150
SGMEOS
moving Directors 162
CLI overview 16
network outages 163
Management Console overview 16
partner
SG-registration-failed trap
defined 148
auto-registration
state 158
failed trap 77
status 159
sinks, log types 175
Primary Director 149
SNMP
Primary Director failure 165
device-state traps 143
remote management stations 148
SNMP commands
requirements 148
connections, configuring 213
Reserve 150
connections, disabling 213
Secondary Director 149
error messages 193
SNMP 153
SSH
SNMP notifications 157, 169
authentication error messages 197
software upgrades 166
Director, using with 209
standalone 149
ssh server
standby pair defined 148
authentication options, setting 210
states 150, 152
generating key 210
240
Index
supported platforms 148 schedule 197

sync SNMP 193
definition 149 SSH 197
state 158 time, clock 192
status 159 time, NTP 192
terminology 148 user directory 192
use scenario 160 user management 190
viewing state 158 usernames and passwords 191
substitution variables
about 54 U
creating (overlay) 55 upgrade behavior, configuration files. 220
syslog upgrading
configuring 124 Director install image file, downloading 217,
219
T Director management node image 217, 219
TACACS servers, configuring 205 SGOS software 98
TACACS+ authentication creating a job for 98
enabling 124 download 98
Telnet install/reboot 98
connections, configuring 212 job actions 98
connections, disabling 212 validation 98
telnet user account management
enable and disable 212 discussed 200
time management commands, error messages, error messages 190
clock 192 local accounts, creating 200
troubleshooting restricting privileges 200
ARP 194
authentication 197 W
CLI help 193 Web port 32
configuration files, restoring 222 workgroups
destroying old configuration files 221 creating 202
devices, error messages 195 default 202
host names 195 priority level, setting 202
LCD error messages 192 rules, setting 203
LCD front panel 192 saving 204
logging 196 users, adding 203
RADIUS 198
241

BlueCoat - Configuration and Management Guide - 5.x

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BlueCoat - Configuration and Management Guide - 5.x

Caricato da

Copyright:

Formati disponibili

Blue Coat Systems

Configuration and Management Guide

SGME Version 5.2.x

For concerns or feedback about the documentation: documentation@bluecoat.com

Other copyrights apply. See the Appendix B.

Document Number: 231-02977

Chapter 1: Director Overview

Chapter 2: Getting Started

Chapter 3: Configuring and Managing Devices

Creating a Profile .............................................................................................................................. 43

Managing Backups through the CLI ....................................................................................... 85

Chapter 4: Configuring Jobs

Chapter 5: Distributing Content

Chapter 6: Monitoring Devices

Chapter 7: Monitoring Administrator Activity

Chapter 8: Monitoring the Health of Devices

Chapter 9: Configuring Director Redundancy

Network Link Failure..................................................................................................................... 163

Chapter 10: Director Logging

Appendix A: Administering Director

Upgrade Changes..................................................................................................................... 220

Appendix B: Third Party Copyright Notices

Chapter Title Description

Chapter 1 Director Overview Provides Director terminology and

Chapter 2 Getting Started Provides how to connect to Director for

Chapter 3 Configuring and Describes how to create and manage

Chapter 4 Configuring Jobs Describes how to configure Director to

Chapter 5 Distributing Describes how to use Director to create

Chapter 6 Monitoring Devices Describes how to use Director to monitor

Table 11 Document Organization

Chapter Title Description

Chapter 7 Monitoring Describes how to monitor tasks invoked

Chapter 8 Monitoring the Describes how to use Director to monitor

Chapter 9 Configuring Describes how to configure Director

Chapter 10 Director Logging Provides the codes used in Director

Appendix A Administering Describes how to perform

bold sans seriff type Words used on the user interface.

italicized type Book titles

monospaced type File and directory names

Square brackets, as in [value] Optional command parameters

Curly braces, as in {value} Required command parameters

Logical OR, as in value1|value2 Exclusive command parameters where only one

Document name Description

Blue Coat Director Dashboard

Blue Coat Director Content Sync

Release Notes Provides late-breaking news; updates to the product;

This chapter provides an overview of Director. It discusses benefits,

About the Benefits of Director

Managing and Monitoring Blue Coat SG Appliances with Director

SG record: Management information stored in Director that corresponds to a

About the Director Managment Console and CLI

Table 11 Availability of Features in the Director CLI and Management Console

Feature Management CLI

Initial Setup and Managing System Software

Director Software Installation, Upgrade, and No Yes

Global IP Configuration No Yes

Network Interface Configuration No Yes

Time Management No Yes

LCD Pane Management No Yes

SSH Server No Yes

FTP and Telnet Servers No Yes

Director management node No Yes

User Accounts No Yes