SA 7.50 Administration Guide

HP Server Automation
for the HP-UX, Solaris, Red Hat Enterprise Linux,

VMware, and Windows operating systems
Software Version: 7.50
Adminstration Guide
Document Release Date: September 2008
Software Release Date: September 2008
Adminstration Guide
2
Legal Notices
Warranty
The only warranties for HP products and services are set forth in the express warranty
statements accompanying such products and services. Nothing herein should be
construed as constituting an additional warranty. HP shall not be liable for technical or
editorial errors or omissions contained herein.
The information contained herein is subject to change without notice.
For information about third party license agreements, see the Third Party and Open
Source Notices document in the product installation media directory.
Restricted Rights Legend
Confidential computer software. Valid license from HP required for possession, use or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software,
Computer Software Documentation, and Technical Data for Commercial Items are
licensed to the U.S. Government under vendor's standard commercial license.
Copyright Notices
Copyright 2000-2008 Hewlett-Packard Development Company, L.P.
Trademark Notices
Microsoft, Windows, Windows Vista, and Windows XP are U.S. registered
trademarks of Microsoft Corporation.
UNIX is a registered trademark of The Open Group.
3
Documentation Updates
The title page of this document contains the following identifying information:
Software Version number, which indicates the software version.
Document Release Date, which changes each time the document is updated.
Software Release Date, which indicates the release date of this version of the software.
To check for recent updates or to verify that you are using the most recent edition of a
document, go to:
http://h20230.www2.hp.com/selfsolve/manuals
This site requires that you register for an HP Passport and sign in. To register for an HP
Passport ID, go to:
http://h20229.www2.hp.com/passport-registration.html
Or click the New users - please register link on the HP Passport login page.
Support
Visit the HP Software Support Online web site at:
www.hp.com/go/hpsoftwaresupport
This web site provides contact information and details about the products, services, and
support that HP Software offers.
For downloads, see:
https://h10078.www1.hp.com/cda/hpdc/display/main/
index.jsp?zn=bto&cp=54_4012_100__
HP Software online support provides customer self-solve capabilities. It provides a fast
and efficient way to access interactive technical support tools needed to manage your
business. As a valued support customer, you can benefit by using the support web site to:
Search for knowledge documents of interest
Submit and track support cases and enhancement requests
Download software patches
Manage support contracts
Look up HP support contacts
Review information about available services
Adminstration Guide
4
Enter into discussions with other software customers
Research and register for software training
Most of the support areas require that you register as an HP Passport user and sign in.
Many also require a support contract. To register for an HP Passport ID, go to:
http://h20229.www2.hp.com/passport-registration.html
To find more information about access levels, go to:
http://h20230.www2.hp.com/new_access_levels.jsp
5
Table of Contents
Preface 17
Overview of this Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Contents of this Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Conventions in this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Icons in this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Guides in the Documentation Set and Associated Users. . . . . . . . . . . . . . .19
Chapter 1: SA Overview 21
SA Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Types of SA Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
SA Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Model-Based Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Types of SA Installations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
The Core Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
SA Core Component Bundling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Model Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
The Core Component Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Interaction Among SA Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
General Interaction Among Components . . . . . . . . . . . . . . . . . . . . . . . . . . .32
SA Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
OS Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Administration Guide
6
Software Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Code Deployment and Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Script Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Integration with AIX and HP-UX Installation Technology . . . . . . . . . . . . . .41
Component Interaction in Multiple Facilities. . . . . . . . . . . . . . . . . . . . . . . . .41
Discovery and Agent Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Application Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Audit and Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Chapter 2: User and Group Setup 47
Users, Groups, and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
SA Users and User Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
SA Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Folder Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
SA Global File System Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Membership in Multiple Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
SAS Web Client Restricted Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Predefined User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Super Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Customer Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Process Overview for Security Administration . . . . . . . . . . . . . . . . . . . . . . .58
Private User Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
7
Managing Users and User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Creating a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Editing User Profile Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Viewing a Users Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Deleting a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Suspending a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Creating a User Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Assigning a User to a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Setting Permissions on User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Setting the Customer Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Setting the Facility Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Setting the Device Group Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Setting the General Feature Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Setting the SA Client Features Permissions . . . . . . . . . . . . . . . . . . . . . . . . .68
Setting the Other Features Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Setting Folder Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Adding OGFS Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Setting Private User Group Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Managing Super and Customer Administrators. . . . . . . . . . . . . . . . . . . . . . .72
Viewing Super and Customer Administrators. . . . . . . . . . . . . . . . . . . . . . . .72
Creating a Super Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Deleting a Super Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Delegating User Group Management to a Customer Administrator . . . .74
8
Managing Passwords and Login Settings . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Specifying Password Character Requirements . . . . . . . . . . . . . . . . . . . . . .75
Resetting Initial Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Setting Password Expiration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Specifying Session Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Setting the User Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Setting the Banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
External LDAP Directory Service with SA. . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Imported Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
SSL and External Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Supported External LDAP Directory Servers . . . . . . . . . . . . . . . . . . . . . . . .79
Using an LDAP Directory Server with SA. . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Modifying the Web Services Data Access Engine Configuration File . . .80
Importing a Server Certificate from the LDAP into SA . . . . . . . . . . . . . . . .84
Configuring the JAAS Login Module (loginModule.conf) . . . . . . . . . . . . . .85
Importing External LDAP Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Code Deployment Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Adding Members to a Code Deployment User Group . . . . . . . . . . . . . . . .87
User and Security Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Chapter 3: Multimaster Mesh Administration 89
Multimaster Facilities Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Modifying a Facilitys Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Adding or Modifying a Facilitys Custom Attributes. . . . . . . . . . . . . . . . . . .90
9
Multimaster Mesh Conflict Administration. . . . . . . . . . . . . . . . . . . . . . . . . . .92
Types of Conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Causes of Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
User Overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
User Duplication of Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Out of Order Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Best Practices for Preventing Multimaster Conflicts . . . . . . . . . . . . . . . . . .96
Examining the State of the Multimaster Mesh . . . . . . . . . . . . . . . . . . . . . . .97
System Diagnosis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Multimaster State Monitoring Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Best Practices for Resolving Database Conflicts . . . . . . . . . . . . . . . . . . . . .98
Types of Conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Guidelines for Resolving Each Type of Conflict . . . . . . . . . . . . . . . . . . . . 100
Model Repository Multimaster Component Conflicts . . . . . . . . . . . . . . . . .102
Overview of Resolving Model Repository Multimaster
Component Conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Resolving a Conflict by Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Resolving a Conflict by Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Network Administration for Multimaster . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Multimaster Alert Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Chapter 4: Satellite Administration 117
Overview of the SA Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Management Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Facilities and Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10
Satellite Information and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Permissions Required for Managing Satellites . . . . . . . . . . . . . . . . . . . . . 120
Viewing Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Enabling the Display of Realm Information . . . . . . . . . . . . . . . . . . . . . . . . 123
Viewing the Realm of a Managed Server. . . . . . . . . . . . . . . . . . . . . . . . . . 123
Viewing Gateway Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Software Repository Cache Management . . . . . . . . . . . . . . . . . . . . . . . . . .129
Availability of Packages on the Software Repository Cache . . . . . . . . . 130
Ways to Distribute Packages to Satellites. . . . . . . . . . . . . . . . . . . . . . . . . 130
Setting the Update Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
On-demand Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Manual Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Hierarchical Software Repository Caches. . . . . . . . . . . . . . . . . . . . . . . . . 134
Cache Size Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Creation of Manual Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Creating a Manual Update Using the DCML Exchange Tool (DET) . . . 135
Applying a Manual Update to a Software Repository Cache. . . . . . . . . 137
Staging Files to a Software Repository Cache . . . . . . . . . . . . . . . . . . . . . 137
Microsoft Utility Uploads and Manual Updates. . . . . . . . . . . . . . . . . . . . . 139
11
Chapter 5: SA Maintenance 141
Possible SA Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
SA Diagnosis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
SA Component Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Diagnosis Tool Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
System Diagnosis Testing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
System Diagnosis Test Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Data Access Engine Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Software Repository Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Web Services Data Access Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Command Engine Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Model Repository Multimaster Component Tests . . . . . . . . . . . . . . . . . . 147
Running a System Diagnosis of SA Core Components . . . . . . . . . . . . . 147
The Health Check Monitor for an SA Core. . . . . . . . . . . . . . . . . . . . . . . . . .149
Overview of HCM Local Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Validating Core Components by Running HCM Local Tests . . . . . . . . . 149
Syntax of the Script for HCM Local Tests . . . . . . . . . . . . . . . . . . . . . . . . . 150
Overview of HCM Global Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Validating a Core By Running HCM Global Tests. . . . . . . . . . . . . . . . . . . 152
Syntax of the Script for HCM Global Tests . . . . . . . . . . . . . . . . . . . . . . . . 152
Setting up Passwordless SSH for Global Tests . . . . . . . . . . . . . . . . . . . . 154
12
Extensibility of the Health Check Monitor . . . . . . . . . . . . . . . . . . . . . . . . . .155
Requirements for Extensions to HCM Local Tests . . . . . . . . . . . . . . . . . 155
Categories and Local Test Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Directory Layout for HCM Local Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
HCM Local Test Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Requirements for Extensions to HCM Global Tests . . . . . . . . . . . . . . . . 158
HCM Global Test Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Directory Layout for HCM Global Tests: . . . . . . . . . . . . . . . . . . . . . . . . . . 161
HCM Global Test Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Logs for SA Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Boot Server Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Build Manager Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Command Engine Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Data Access Engine Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Media Server Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Model Repository Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Model Repository Multimaster Component Logs. . . . . . . . . . . . . . . . . . . 163
Agents Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
SAS Web Client Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Software Repository Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Software Repository Replicator Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Web Services Data Access Engine Logs . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Gateway Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Global File System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
HTTPS Server Proxy Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
13
Global Shell Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Shell Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Shell Stream Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Shell Script Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Example of Monitoring Global Shell Audit Logs . . . . . . . . . . . . . . . . . . . . 168
Digital Signatures in the Global Shell Audit Logs. . . . . . . . . . . . . . . . . . . 169
Storage Management for the Global Shell Audit Logs . . . . . . . . . . . . . . 170
Configuring the Global Shell Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Start Script for SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
Syntax of the Start Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Starting an SA Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Starting a Multiple-Server SA Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Starting an SA Core Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
SA Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Mass Deletion of Backup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Syntax of Backup Deletion Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Deleting Backup Files with the Mass Deletion Script . . . . . . . . . . . . . . . 179
Designations for Multiple Data Access Engines . . . . . . . . . . . . . . . . . . . . .181
Overview of Designations for Multiple Data Access Engines . . . . . . . . 181
Reassigning the Data Access Engine to a Secondary Role. . . . . . . . . . 182
Designating the Multimaster Central Data Access Engine. . . . . . . . . . . 183
Web Services Data Access Engine Configuration Parameters . . . . . . . . .184
Changing a Web Services Data Access Engine Parameter . . . . . . . . . . 184
Web Services Data Access Engine Configuration File . . . . . . . . . . . . . . 184
14
Chapter 6: Monitoring SA 187
Overview of SA Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Agent Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Agent Cache Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Command Center Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Load Balancing Gateway Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Data Access Engine Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Web Services Data Access Engine Monitoring . . . . . . . . . . . . . . . . . . . . . .197
Command Engine Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
Software Repository Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Model Repository Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
Model Repository Multimaster Component Monitoring . . . . . . . . . . . . . . .204
TIBCO Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Global File System Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Spoke Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Gateway Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
OS Build Manager Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214
OS Boot Server Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
OS Media Server Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
15
Chapter 7: SA Configuration 219
System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Ways to Use SA Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . .220
Configuring Contact Information in the SA Help . . . . . . . . . . . . . . . . . . . 220
Configuring the Mail Server for a Facility. . . . . . . . . . . . . . . . . . . . . . . . . . 221
Setting Email Alert Addresses for an SA Core . . . . . . . . . . . . . . . . . . . . . 222
Configuring Email Alert Addresses for Multimaster . . . . . . . . . . . . . . . . . 223
Configuring Email Notification Addresses for Code Deployment and
Rollback (CDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Scheduling Audit Result and Snapshot Removal . . . . . . . . . . . . . . . . . . . .226
Appendix A: Permissions Reference 229
Permissions Required for the SAS Web Client . . . . . . . . . . . . . . . . . . . . . .229
Permissions Required for the SA Client . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
More Information for Security Administrators. . . . . . . . . . . . . . . . . . . . . . 232
Application Configuration Management Permissions . . . . . . . . . . . . . . . 232
Device Group Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
SA Discovery and Agent Deployment Permissions . . . . . . . . . . . . . . . . . 241
Job Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Patch Management for Windows Permissions . . . . . . . . . . . . . . . . . . . . . 242
Patch Management for Unix Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 247
Software Management Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Script Execution Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Audit and Remediation Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Service Automation Visualizer Permissions. . . . . . . . . . . . . . . . . . . . . . . . 294
Virtualization Director Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
OS Provisioning Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
16
Compliance View Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Server Property and Reboot Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 305
Server Objects Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Predefined User Group Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
Private User Groups (PUG) Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . .311
Code Deployment User Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
Index 315
17
Preface
Welcome to HP Server Automation (SA) an enterprise-class software solution that
enables customers to get all the benefits of the SA data center automation platform and
support services. SA provides a core foundation for automating formerly manual tasks
associated with the deployment, support, and growth of server and server application
infrastructure.
Overview of this Guide
This guide describes how to administer HP Server Automation (SA), including how to
create and administer SA user accounts, and how to administer multimaster facilities and
SA Satellites. It also discusses how to monitor and diagnose the health of SA
components. This guide is intended for SA administrators who will update facility
information, resolve database conflicts in multiple core environments, manage the
Software Repository Cache, monitor logs, and stop and restart components.
Contents of this Guide
This guide contains the following chapters:
Chapter 1, HP Server Automation Overview: Provides an overview and diagrams of
SA architecture, showing how SA components and features interact in single and multiple
core environments. Each of the components and its function is introduced.
Chapter 2, User and Group Setup: Provides information about how to create and
delete users, user groups, and administrators and how to assign permissions to each.
Chapter 3, Multimaster Mesh Administration: Provides information about how to
manage data across facilities and resolve multimaster conflicts when SA is configured for
multimaster mode.
Chapter 4, Satellite Administration: Provides overview information about a Satellite
facility and how to administer one after installation.
18
Chapter 5, SA Maintenance: Provides information about possible SA problems, how
to contact support, and how to test and diagnose both SA components and managed
servers. It describes how to locate component logs, stop and restart SA components, and
restart order dependencies. It also discusses how to administer the SA Access &
Authentication Directory.
Chapter 6, Monitoring SA: Provides information about performing basic monitoring of
the SA components in a core so that you can automate SA system diagnosis and
monitoring. The type of monitoring information described in the chapter includes the
commands to confirm specific component processes are running, as well as examples of
the expected output, and component specific ports, logs, and administrative URLs.
Chapter 7, SA Configuration: Provides information about how to set several
configuration parameter values that SA uses to send email notifications and alerts, and to
display the SA administrator contact information.
Chapter A, Permissions Reference: Provides information about which SA permissions
to grant SA users so that they access only the areas of functionality relevant to their
responsibilities in the managed server environment.
Conventions in this Guide
This guide uses the following typographical and formatting conventions.
NOTATION DESCRIPTION
Bold Identifies field menu names, menu items, button names, and
inline terms that begin with a bullet.
Courier Identifies text that is entered or displayed at the
command-line prompt, such as Unix commands, SA
commands, file names, paths, directories, environment
variable names, contents of text files that are viewed or edited
with a text editor, source code in a programming language,
and SQL (database) commands.
Italics Identifies document titles, DVD titles, web site addresses.
Used to introduce new terms when they are first defined in a
document and for emphasis.
19
Icons in this Guide
This guide uses the following icons.
Guides in the Documentation Set and Associated Users
The SA Users Guide: Server Automation is intended for system administrators
responsible for all aspects of managing servers in an operational environment. It
describes how to use SA, introducing the system and the user interface. It provides
information about managing servers, remediating servers, script execution,
configuration tracking, deploying and rolling back code, and agent deployment. It also
explains how to use the Global Shell and open a Remote Terminal on managed
servers.
The SA Users Guide: Application Automation is intended for system administrators
responsible for performing the day-to-day functions of managing servers. It reviews
auditing and compliance, software packaging, visual application management,
ICON DESCRIPTION
This icon represents a note. It identifies especially important
concepts that warrant added emphasis.
This icon represents a requirement. It identifies a task that
must be performed before an action under discussion can be
performed.
This icon represents a tip. It identifies information that can
help simplify or clarify tasks.
This icon represents a warning. It is used to identify significant
information that must be read before proceeding.
20
application configuration, and software and operating system installation on managed
servers.
The SA Administration Guide is intended for administrators responsible for monitoring
and diagnosing the health of the SA core components. It also documents how to set up
SA user groups and permissions.
The SA Planning and Installation Guide is intended for advanced system administrators
responsible for planning all facets of an SA installation. It documents all the main
features of SA, scopes out the planning tasks necessary to successfully install SA,
explains how to run the BSA Installer, and details how to configure each of the
components. It also includes information on system sizing and checklists for
installation.
The SA Policy Setters Guide is intended for system administrators responsible for
setting up OS provisioning, configuration tracking, code deployment, and software
management.
The SA Content Utilities Guide is intended for advanced system administrators
responsible for importing content such as software packages into SA. It documents the
following command-line utilities: OCLI 1.0, IDK, and DET (CBT).
The Server Automation Platform Developers Guide is intended for software developers
responsible for customizing, extending, and integrating SA. It documents how to create
Web Services, Java RMI, Python, and CLI clients that invoke methods on the SA API.
21
Chapter 1: SA Overview
SA Technology
SA provides a core set of features that automate critical areas of server and application
operations including the provisioning, deployment, patching, and change management
of servers across major operating systems and a wide range of software infrastructure
and application products.
SA does not just automate your operations, it also allows you to make changes more
safely and consistently, because you can model and validate changes before you actually
commit the changes to a server. SA helps ensure that modifications to your servers work
on your first attempt, thereby reducing the risk of downtime.
Using SA, you can coordinate many operations tasks, across many IT groups with
everyone working with the same understanding of the state of servers, applications, and
configurations. This coordination ensures that all IT administrators have full knowledge of
the current state of the environment before further changes are made.
SA allows you to incorporate and maintain operational knowledge gained through long
hours of trial-and-error processes. After an administrator has found and tested a
procedure or configuration, that knowledge can be translated into a model that is stored in
a central repository. This allows you to continue to benefit from the operational knowledge
gained by your system administrators, even if they are no longer working in your
organization.
I N T H I S C H A P T E R
This section contains the following topics:
SA Technology
Types of SA Users
Types of SA Installations
The Core Components
Interaction Among SA Components
22
The following figure provides an overview of how SA automates server and application
operations across all major platforms and a wide range of applications. Each feature that
is shown in the diagram is discussed in the following sections.
Figure 1-1: Overview of SA Features
Opsware SAS
Policies
ARCHITECTS
NEWYORK DATACENTER
DALLAS DATACENTER
SERVER ADMINS APP ADMINS DEV/RELEASE/NOC IT MANAGERS
Model
Environment
Change
History
Provision
Systems
Set Standards
Provision
Apps
Manage
Change
Report &
Plan
23
Types of SA Users
The following table identifies the types of SA users and their responsibilities.
In addition to the SA users listed above, this guide describes the following three types of
users:
End Users are responsible for all aspects of managing and provisioning the servers in
an operational environment. In the SA documentation, these users are referred to as SA
users or system administrators. These users log into the HP SAS Web Client and SA
Client and use these interfaces to manage servers in their IT environment.
SA Administrators are the users, with special training and information, who are
responsible for installing and maintaining SA. In the SA documentation, these users are
referred to as SA administrators. They use the Administration features in the SAS Web
Client to manage SA and SA users (by adding user accounts and assigning
permissions for different levels of operation and access), to add customers and
facilities, and to change SA configurations. They monitor and diagnose the health of SA
components. SA administrators need to understand how SA features operate to
support users and SA.
Policy Setters are the power users who are responsible for architecting what SA will
do in the managed environment; for example, they determine which operating systems
can be installed on your managed servers and how those operating systems will be
configured during installation. Policy setters, for example, prepare specific features in
SA by defining the Software Policies, preparing Operating System Definitions, and
Table 1-1: Types of SA Users
SA USER RESPONSIBILITIES
Data Center and Operations
Personnel
After manually racking and stacking servers, manage
customer facilities and boot bare-metal servers over the
network or from an SA boot image.
System Administrators Install operating systems and applications (for example,
Solaris 5.7 or WebLogic 6.0 Web Server), upgrade
servers, create operating system definitions, and set up
software management policies.
Site Engineers and
Customer Project Managers
Deploy custom code on servers.
24
acting as Patch Administrators to approve patches for installation in the operational
environment.
SA Environment
In an SA-managed environment, the following two main components are installed in your
facility that provide the core SA platform support and the infrastructure used to run your
operational environment:
SA Core Technology: The set of back-end processes needed to manage the
environment such as the Software Repository, the Model Repository, the Command
Engine, the Data Access Engine, and so forth.
Managed Environment: All servers that SA manages through an installed Server
Agent, which performs tasks such as installing or removing software, installing or
removing patches, and so on. An OS Build Agent also resides on each server and is
responsible for registering bare metal servers with SA and managing the OS installation
process.
Model-Based Control
SA uses a model-based control approach to accomplish infrastructure management.
Users and administrators interact with the SAS Web Client, a Web-based front-end
application, and the SA Client, a Java-based front-end application to accomplish tasks
such as server management, software distribution, OS Provisioning, patch management
and installation, inventory reporting, system diagnosis, and code and content deployment
to the operational environment. SA tracks the operational environment through a back-
end system and data model that has the following key Core Components:
Model Repository: A data repository that stores information about the hardware and
software deployed in the operational environment. All SA components work from, or
update, a data model of information maintained in the Model Repository for all servers
that SA manages.
Software Repository: A central repository for all software that SA manages and
deploys in the operational environment.
Command Engine: A system for running distributed programs across many servers.
SA Agent: On each SA-managed server. Whenever SA needs to enact change on
servers or query servers, it sends requests to the Agents.
25
Types of SA Installations
There are three basic types of SA installations: Single Core (or First Core), Multimaster,
and Satellite.
Single Core: A core in a Single Core installation does not communicate or exchange
information with other cores. A Single Core can manages servers in a single facility,
however, a Single Core can also manage remote servers in locations where a Satellite
Facility has been installed. Typically, though, a Single Core is installed as the First Core
of a Multimaster Mesh because it contains all components of SA necessary for
Multimaster capabilities.
Multimaster: In a Multimaster Mesh installation, cores can exchange information with
other cores as well as replicate the contents of their Model Repositories. In a
Multimaster Mesh, you can centralize the management of several facilities but still get
the performance benefits of having a local, replicated copy of key SA data at each
facility.
Satellite: Satellites are installed in a remote facilities, typically ones that do not have a
large enough potential Managed Server base to justify a full SA Core installation. A
Satellite provides network connectivity to the First Core and bandwidth management
allowing management of the remote servers. A Satellite must be linked to at least one
core, which may be either Single Core or part of a Multimaster Mesh.
This guide uses the term Facility to refer to a collection of servers that a single SA Core
manages. A Facility typically represents a specific geographical location, such as
Sunnyvale, San Francisco, or New York, or, commonly, a specific data center. Each SA
Core or Satellite is associated with a specific facility.
26
The Core Components
The Core Components are the heart of the SA Core making it possible to communicate
with, monitor, and manage servers. Users and developers interact with the core through
the SA Client or SAS Web Client, the command line, the API, and so on. Users can retrieve
vital information about their network servers, provision servers, apply patches, take
servers on and off line, configure and audit servers, and more. This interaction is
controlled by the Core Components.
For example, a user could use the OS provisioning feature of the SA Client to identify an
unprovisioned server, assign an OS Sequence to that server, and remotely begin the
provisioning process.
The following section describes the SA Core Components and interfaces. For detailed
information about how the SA Components work together to manage your servers, see
the Administration Guide.
SA Core Component Bundling
The release of SA 7.50 expands on the concept of SA Core Component Bundling as a
way of distributing Core Components in an SA installation introduced in SA 7.0. Certain
components are bundled together and must be installed as a unit during a Typical
Installation. During a Custom installation, certain components can be broken out of their
bundles (such as the Command Engine, the OS Provisioning Boot Server and Media
Server, among others) and installed on separate servers. For more information about
Typical vs. Custom installations, see Chapter 6, Installing the First Core and Chapter 8,
Multimaster Mesh Installation.
Component Bundling provides the following benefits:
Added simplicity and robustness for multi-server deployments
Scaling capability: you can install additional Slice Components bundles for horizontal
scaling
Improved High Availability
Load balancing between slices when multiple instances installed
New in SA 7.5:
The SA Command Engine is now installable as part of the Slice Component bundle,
therefore you can have multiple Command Engine per core thus increasing SA 7.5s
ability to manage large numbers of servers simultaneously.
27
Table 1-1 shows how components are bundled..
The Boot Agent is unrelated to Server Agents and operates as part of OS Provisioning.
Model Repository
The Model Repository is implemented as an Oracle database. It is a standalone
component and is not bundled with other Core Components. All SA components work
from or update a data model maintained for all servers that SA manages. The Model
Repository contains essential information necessary to build, operate, and maintain the
following items:
Table 1-1: Component Distribution
MODEL
REPOSITORY
INFRASTRUCTURE
COMPONENTS
OS
PROVISIONING
COMPONENTS
SLICE
COMPONENTS
#1
SLICE
COMPONENT
S#2
One per core One per core Typically one
per core
Multiple per
core
Multiple per
core
Model
Repository
Management
Gateway, Primary
Data Access
Engine
Model Repository
Multimaster
Component/Tibco
Software
Repository
Media Server
Boot Server
Core Gateway/
Agent
Gateway
Command
Center
Global File
System
Web Services
Data Access
Engine
Secondary
Data Access
Engine
Build Manager
Command
Engine
Core Gateway/
Agent
Gateway
Command
Center
Global File
System
Web Services
Data Access
Engine
Secondary
Data Access
Engine
Build Manager
Command
Engine
28
An inventory of all servers under SA management.
An inventory of the hardware associated with these servers, including memory, CPUs,
storage capacity, and so on.
Information about the configuration of the servers, including IP addresses.
An inventory of the operating systems, system software, and applications installed on
servers.
An inventory of operating systems and other software that is available to be provisioned
to the servers along with software policies that control how the software is configured
and installed.
Authentication and security information.
Each SA Core contains a single Model Repository.
The Core Component Bundles
Infrastructure Components Bundle
Primary Data Access Engine
The Data Access Engine provides an XML-RPC interface to the Model Repository that
simplifies interaction with various clients, such as the SAS Web Client, system data
collection, and monitoring agents on servers. The Data Access Engine installed with the
Infrastructure Component bundle is designated the Primary Data Access Engine. The
Data Access Engine installed with the Slice Component bundle(s) is designated the
Secondary Data Access Engine.
Because interactions with the Model Repository go through the Data Access Engine,
clients are less impacted by changes to the Model Repositorys schema. The Data
Access Engine allows features to be added to SA without requiring system-wide
changes.
Management Gateway
Manages communication between SA Cores and between SA Cores and Satellites.
Model Repository Multimaster Component/TIBCO Rendezvous
The Model Repository Multimaster Component is installed with the Infrastructure
Component bundle. A Multimaster Mesh, by definition, has multiple core installations
and the Model Repository Multimaster Component synchronizes the data in the Model
Repositories for all cores in the Mesh, propagating changes made in one repository to
29
the other repositories. The Model Repository Multimaster Component uses TIBCO
Rendezvous and its underlying transport capabilities.
Each Model Repository Multimaster Component consists of a Sender and a Receiver.
The Sender (Outbound Model Repository Multimaster Component) polls the Model
Repository and sends unpublished transactions to other Model Repositories. The
Receiver (Inbound Model Repository Multimaster Component) accepts the transactions
from other Model Repositories and applies them to the local Model Repository.
Software Repository
A repository in which the binaries/packages/source for software/application
provisioning and remediation is uploaded and stored.
For information about how to upload software packages to the Software Repository, see
the SA Configuration Guide.
Slice Components Bundle
Command Engine
The Command Engine is a system for running distributed programs across many
servers (typically through SA Server Agents). Command Engine scripts are written in
Python and run on the Command Engine server. Command Engine scripts can issue
commands to Server Agents. These calls are delivered in a secure manner and are
auditable by using data stored in the Model Repository.
SA features (such as Code Deployment & Rollback) can use Command Engine scripts
to implement part of their functionality.
As of SA 7.50, the Command Engine resides in the Slice Component bundle. Because
you can have multiple Slice Component bundles, and therefore multiple Command
Engines, horizontal scaling is greatly enhanced. Multiple Command Engine instances
can share the load of command delivery and script execution by taking advantage of
the load balancing mechanism provided by multiple Slice Component bundles. Failover
and high availability are also improved. For example, when a Command Engine
instance tries to delegate a command to another node in the cluster and that node is
down, it fails over to the next node.
Core Gateway/Agent Gateway
The Core Gateway communicates directly withe Agent Gateways passing requests and
responses to and from Core Components. Agent Gateways are installed on Managed
Servers and communicate with the Core Gateway
30
Command Center
The Command Center (OCC) is the Core Component that underlies the SAS Web
Client. The OCC includes an HTTPS proxy server and an application server. You access
the OCC only through the SAS Web Client.
Global File System
The Global File System (OGFS) is installed with each Slice Component Bundle and
provides the central execution environment for SA.
The OGFS runs on one or more physical servers; customers can scale SA execution
capacity by simply adding additional Slice Component bundles in a core.
The OGFS runs SA built-in components as well as customer-written programs
within a virtual file system that presents the SA data model, SA actions, and managed
servers as virtual files and directories.
This unique feature of SA allows users of the Global Shell and Automation Platform
Extensions (APX) to query SA data and manage servers from any scripting or
programming language. Since the OGFS filters all data, actions, and managed server
access through the SA security model, programs running in the OGFS are secure by
default.
Web Services Data Access Engine
The Web Services Data Access Engine provides a public-object abstraction layer to the
Model Repository and provides increased performance to other SA Core Components.
This object abstraction can be accessed through a Simple Object Access Protocol
(SOAP) API, through third-party integration components, or by a binary protocol of SA
components such as the SAS Web Client.
Secondary Data Access Engine
The Data Access Engine provides an XML-RPC interface to the Model Repository that
simplifies interaction with various clients, such as the SAS Web Client, system data
collection, and monitoring agents on servers. The Data Access Engine installed with the
Infrastructure Component bundle is designated the Primary Data Access Engine. The
Data Access Engine installed with the Slice Component bundle(s) is designated the
Secondary Data Access Engine.
Because interactions with the Model Repository go through the Data Access Engine,
clients are less impacted by changes to the Model Repositorys schema. The Data
31
Access Engine allows features to be added to SA without requiring system-wide
changes.
Build Manager
Although the Build Manager is part of the OS Provisioning feature it is installed as part
of the Slice Component bundle. The Build Manager facilitates communications
between OS Build Agents and the Command Engine. It accepts OS Provisioning
commands from the Command Engine. It provides a runtime environment for the
platform-specific build scripts to perform the OS Provisioning procedures.
OS Provisioning Components Bundle
Boot Server
The Boot Server is part of the OS Provisioning feature. It supports network booting of
Sun and x86 systems with inetboot and PXE, respectively. The processes used to
provide this support include the Internet Software Consortium DHCP server, Sun Solaris
TFTP, and NFS.
Media Server
The Media Server is part of the OS Provisioning feature. It is responsible for providing
network access to the vendor-supplied media used during OS Provisioning. The
processes used to provide this support include the Samba SMB server and Sun
Solaris/Linux NFS. You copy and upload your valid operating system installation media
to the Media Server.
OS Build Agent: The OS Build Agent is part of the OS Provisioning feature. It runs during
the pre-provisioning (network boot) process and is responsible for registering a bare
metal server with the SA Core through the Build Manager and guiding the OS installation
process.
Satellite Installations
Software Repository Cache
A Software Repository Cache contains local copies of the contents of a Cores Software
Repository (or of another Satellite). Having a local copy of the Software Repository can
improve performance and decrease network traffic when you install or update software
on a Satellites Managed Servers.
32
Interaction Among SA Components
To understand SA architecture, review the following types of SA component interactions:
General Interaction Among Components
SA Security
OS Provisioning
Patch Management
Software Management
Code Deployment and Rollback
Script Execution
Integration with AIX and HP-UX Installation Technology
Component Interaction in Multiple Facilities
Discovery and Agent Deployment
Application Configuration Management
Audit and Remediation
General Interaction Among Components
The SAS Web Client, Command Engine, Software Repository, and Server Agent interact
with the Model Repository through the Data Access Engine.
The Data Access Engine issues queries against the Model Repository. It does not cache
query results.
The Software Repository authenticates all clients. It maps the client's IP address to the
customer name. The Software Repository performs this mapping to enforce access rules
on customer-specific files.
SA Security
To enable secure communication with the Server Agent, SA automatically issues a unique
cryptographic certificate to every server that it manages. The certificate is tied to the
server to which it is issued, and cannot be copied and used by a different server. The
certificate allows the Server Agent to establish a secure HTTPS connection to SA Core
Components.
33
As an additional security measure, SA performs checks on all requests that a Server
Agent issues. SA verifies that the requested operation is appropriate for the particular
server and checks the parameters of the request to make sure that they fall within
reasonable bounds.
OS Provisioning
The OS Provisioning feature supports installation-based provisioning using Red Hat Linux
Kickstart, Sun Solaris JumpStart, and Microsoft Windows unattended installation. Image-
based provisioning using Microsoft WIM imaging is supported. Image-based provisioning
using Symantec Ghost and Sun Solaris Flash is supported, but not out-of-the-box.
Because the OS Provisioning feature supports installation-based provisioning, your
organization can keep its OS installations lean. Rather than trying to manage changing
software through master images, you can use the Software Management feature to install
and remove often changing software, including system patches, system utilities, and third-
party agents (such as monitoring, backup, and anti-viral agents). See the SA Users
Guide: Application Automation and the SA Policy Setters Guide for information about the
OS provisioning process.
OS Provisioning Phase 1: Initial Booting:
1 The DHCP request is a network broadcast.
2 The DHCP reply contains the IP address and TCP port of the appropriate Core Agent
Gateway for use by Solaris JumpStart and WinPE-based Windows provisioning. For
Microsoft Windows provisioning using the DOS-based preinstallation environment,
the gateway IP and port combination is embedded in the floppy images by the
HP BSA installer at install-time.
3 TFTP is used to boot the server over the network (using PROM-based inetboot for
Solaris SPARC, and PXE for Solaris x86, Windows, Linux, and VMware ESX). Instead
of PXE, the DOS-based pre-installation environment for Windows can use a boot
floppy and the WinPE pre-installation environment for Windows and LInux can use a
boot CD.
4 An NFS boot image is used by Solaris and Linux only.
5 The OS Build Agent pings the Build Manager.
6 The Build Manager invokes a Build Script that probes the servers hardware.
7 The server is registered with SA.
34
8 The OS Build Agent periodically contacts the Build Manager with a ping message.
The system remains in this state until a user provisions an OS onto the server with
the SAS Web Client or until the server is removed from the network.
OS Provisioning Phase 2: OS Installation:
1 A user initiates OS provisioning with the Install OS Wizard in the SAS Web Client or
runs an OS sequence from the SA Client. For information on using an OS sequence
see SA Users Guide: Application Automation.
2 Feedback is provided throughout OS provisioning with status messages passed from
the Build Manager to the Command Engine and from the Command Engine to the
SA Client.
3 A Media Resource Locator (MRL) contains the network location (host name and
path) of an NFS or SMB server from which to retrieve the vendor OS installation
media or obtain the WIM install image.
4 The installation media is mounted with NFS (Solaris and Linux) or SMB (Windows).
5 The vendor installation program is used to install the OS (Sun Solaris Jumpstart, Red
Hat Linux Kickstart, VMware ESX or Windows unattended install).
6 The server is rebooted after OS installation (depending on the installation type, there
might be multiple reboots).
7 The OS Build Agent gets a copy of the Server Agent from the Software Repository.
8 The OS Build Agent is used to install the Server Agent.
9 Hardware and software registration is performed as part of the Server Agent
installation.
10 The remediate function installs additional software that the vendor installation
program did not install.
Phase 2, Steps 3 through 10 are managed by a build script that runs inside the Build
Manager. The build script is invoked by the provisionOS script and manages the OS
installation at a micro level. The provisionOS script is run by the Command Engine and
is responsible for managing the installation process at a macro level.
35
Patch Management
SA automates the key aspects of patch management, while offering a fine degree of
control over how and under what conditions patches are installed.
Because patches are often released to address grave security threats, an organization
needs to be able to roll out patches quickly, before systems become compromised. At the
same time, however, patches can cause serious problems, from performance degradation
to general system failure.
The Patch Management feature allows you to react quickly to newly discovered threats,
but it also provides support for strict testing and standardization of patch installation. And,
if patches later cause problems even after being tested and approved, the Patch
Management feature also allows you to uninstall the patches in a safe and standardized
way.
See the SA Users Guide: Application Automation for information about the patch
management process.
Windows Patches
1 An SA user with the required permissions logs into the SA Client and selects
Opsware Administration Patch Settings from the Navigation pane. To import the
patch database from the Microsoft web site, click Import from Vendor.
2 The Software Repository places a record of the location, file size, and patch state of
each patch in the Model Repository with the Data Access Engine.
See the SA Users Guide: Application Automation for information about importing the
Microsoft patch database.
Unix Patches
1 An SA user with the required permissions logs in to the SA Client and selects Library
By Folder from the Navigation pane and then selects the folder in which the patch
should be located.
2 From the Actions menu select Import Software. The Import Software window
displays.
3 Using the Import Software window, the user specifies a Patch type and Platform and
uploads the file to the Software Repository.
36
See the SA Users Guide: Application Automation for information about the importing
software process.
install patch process:
1 An SA user with the required permissions logs in to the SA Client and selects Install
Patch from the Actions menu. The Install Patch window displays.
2 Using the Install Patch window, the user specifies patches, servers, reboot options,
pre and post install scripts, scheduling information, and starts the install process,
retrieving patch information from the Model Repository with the Web Services Data
Access Engine.
4 The Command Engine gets a list of installed software from the Server Agent on the
managed servers. It compares it to the user-specified list of patches to determine
what needs to be installed.
5 The Server Agent on each managed server downloads patches from the Software
Repository and installs them, performing all required install operations and reboots.
6 When installation is complete, a record of all currently-installed software is stored in
the Model Repository with the Data Access Engine.
7 The Server Agent on each managed server reports installation status to the
Command Engine.
8 The Command Engine stores installation status in the Model Repository with the
Data Access Engine.
9 An operation complete status message displays in the SA Client.
Uninstall patch process:
1 An SA user with the required permissions logs in to the SA Client and selects
Uninstall Patch from the Actions menu. The Uninstall Patch window displays.
2 Using the Uninstall Patch window, the user specifies patches, servers, reboot options,
pre and post uninstall scripts, scheduling information, and starts the uninstall
process, retrieving server and patch information from the Model Repository with the
Web Services Data Access Engine.
3 The SA Client passes uninstall operation details to the Command Engine.
37
4 The Command Engine gets a list of installed software from the Server Agent on the
managed servers. It compares it to the user-specified patch to be uninstalled and
determines if it does need to be uninstalled.
5 The Server Agent on each managed server removes the patch from the managed
servers and performs all required uninstall operations and reboots.
6 When uninstallation is complete, a record of all currently-installed software is stored
in the Model Repository with the Data Access Engine.
7 The Server Agent on each managed server reports uninstallation status to the
Command Engine.
8 The Command Engine stores uninstallation status in the Model Repository with the
Data Access Engine.
Patch policy remediation process for vendor-recommended (Windows) patches:
1 Every 24 hours, the Server Agent builds an inventory of software installed on the
server. It uses that inventory and the Microsoft Patch Database to determine what
Hot fixes and Service Packs are needed to bring the server up to current patch level.
This is the Recommended Patch List.
2 The Recommended Patch List and a full inventory of installed software is stored in
3 An SA user with the required permissions logs in to the SA Client and attaches the
vendor-recommended patch policy to the server.
4 Using the Remediate window, the user performs the patch policy remediation
process to install the patches in the vendor-recommended patch policy.
5 The installation details are passed from the SA Client to the Command Engine, which
obtains a list of installed software from the Server Agent. It compares this list to the
user-selected list and determines what actually needs to be installed.
6 The Server Agent on the managed server downloads patches from the Software
Repository and installs them, performing all required install operations and reboots.
7 When installation is complete, a record of all currently installed software is stored in
8 Install operation status is reported to the Command Engine, which places it in the
Model Repository with the Data Access Engine.
38
Software Management
In SA, packages reside in a central Software Repository. SA policy setters upload the
packages and patches and also specify options that help ensure that the software is
installed in a safe and consistent way. Policy Setters then create software policies and
add the software resources such as packages, patches, application configurations, and
other software policies to the software policy. In a software policy they specify the
installation order for software installation. A system administrator then attaches the
software policy to a server and remediates the server. During remediation, the software
specified in the software policy is installed on the server.
SA maintains detailed information about the state of every server under management in a
central database called the Model Repository. This information includes details about
software that is installed. You can use the information to check the rollout of software and
also to help diagnose common server problems. Information about the software is
consolidated into the centralized Model Repository. See the SA Policy Setters Guide for
information about the software management process.
Software installation process:
Software Installation Phase 1: Determine Server Configuration:
1 An SA user logs into the SA Client and selects one or more servers and software
policies to remediate against.
2 The SA Client starts the Preview Remediate Job in the Web Services Data Access
Engine.
3 The Server Agent on each of the specified servers is queried by the Command
Engine for a list of software installed on its server.
4 The Command Engine, via the Web Services Data Access Engine, compares that list
to the user-specified list of software policies to determine what needs to be installed
or removed.
Software Installation Phase 2: Software Installation through Remediate
1 At the end of Remediate Preview, the SA Client displays a list of the software to be
installed and/or removed. The user confirms proceeding with the remediate.
2 The SA Client starts the Remediate job in the Command Engine.
39
Engine for a list of software installed on its server.
4 The Command Engine, via the Data Access Engine, compares that list to the user-
specified list of software policies to determine what needs to be installed or removed.
5 The Command Engine tells the Server Agent to install and/or remove software.
6 The Server Agent downloads software from the Software Repository, removes any
software that need to be removed, and installs the new software, performing all
necessary install, uninstall, and reboots, if required.
7 The Server Agent reports installation status to the Command Engine.
Engine for a list of software installed on its server to confirm what was installed and/
or removed.
9 The Command Engine stores installation status in the Model Repository via the Data
Access Engine.
10 Status of completed installation and removal of software displays in the SA Client via
the Command Engine and the Web Services Data Access Engine.
Code Deployment and Rollback
Before you use Code Deployment and Rollback (CDR) to push code and content, you
must upload new or updated files to your SA staging environment. You can use SA-
supported content management tools, such as OpenDeploy, scp, or rsync over SSH, to do
that.
After you upload the files and test your changes, you can synchronize updates to the
production hosts that run your operational environment. You can run specific
synchronizations and perform other service deployment operations by selecting CDR
menu options available from the SAS Web Client navigation panel. Figure shows the
code deployment and rollback process.
See the SA Users Guide: Server Automation for information about the process to deploy
code and content to servers in the managed environment.
Code deployment and rollback process:
1 An SA user with the required permissions logs into the SAS Web Client, clicks the
Deploy Code link, selects a code deployment action, and clicks Run.
40
2 The SAS Web Client gets code deployment details from the Model Repository via the
Data Access Engine.
3 The SAS Web Client sends code deployment details to the Command Engine.
4 The Command Engine sends commands to staging and production servers.
5 Results of the code push are sent back to the Model Repository via the Data Access
Engine.
6 The user views results of the code push.
Script Execution
The Script Execution feature provides features and tools for automating the management
and execution of server scripts. Previously, a user created a script and then manually
executed the script at individual servers, one server after another. With the Script
Execution feature, a user performs all script tasks at one location the SAS Web Client.
From the SAS Web Client, you can create or upload a script, set it up to run
simultaneously across multiple Unix or Windows servers, and monitor it as it executes on
each server. After a script runs, job- and server-specific execution results are available for
review. You can modify, delete, or rerun a script at a later date.
See the SA Users Guide: Server Automation for information about the process to create
and execute scripts in the managed environment.
Script execution upload script process:
1 An SA user with the required permissions logs into the SAS Web Client and clicks the
Scripts link under Software and then clicks New Script.
2 The user clicks Upload Script, defines the path, enters Usage Notes, and clicks
Save. The script is uploaded and saved in the Model Repository by the Command
Engine via the Data Access Engine.
3 The Web Services Data Access Engine displays the newly uploaded script in the list
of available scripts.
Script execution execute script process:
1 An SA user with the required permissions logs into the SAS Web Client and clicks the
Run Distributed Script Wizard link on the home page.
2 The user selects the scripts and the servers on which to execute the script and clicks
Run Script. The request is passed to the Command Engine.
41
3 The Command Engine contacts the Server Agent on the selected servers and tells it
to execute the script.
4 The Server Agent runs the script and sends the results back to the Command
Engine.
5 The Command Engine aggregates the scripts and stores them in the Model
Repository via the Data Access Engine.
6 The Model Repository sends the results to the SAS Web Client via the Data Access
Engine for the user to view.
Integration with AIX and HP-UX Installation Technology
Integrating SA with an OS installation technology enables installing an OS by using
vendor utilities and automatically installing the Server Agent, which registers servers initial
configurations with the Model Repository.
SA integration with AIX and HP-UX operating systems:
1 Installation technology installs the OS.
2 SA integration downloads and installs the Server Agent on the server.
3 The Server Agent determines hardware, software, customer, and facility information
and records the server information in the Model Repository via the Data Access
Engine.
4 The Server Agent Installer attaches the server to the specified OS template.
5 (Optional) The server is remediated with the modeled OS in the Model Repository.
Component Interaction in Multiple Facilities
The steps below illustrate how SA components interact when SA is running in multiple
facilities. See Multimaster Facilities Administration on page 89 for information on how to
administer this SA configuration.
1 An SA user updates the managed environment.
2 The Data Access Engine sends an update to the Model Repository.
3 A trigger fires in the Model Repository, and the changes are saved in the transaction
table in the Model Repository.
4 The Outbound Model Repository Multimaster Component monitors the transaction
table for updates.
42
5 The Outbound Model Repository Multimaster Component publishes the updated
message to TIBCO.
6 TIBCO connects to the Gateway in Facility 1 and sends the updated message.
7 The updated message travels over the tunnel between facilities and arrives at the
Gateway in Facility 2.
8 The Gateway in Facility 2 sends the message to TIBCO.
9 The Inbound Model Repository Multimaster Component in Facility 2 receives the
TIBCO event with updates.
10 The Inbound Model Repository Multimaster Component in Facility 2 updates the
local Model Repository.
The SA Discovery and Agent Deployment (ODAD) utility allows you to remotely discover
unmanaged servers in your data center, deploy Server Agents to those servers, and place
them under SA management.
Discovering unmanaged servers and deploying Server Agents:
1 An SA user launches ODAD from the SA Client and selects a scan location. The scan
location determines which Agent Deployment Helper will perform the scan. Each
Gateway can act as an Agent Deployment Helper.
2 The user specifies a range of IP addresses to scan.
3 The Agent Deployment Helper scans those IPs, determines if anything is using those
IP addresses and what ports are open.
4 Scan results are displayed in the SA Client.
5 The user selects one or more servers, provides a login name and password, sets any
install options and chooses the agent deployment option.
43
6 For Unix:
1. The Agent Deployment Helper tries to log onto the server by using available
protocols.
2. It determines the operating system of the server.
3. It checks agent installation prerequisites.
4. It downloads the agent installer.
5. It installs the Server Agent on the server.
For Windows:
1. The Windows Agent Deployment Helper establishes a tunnel via the Gateway
mesh to the server, then proceeds through the same steps as for Unix.
2. The list of servers is updated in the SA Client to show the status of the Server
Agent installation.
Application Configuration Management
SA Application Configuration Management (ACM) allows you to create configuration
templates so you can modify and manage application configuration files associated with
server applications. ACM enables you to manage and update and modify those
configurations from a central location, so you can always be sure that applications in your
data center are accurately and consistently configured the way you want them to be.
Discovering unmanaged servers and installing the Server Agent on those servers:
Part A: Create an Application Configuration and Associated Templates
1 An SA user chooses a gold configuration for an application on a managed server
and retrieves the configuration files.
2 The user edits these configuration files, creating a CML file, turning some values into
variables that can later be configured at a global or granular level.
3 The user creates templates for the Application Configuration and pastes in the edited
CML files.
4 The user logs into the SA Client and creates an Application Configuration, which is
stored in the Model Repository.
Part B: Configure and Push Application Configurations to Servers
5 The user chooses servers or server groups in the SA Client and adds an Application
Configuration to the target servers.
44
6 The user uses the Value Set Editor to configure the application for these servers, and
these values are saved in the Model Repository.
7 The user clicks Push to enable the application configuration to the target servers. To
accomplish this action, the Web Services Data Access Engine communicates with
the Command Engine to create a session ID. The Command Engine then passes
session data back to the Web Services Data Access Engine which communicates
with the Global File System to push application configurations to managed servers.
Audit and Remediation
The SA Audit and Remediation feature enables SA users to keep managed servers up-to-
date by comparing them to known working servers.
Audit and Remediation: Take a Snapshot:
1 An SA user chooses a snapshot specification to run.
2 The user clicks Run, which invokes the appropriate command on the Web Services
Data Access Engine.
3 The Web Services Data Access Engine communicates with the Command Engine to
coordinate the snapshot.
4 The Global File System is used to provide snapshot information from the managed
server.
5 The snapshot information is assembled in the Global File System.
6 The snapshot information recorded is stored in the Software Repository.
7 The snapshot information is stored in the Data Access Engine.
Audit and Remediation: Run an Audit
1 An SA user chooses an audit to use.
2 The user clicks Run, which invokes the appropriate command on the Web Services
Data Access Engine.
3 The Web Services Data Access Engine communicates with the Command Engine to
coordinate the audit.
4 The Global File System is used to provide audit information from the managed server.
5 The audit information is assembled in the Global File System.
6 The Command Engine issues the create audit command.
45
7 The Global File System loads appropriate snapshots and performs a difference.
8 The resulting audit is uploaded to the Software Repository.
9 The audit is stored in the Data Access Engine.
Audit and Remediation: View results of audit or snapshot
1 An SA user gets a list of available snapshots or audit results information.
2 The user requests detailed information about a snapshot or an audit.
3 The results are returned from the Software Repository to the user.
46
47
Chapter 2: User and Group Setup
Users, Groups, and Permissions
SA enforces security policy that allows only authorized users to perform specific
operations on specific servers. Intended for security administrators, this chapter explains
how to set up a role-based security structure for SA.
SA Users and User Groups
When you log in to the SA Client or the SAS Web Client, you are prompted for an SA user
name and password. Everyone in your organization who logs on to SA must have a
unique SA user name and password. SA user names are stored in the Model Repository.
You can create user names with the SAS Web Client, or you can import them into the
Model Repository from an external Lightweight Directory Access Protocol (LDAP) system.
SA user names are not case sensitive.
A user group represents a role played the people in your organization who log in to SA.
Every user should belong to one or more SA user groups. The tasks that a user is
authorized to perform depend on the groups the user belongs to.
This section discusses the following topics:
Users, Groups, and Permissions
Managing Users and User Groups
Setting Permissions on User Groups
Managing Super and Customer Administrators
Managing Passwords and Login Settings
External LDAP Directory Service with SA
Code Deployment Permissions
User and Security Reports
48
SA Permissions
The permissions that you specify for a user group determine what the groups members
can do with SA. Feature permissions specify what actions users can perform; resource
permissions indicate which objects (typically servers) users can perform these actions on.
For example, Jane Doe could belong to a user group called London Windows
Administrators. This user group has the feature permission to install patches, and the
resource permission to Read & Write on the device group named London Windows
Servers.
Feature Permissions
An SA feature is a task, such as running a script or uploading a patch. With feature
permissions, you define the tasks that can be performed by the users of a group. A
feature permission is either on or off: The user can either perform a task or cannot. In the
SAS Web Client, you specify feature permissions on the Features, Client Features, and
Others tabs of the Edit Group page.
Resource Permissions
A resource is usually a set of managed servers. A resource permission determines if the
users in a user group can view or modify a resource. Resource permissions specify the
following types of access:
Read: Users can view the resource only.
Read & Write: Users can view, create, modify or delete the resource.
None: The resource does not appear in the SA Client or the SAS Web Client. Users
cannot view or modify the resource.
The SAS Web Client organizes resources into the following categories:
Customers: The servers associated with a customer.
Facilities: The servers associated with a facility.
Device Groups: The servers belonging to the specified public device group.
Each of the preceding resource categories corresponds to a tab on the Edit Group page
of the SAS Web Client.
Managed servers are the most common resources. Other types of resources are
application configurations, hardware definitions, realms, and OS installation profiles. Each
of these resources can be associated with customers.
49
Folders can also be associated with customers, but the access to folders is controlled in a
different way. (See Folder Permissions on page 50.)
Server Access and Resource Permissions
Access to a server depends on the servers association to a customer, association to a
facility, and optionally, its membership in a public device group. For example, suppose
that a server is associated with the Widget, Inc. customer, resides in the Fresno facility,
and belongs to the Accounting device group. To modify the server, the user group must
have the permissions listed in Table 2-1. (The Read & Write permission for Accounting is
required only if user group permissions are specified for public device groups.)
If the permissions for the customer, facility, or device group do not match, then the most
restrictive permissions are enforced. For example, if the permission for the customer is
Read & Write, but the permission for the facility is Read, then the Read permission is
enforced. If the permission for the customer is None, then the server cannot be viewed,
even if the other permissions for the user group specify Read (or Read & Write).
Feature and Resource Permissions Combined
To use a feature on a resource, the user must belong to a group that has the necessary
permissions for both the feature and resource. For example, suppose that a server is
associated with these resources: the Widget, Inc. customer and the Fresno facility. To
install a patch on this server, the user must belong to a group with the permissions listed
in Table 2-2.
Table 2-1: Example of Resource Permissions
RESOURCE GROUP PERMISSION
Customer: Widget, Inc. Read & Write
Facility: Fresno Read & Write
Device Group: Accounting Read & Write
Table 2-2: Example of Permissions Resources and Features
RESOURCE OR FEATURE GROUP PERMISSION
Facility: Fresno Read & Write
Feature: Install Patch Yes
50
Folder Permissions
Folder permissions control access to the contents of the folder, such as software policies,
OS sequences, server scripts, and subfolders. A folders permissions apply only to the
items directly under the folder. They do not apply to items lower down in the hierarchy,
such as the subfolders of subfolders (grandchildren).
Types of Folder Permissions
In the Folders Properties window of the SA Client, you can assign the following
permissions to an individual user or a user group:
List Contents of Folder: Navigate to the folder in the hierarchy, click on the folder, view
the folders properties, see the name and type of the folders children (but not the
attributes of the children).
Read Objects Within Folder: View all attributes of the folders children, open object
browsers on folders children, use folders children in actions.
For example, if the folder contains a software policy, users can open (view) the policy
and use the policy to remediate a server. However, users cannot modify the policy. (For
remediation, feature and server permissions are required, as well.)
Selecting this permission automatically adds the List Contents of Folder permission.
Write Objects Within Folder: View, use, and modify the folders children.
This permission permits actions such as New Folder and New Software Policy. To
perform most actions, client features are required as well.
Selecting this permission automatically adds the List Contents of Folder and the Read
Objects Within Folder permissions.
Execute Objects Within Folder: Run the scripts contained in the folder and view the
names of the folders children.
This permission allows users to run scripts, but not to read or write them. To view the
contents of scripts, users need the Read Objects Within Folder permission and the
appropriate feature permission. To create scripts, they need the Write Objects Within
Folder permission and the appropriate feature permission.
Selecting the Execute Objects Within Folder permission automatically adds the List
Contents of Folder permission.
Edit Folder Permissions: Modify the permissions or add customers to the folder.
51
This permission enables users to delegate the permissions management of a folder
(and its children) to another user group.
Selecting this permission automatically adds the List Contents of Folder permission.
Client Feature Permissions and Folders
Client feature permissions determine what actions users can perform with the SA Client.
Folder permissions specify which folders users have access to.
To perform most actions on folders and the items they contain, users need both folder
and client feature permissions. For example, to add a software policy to a folder, users
must belong to a group that has the Write Objects Within Folder permission and the
Manage Software Policy permission (Read & Write).
Customer Constraints, Folders, and Software Policies
If a customer is assigned to a folder, the customer constrains some of the actions on the
software policies contained in the folder. These constraints are enforced through filtering:
The objects that can be associated with the software policies must have a matching
customer.
For example, suppose that you want to add the quota.rpm package to a software
policy. The package and the software policy reside in different folders. The customer of
the policys parent folder is Widget and the customer of the packages parent folder is
Acme. When you perform the Add Package action on the policy, the packages that you
can choose will not include quota.rpm. The customer of the policys parent folder
(Widget) acts as a filter, restricting the objects that can be added to the policy. If you add
the Widget customer to the parent folder of quota.rpm, then you can add quota.rpm
to the policy.
The following list summarizes the customer contraints for software policy actions. These
constraints are invoked only if the software policys parent folder has one or more
customers. Software policy actions not listed here, such as New Folder, do not have
customer constraints.
Add Package: The customers of the package's parent folder must be a subset of the
customers of the software policy's parent folder.
Add Application Configuration: The customers of the application configuration must
be a subset of the customers of the software policy's parent folder.
Add Software Policy: If software policy A is added to software policy B, then the
customers of A's parent folder must be a subset of the customers of B's parent folder.
52
Attach Software Policy: The customer of the server being attached must be one of
the customers of the software policy's parent folder.
Install Software Policy Template: The customer of the server must be one of the
customers of the parent folder of each software policy contained in the template.
Default Folder Permissions
When SA is first installed, the predefined user groups are assigned permissions to the
top-level folders such as Package Repository. When you create a new folder, it has the
same permissions and customer as its parent.
SA Global File System Permissions
The SA Global File System (OGFS) underlies many SA Client actions, such as browsing
managed server file systems and scanning servers for compliance. To perform actions
that access the OGFS, you must belong to a user group that has certain OGFS
permissions. Table 2-3 lists the operations you control with OGFS permissions.
Table 2-3: OGFS Permissions
OGFS PERMISSION TASK ALLOWED BY THIS PERMISSION
Launch Global Shell Launch the Global Shell.
Log In To Server Open a shell session on a Unix server. In the SA Client,
open a Remote Terminal. In the Global Shell, you can
use the rosh command.
Read COM+ Database Read COM Plus objects as a specific login. In the
SA Client, use the Device Explorer to browse these
objects on a Windows server.
Read Server File System Read a managed server as a specific login. In the
SA Client, use the Device Explorer to browse the file sys-
tem of a managed server.
Read IIS Metabase Read IIS Metabase objects as a specific login. In the
SA Client, use the Device Explorer to browse these
objects on a Windows server.
Read Server Registry Read registry files as a specific login. In the SA Client,
use the Device Explorer to view the Windows Registry.
53
When setting an OGFS permission, in addition to specifying an operation such as Write
Server File System, you also specify which managed servers the operation can be
applied to. You specify the managed servers by selecting a resource, either a customer,
facility, or device group. You also specify the login name of the managed server where the
operation runs. (The Launch Global Shell operation is an exception, as explained later in
this section.)
For example, suppose you specify the Read Server File System permission. For the
servers, you select a device group named Sunnyvale Servers. For the login name, you
select the SA user name. Later on, in the SA Client, the SA user jdoe opens a server
belonging to the Sunnyvale Servers device group in the Device Explorer. In the Views
pane, the string jdoe appears in parentheses next to the File System label. When the user
drills down into the file system, the Device Explorer displays the files and directories that
the Unix user jdoe has access to.
If you specify root for the login name, make sure that the resource you select allows
access to the correct set of servers. For root, you should limit access to servers by
customer or device group, not by facility.
For the Launch Global Shell permission, you do not specify the managed servers
because a Global Shell session is not associated with a particular server. Also, you do not
specify the login user for this permission. If you open a Global Shell session with the SA
Client, you do so as your current SA login. If you open it with the ssh command, you are
prompted for an SA login (user name).
Relay RDP Session To Server Open an RDP session on a Windows server. In the
SA Client, this is the Remote Terminal feature that opens
an RDP client window for a Windows server.
Run Command On Server Run a command or script on a managed server using
the rosh utility, where that command or script already
exists. In the SA Client, this is used for Windows
Services accessed by the Device Explorer.
Write Server File System Modify files on a managed server as a specific login. In
the SA Client, you can use the Device Explorer to modify
the file system of a managed server.
Table 2-3: OGFS Permissions (continued)
OGFS PERMISSION TASK ALLOWED BY THIS PERMISSION
54
Membership in Multiple Groups
If a user belongs to more than one user group, the users permissions are derived from
the resource and feature permissions of the groups. The way the permissions are derived
depends on whether or not the resources are folders.
If the resources are not folders, then the derived permissions are a cross-product of the
resource and feature permissions of all groups that the user belongs to. With a cross
product, all feature permissions apply to all resource permissions. For example, Jane Doe
belongs to both of the Atlanta and Portland groups, which have the permissions listed in
Table 2-4. Because the derived permissions are a cross-product, Jane can perform the
System Diagnosis task on the managed servers associated with the Widget Inc.
customer, even though neither the Atlanta nor Portland group has this capability.
If the resources are folders (or their contents), then the derived permissions for the user
are cumulative, but do not cross user groups. For example, Joe Smith belongs to both the
Sunnyvale and Dallas groups shown in Table 2-5. Joe can create packages under the
Webster folder because the Sunnyvale group has Read & Write permissions for that folder
and for the Manage Package feature. However, Joe cannot create packages under the
Kiley folder, because neither user group can do so. Joe can create OS Sequences under
the Kiley folder, but not under the Webster folder.
Table 2-4: Example of Cross-Product Permissions
RESOURCE OR FEATURE
ATLANTA USER GROUP
PERMISSION
PORTLAND USER GROUP
PERMISSION
Resource:
Customer Widget, Inc.
Read & Write None
Resource:
Customer Acme Corp.
None Read & Write
Feature:
System Diagnosis
No Yes
Table 2-5: Example of Cumulative Permissions
RESOURCE OR FEATURE
SUNNYVALE USER GROUP
PERMISSION
DALLAS USER GROUP
PERMISSION
Resource:
Folder Webster
Read & Write None
55
SAS Web Client Restricted Views
The SAS Web Client displays only those features and resources that the users group has
Read (or Read & Write) permissions.
For example, John Smith belongs to the Basic Users group, which has the permissions
listed in Table 2-6. When John logs in, the SAS Web Client displays only the servers for
Widget Inc., but not those of Acme Corp. In the navigation panel of the SAS Web Client,
the Operating Systems link appears, but not the Scripts link.
To locate or view a server, a user must belong to a group that has Read (or Read & Write)
permission to both the customer and facility associated with the server. If the server also
belongs to a device group with set permissions, then the user group must also have Read
(or Read & Write) access to the device group. Otherwise, the user cannot locate the
server in the SAS Web Client.
Resource:
Folder Kiley
None Read & Write
Feature:
Manage Packages
Read & Write None
Feature:
Manage OS Sequences
None Read & Write
Table 2-6: Example of Permissions and Restricted Views
RESOURCE OR FEATURE
BASIC GROUP
PERMISSION
Customer: Acme Corp. None
Wizard: Prepare OS Yes
Wizard: Run Scripts No
Table 2-5: Example of Cumulative Permissions (continued)
RESOURCE OR FEATURE
SUNNYVALE USER GROUP
PERMISSION
DALLAS USER GROUP
PERMISSION
56
Predefined User Groups
SA includes the following predefined user groups:
Basic Users
Intermediate Users
Advanced Users
SA System Administrators
The Basic, Intermediate, and Advanced Users groups define roles for system
administrators with increasing levels of responsibility. These system administrators
perform operational tasks on managed servers and set up elements of SA such as
patches and packages. The users in the SA System Administrators group manage SA
itself, performing tasks such as running the SA system diagnosis and multimaster tools.
Use of the predefined user groups is optional. You can change the permissions of the
predefined user groups; you can also delete these groups. Changes or deletions of the
predefined user groups are not affected by SA upgrades.
Super Administrators
A super administrator is an SA user who manages SAs security structure. Super
administrators create users and groups, specify permissions for groups, and assign users
to groups. Super administrators can also manage customers and facilities, as well as set
folder permissions. To perform most of the tasks described in this chapter, you must log in
to the SAS Web Client as a user with super administrator privileges.
The HP BSA Installer creates a single default user: the super administrator named admin.
The password for admin is specified during the installation and should be changed
immediately afterwards.
As a best practice, you should not add the admin user to other user groups.
57
Customer Administrators
The super administrator delegates the management of specific user groups to a customer
administrator. Like a super administrator, a customer administrator can assign users and
permissions to user groups. However, a customer administrator cannot create users. The
user groups that a customer administrator can manage depend on the relationships
between several objects, including customer permissions and customer groups.
For example, suppose that the user Joe Smith is a customer administrator who can
manage the user group named Sunnyvale Admins. The users who belong to the
Sunnyvale Admins group are responsible for managing servers owned by the Widget, Inc.
customer. Figure 2-1 shows the relationships required between various objects. In order
for Joe Smith to manage the Sunnyvale Admins user group, the following relationships
must exist:
The R & W customer permission Widget, Inc. is assigned to the Sunnyvale Admins.
The Widget, Inc. customer belongs to the customer group named Widget Admins.
The user Joe Smith is assigned to the Widget Admins customer group.
For instructions on setting up the relationships shown in Figure 2-1, see Delegating User
Group Management to a Customer Administrator on page 74.
Figure 2-1: Relationships Required for a Customer Administrator
User:
Joe Smith
User Group:
Sunnyvale Admins
Customer
Permission:
R & W
Customer:
Widget, Inc.
Customer Group:
Widgets, Inc. Admins
can manage
is assigned to
is assigned to
belongs to
is a resource
permission of
58
Process Overview for Security Administration
The person responsible for the security of SA creates and maintains users, groups, and
permissions. This person must be able to log in to the SAS Web Client as a user who is a
super administrator. The default super administrator is the admin user.
The following steps provide an overview of security administration for SA:
1 Identify the people in your organization who will manage SA security.
2 For each user identified in the preceding step, create a super administrator.
For instructions, see Creating a Super Administrator on page 73.
3 Note the facility that the managed servers belong to.
A facility is an SA object that represents a data center or physical location.
Depending on your organization, you may want to name the facility after the city,
building, or room where the servers reside. The person who installs SA specifies a
default facility for the core.
4 Associate customers with managed servers.
In SA, a customer is an object that represents a business organization, such as a
division or a corporation. Typically, a server is associated with a customer because it
runs applications for that customer.
5 (Optional) Create device groups and assign servers to the groups.
For more information, see the Device Groups section of the SA Users Guide:
Server Automation.
6 Plan your user groups.
Decide which SA tasks specific groups of users will perform and on which servers.
Usually, a user group represents a role or a job category. Examples of user groups
are: Unix System Admins, Windows Admins, DBAs, Policy Setters, Patch Admins, and
so forth.
7 Create the user groups.
For instructions, see Creating a User Group on page 64.
8 Set the resource permissions on the user groups.
These permissions specify read and write access to servers associated with facilities,
customers, and device groups. Resource permissions control which servers the
members of a user group can access.
59
For instructions, see Setting the Customer Permissions on page 64 and the
adjacent sections.
9 (Optional) Delegate the management of user groups to other users.
For instructions, see Delegating User Group Management to a Customer
Administrator on page 74.
10 Set the feature (action) permissions on the user groups.
To determine which feature permissions are required to perform a specific task, see
the tables in Permissions Required for the SA Client on page 231. For example, if
you have a user group named Policy Setters, see Software Management
Permissions Required for User Actions on page 251.
For instructions, see Setting the SA Client Features Permissions on page 68 and
the adjacent sections.
11 Set the OGFS permissions on the user groups.
OGFS permissions are required for some actions. The OGFS permissions are
included in the tables in Permissions Required for the SA Client on page 231.
For instructions, see Adding OGFS Permissions on page 70.
12 Create the folder hierarchy in the Library of the SA Client.
For information on folders, see the Software Management Setup chapter of the
SA Policy Setters Guide.
13 Set the folder permissions.
Again, see Permissions Required for the SA Client on page 231. In general, you
need read permission on a folder to use its contents in an operation, write permission
to create folder contents, and execute permission to run scripts that reside in a folder.
For instructions, see Setting Folder Permissions on page 69.
14 (Optional) Delegate the management of folder permissions to other user groups,
individual users, or customer administrators.
For instructions, see Setting Folder Permissions on page 69.
15 Create new users in SA or import existing users from an external LDAP.
For instructions, see Creating a User on page 61 or External LDAP Directory
Service with SA on page 78.
60
16 Assign users to the appropriate groups.
For instructions, see Assigning a User to a Group on page 64.
Private User Group
When an SA administrator creates a new user, SA automatically creates a private user
group for the new user using the users username and assigns the new user to the private
user group.
A private user group can contain only one SA user and every SA user can belong to only
one private user group. The SA administrator can then assign feature and resource
permissions to the private user group. The permissions that you specify for a private user
group determines what the user can do with SA. Feature permissions specify what
actions the user can perform; resource permissions indicate which objects (typically
servers) the user can perform the actions on. OGFS permissions cannot be assigned to a
private group.
For example, when an SA Administrator creates a new user with username John, a private
user group John is also created for the user John and a default folder called John is
created in the Home directory. The SA Administrator can then assign feature and resource
permissions to the private user group John.
An SA user can be a member of multiple user groups and belong to the users private
group. But then the derived permissions of the private user group is not a cross-product of
the resource and feature permissions of all groups that the user belongs to.
When an user is deleted, SA automatically deletes the corresponding private user group
and the default folder for that user is moved the location: /Home/deleted_users.
To access a private user group see Setting Private User Group Permissions on page 72.
After accessing a private user group, the SA administrator may assign the following
permissions:
1 Set the resource permissions on the private user group.
These permissions specify read and write access to servers associated with facilities,
customers, and device groups. Resource permissions control which servers the user
can access.
For instructions, See Setting the Customer Permissions on page 64. and See
Setting the Facility Permissions on page 65.
2 Set the feature (action) permissions on the private user group.
61
To determine which feature permissions are required to perform a specific task, See
Setting the SA Client Features Permissions on page 68. and See Setting the
General Feature Permissions on page 67.
3 Set the folder permissions on the default home folder of the user. When an SA
Administrator creates a new user, a private user group is also created for the user in
the following location: /Home/user_name. By default, the user has Read and Write
permissions to this folder and the SA administrator has List and Edit permissions to
this folder.
For instructions, See Setting Folder Permissions on page 69.
Managing Users and User Groups
To manage users, you must log in to the SAS Web Client as a super administrator
(admin).
Creating a User
You can create SA users with the SAS Web Client, or you can import users from an
external LDAP directory. See External LDAP Directory Service with SA on page 78 in this
chapter for more information.
To create a user with the SAS Web Client, perform the following steps:
1 From the navigation panel, select Administration Users & Groups.
The Users tab appears. (See Figure 2-2.)
Figure 2-2: Users Tab
2 Click New User.
62
3 On the Profile Editor page, fill in the required fields, which are labelled in bold font.
The Login User Name may be different than the first, last, and full names. The Login
User Name is not case sensitive and cannot be changed after the user is created.
4 (Optional) If both SA and HP Network Automation (NA) are installed, and you want
the user to authenticate with NA, then select NA for the Credential Store.
The Credential Store field can be either SA (the default), Network Automation (NA),
External, or RSA 2-factor. The value NA specifies that the user was configured on a
TACACS+/RADIUS server connected to NA, not a native NA user. The value External
indicates that the user was imported from an external LDAP directory. The value RSA
2-factor specifies that the user was configured on an RSA server connected to SA.
You can change the user password in the SAS Web Client only if the Credential Store
is SA.
5 (Optional) Assign the user to one or more of the groups listed at the bottom of the
page.
You can also assign the user to a group at a later time. If a user does not belong to a
group, the user cannot view servers or perform tasks with the SA Client.
6 Click Save to create the user.
Editing User Profile Information
Each SA user can edit the profile information for his or her own login user. If you log in as
a super administrator (admin), you may view or edit the information of any SA user. To do
so, perform the following steps:
2 On the Users tab, select an entry in the User Name column.
3 In the Profile Editor, modify the information as appropriate.
4 Click Save.
Viewing a Users Permissions
You do not assign permissions directly to a user. Instead, you set the permissions on a
user group and then assign a user to a group. To view the permissions of a user, perform
the following steps:
63
2 On the Users tab, select an entry in the User Name column.
3 If the user belongs to more than one group, on the Edit User page, select a user
group in the View as field. The permissions displayed depend on the user group
you select.
4 View the permissions on the Resource Privileges and Action Privileges tabs.
Deleting a User
When you delete a user, the users login and logout history is permanently stored, and the
user is unassigned from user groups. After a user is deleted, you can create another user
with the same name.
To delete an SA user, perform the following steps:
2 On the Users tab, select the check box next to the user to be deleted.
3 Click Delete.
Suspending a User
A suspended user cannot log in to SA, but has not been deleted from the Model
Repository. A suspended user is indicated by the lock icon on the Users tab of the SAS
Web Client. A user can be suspended in the following ways:
Login Failure: If you specify Login Failure on the Security Settings tab, and someone
tries to log in with the wrong password a specified number of times, the user account is
suspended. For instructions on accessing the Security Settings tab, see the first two
steps of Resetting Initial Passwords on page 76.
Account Inactivity: If you specify Account Inactivity on the Security Settings tab, and
the user has not logged on for the specified number of days, the user account is
suspended.
Expired Password: A user can be suspended if the password has expired and the
expiration count is full.
Suspend: To suspend the users account immediately, go to the Users tab, select the
users checkbox, and click Suspend.
To activate a suspended user, go to the Users tab, select the users checkbox, and click
Activate.
64
Creating a User Group
To create an SA user group, perform the following steps:
2 On the Groups tab, click New Group.
3 On the New Group page, enter a role in the Group name field.
4 At this point, you can select the check boxes under the Feature column to assign
permissions to the group. The New Group page, however, does not display all
available permissions.
5 Click Save.
Assigning a User to a Group
You should assign each SA user to a group reflecting the users role in your organization.
To assign an SA user to a user group, perform the following steps:
2 On the Group tab, select a user group from the Name column.
3 On the Users tab, in the Unassigned Members box, select the user name.
4 Click the right arrow.
5 To unassign a user, click the name in the Assigned Members box and click the left
arrow.
6 Click Save.
Setting Permissions on User Groups
To perform the tasks in this section, you must log in to the SAS Web Client as a super or
customer administrator. (The default super administrator is admin.)
If you change permissions while a user is logged on to the SAS Web Client or SA Client,
the user must log out and log in again for the changes to take effect.
Setting the Customer Permissions
In SA, you can associate a customer with a number of resources, including servers,
folders, application configurations, and OS installation profiles. By setting the customer
permission, you control the access that the users of a group have to the resources
65
associated with the customer. For example, if you want the users of a group to be able to
view (but not modify) the servers associated with the Widget Inc. customer, set the
permission to Read.
The customer permissions also control access to the customer object itself. For example,
to add a custom attribute to a customer, a user must belong to a group that has Read &
Write permission to the specific customer, as well as permission for the Customers
feature.
To control the access to the resources associated with a customer, perform the following
steps:
2 On the Groups tab, select an entry in the Name column. Another set of tabs appears,
including the Customers tab.
3 On the Customers tab, for each customer listed, select Read, Read & Write, or None.
4 Click Save.
Setting the Facility Permissions
In SA, a facility can be associated with resources such as servers and IP ranges. To
modify a server of a particular facility, a user must belong to a group that has Read &
Write permission for the facility.
The facility permissions also control access to the facility object itself. For example, to
modify a property of a facility, a user must belong to a group that has Read & Write
permission to the facility, as well as permission for the Facilities feature.
To control the access to the resources associated with a facility, perform the following
steps:
including the Facilities tab.
3 On the Facilities tab, select Read, Read & Write, or None.
4 Click Save.
66
Setting the Device Group Permissions
To control access to the servers in a public device group, select a permission on the
Device Groups tab. (You cannot control access to a private device group, which is visible
only to the user who created it.)
If the Device Groups tab lists no device groups, then access to servers is not controlled
by membership in device groups; however, access to servers is still controlled by their
association with customers and facilities. If the Device Groups tab lists at least one device
group, then access is denied to unlisted device groups (the equivalent of a None
permission).
Access control based on device groups is optional. By default, membership in a device
group does not restrict access. In contrast, for servers associated with customers or
facilities, the default permission is None, which prohibits access.
You can combine customer, facility, and device group permissions to implement security
policies. For example, you can restrict access to servers that are associated with the
Acme Corp. customer, reside in the Fresno facility, and belong to a device group that
contains only Windows servers.
A device group can contain other device groups. However, permissions are not inherited
by the contained (children) device groups.
The permissions on the Device Groups tab control access to servers that belong to
device groups. However, these permissions do not control the management of the device
groups. To create, modify, or delete device groups, a user must belong to a user group
that has the Manage Public Device Groups and the Model Public Device Groups check
boxes selected on the Other tab. Also, the Managed Servers and Groups check box must
be selected on the Features tab.
To control access to servers that belong to a device group, perform the following steps:
including the Device Groups tab.
3 On the Device Groups tab, note the check box below Assign. If this check box is
selected, then access to managed servers is not based on device groups.
4 Deselect the check box below Assign.
5 Click Assign.
67
The Select Groups page appears. (See Figure 2-3.)
Figure 2-3: Select Groups Page
6 On the Select Groups page, use the Browse or Search tab to locate the device
groups.
7 On the Browser or Search tab, click on the device group name and then click Select.
8 On the Device Groups tab, for each device group listed, select the check box and
click the button for the appropriate access.
To allow viewing (but not modification) of the servers in a device group, select the
Read permission. To allow both viewing and modification, select the Read & Write
permission.
9 Click Save.
Setting the General Feature Permissions
The Features tab of the SAS Web Client includes many tasks, including managing the
servers and running the wizards. If the check box for a feature is unselected, then the SAS
Web Client does not display the related links in the navigation panel.
To allow the users in a group the ability to view and execute a task on the Features tab,
perform the following:
68
2 On the Group tab, select a user group from the Name column.
3 Another set of tabs appears, including the Features tab. (See Figure 2-4.)
Figure 2-4: Features Tab
4 On the Features tab, select the check box for each feature that should be enabled for
the user group. To prevent (and hide) a feature, deselect the check box.
5 Click Save.
Setting the SA Client Features Permissions
The Client Features tab of the SAS Web Client lists permissions for the actions performed
with the SA Client. These actions are for features such as Application Configuration and
Software Policy Management.
To set these permissions for the SA Client perform the following steps:
2 On the Group tab, select a user group from the Name column. Another set of tabs
appears, including the Client Features tab.
3 On the Client Features tab, select the appropriate permission buttons.
4 Click Save.
69
Setting the Other Features Permissions
The Other tab of the SAS Web Client contains the following permissions:
General Permissions: Allows users in a user group to edit shared scripts or run my
scripts as root. The Features tab also has script-related permissions: Scripts, and
Wizard: Run Scripts.
Server and Device Group Permissions: Enables users in a user group to perform
particular tasks on managed servers. The Allow Run Refresh Jobs permission lets
users specify a job to update the servers list. The Manage Public Servers Group
permission enables users to create device groups, modify the group properties, and
change the group membership (through rule changes, or adding and deleting servers).
All users may view all public device groups. The Model Public Servers Group
permission lets users add custom attributes. (These permissions apply to public, not
private device groups. Only the user who creates a private device group can view or
modify it.) The Features tab also has a permission related to managing servers:
Managed Servers and Group.
Job Permissions: Allows users in a user group to view and schedule jobs, which
include operations such as Audit Servers, Snapshots, Push Configurations, and Audit
Configurations. The View All Jobs permission lets users view the details and schedules
of jobs created by all users. The Edit All Jobs permission enables users to view or
modify the schedules of jobs created by all users and to view the job details of all
users. Without these permissions, users can view and schedule only their own jobs.
To set the permissions on the Other tab, perform the following steps:
appears, including the Other tab.
3 On the Other tab, select the check boxes to assign permissions to this user group.
4 Click Save.
Setting Folder Permissions
To perform this task, your user or user group must have the Edit Folder Permission on the
target folder. When you create a folder, it has the same permissions and customer as its
parent folder. If you are changing the permissions of a folder that has children, you are
prompted to apply the changes to the children.
70
To set the permissions of a folder, perform the following steps:
1 In the SA Client, navigate to the folder.
2 From the Actions menu, select Folder Properties.
3 In the Folder Properties window, select the Permissions tab.
4 On the Permissions tab, click Add to allow certain user groups to access the folder.
5 For each user group and user displayed on the Permissions tab, select a check box
such as Write Objects Within Folder. To delegate the setting of permissions for this
folder, select Edit Folder Permissions.
Adding OGFS Permissions
You can add OGFS permissions with the SAS Web Client or with the aaa command-line
utility. For syntax and examples of the aaa utility, see the SA Users Guide: Server
Automation.
To add an OGFS permission in the SAS Web Client, perform the following steps:
appears, including the OGFS Permissions tab.
71
3 On the OGFS Permissions tab click Add Permission. The Add OGFS Permissions
window appears. (See Figure 2-5.)
Figure 2-5: Add OGFS Permissions Window
4 In the Add OGFS Permissions window, select a feature.
For descriptions of these features, see Table 2-3 on page 52.
5 If you selected a feature other than Launch Global Shell, select the managed servers
this permission applies to.
You can select servers associated with a customer, facility, or device group. If you
want to select servers associated with multiple resources (for example, two device
groups) then you must add a separate OGFS permission for each resource.
6 For Login Name, select the user account (login) on the managed servers.
The operation indicated by the Feature field will run on the managed server as the
user indicated by Login Name.
7 Click Grant.
72
Setting Private User Group Permissions
The SA Administrator can set the feature, resource, or folder permissions on a private user
group.
Perform the following steps to set permissions on a private user group:
1 From the navigation panel, select Administration Users & Groups. The Users &
Groups: View Users window appears.
2 Select the user from the User Name column. The Users & Groups: Edit User window
appears.
3 From the View As drop-down menu, select the user name and then click Edit.
4 In the Users & Groups: Edit Group - <user name> window select Features,
Customers, or Client features tab to assign the permissions.
5 Refer to the following sections to assign the permissions:
Setting the Customer Permissions on page 64
Setting the Facility Permissions on page 65
Setting the Device Group Permissions on page 66
Setting the General Feature Permissions on page 67
Setting the SA Client Features Permissions on page 68
Setting Folder Permissions on page 69
Managing Super and Customer Administrators
These users are the security administrators who assign permissions to user groups. To
manage super and customer administrators, you must log in to the SA Client as a super
administrator. When SA is first installed, the default super administrator is the admin user.
Viewing Super and Customer Administrators
To see which users are super or customer administrators, perform the following steps:
73
2 Select the Administrators tab. (See Figure 2-6.)
Figure 2-6: Administrators Tab
3 On the Administrators tab, note the Type field, which identifies the user as either a
super or customer administrator. The name of the customer group is in parentheses.
Creating a Super Administrator
To create a super administrator, perform the following steps:
1 Create a new user who will be the super administrator. For instructions, see Creating
a User on page 61.
3 Select the Administrators tab.
4 Click New Super Administrator.
5 On the Add Super Administrators page, select one or more user names.
6 Click Save.
Deleting a Super Administrator
To delete a super administrator, perform the following steps:
2 Select the Administrators tab.
3 Select the check box for the user.
4 Click Revoke. This action revokes super administrator privileges from the user, but
does not delete the user from SA.
5 To delete the user from SA, follow the instructions in Deleting a User on page 63.
74
Delegating User Group Management to a Customer Administrator
A customer administrator is a user who can manage a subset of user groups. The subset
is determined by customer permissions and customer groups. For a full explanation of the
relationships between these objects, see Customer Administrators on page 57.
To delegate the management of a user group, perform the following steps:
1 Identify the user who will be responsible for user group management.
This user will be a customer administrator. If the user does not exist, follow the
instructions in Creating a User on page 61.
2 Decide which user group will be managed by the user identified in the preceding
step.
For instructions on viewing the user group, see Creating a User Group on page 64.
3 Note the customer permissions of the user group.
For instructions on viewing these permissions, see Setting the Customer
Permissions on page 64.
5 Select the Customer Groups tab.
6 Click New Group.
7 Enter the customer group name. (See Figure 2-7.)
Figure 2-7: New Customer Group Window
75
8 Click Save.
9 Add the customers you noted in step 3 to the customer group.
10 Add the user you identified in step 1 to the customer group.
The user of step 1 is now the customer administrator who can manage the user
group of step 2.
11 (Optional) Verify that the user is listed as a customer administrator by following the
instructions in Viewing Super and Customer Administrators on page 72.
Managing Passwords and Login Settings
An SA user can change his or her own password on the Profile page of the SAS Web
Client. A super administrator can change the password of other users, as well as perform
other password management tasks described in the following sections.
Changing Passwords
Only a super administrator (admin) can change the passwords of other SA users. If the
user name has been imported from an external LDAP directory, then the password cannot
be changed with the SAS Web Client.
To change the password of an SA user in the SAS Web Client, perform the following
steps:
2 On the User tab, select a user name.
3 On the User Identification tab, click Change Password.
4 Enter the new password, confirm it, and click Save.
Specifying Password Character Requirements
To specify character requirements for SA users, perform the following steps:
1 From the navigation panel, select Administration System Configuration. The Select
a Product page appears.
2 Under Select a Product, click SAS Web Client. The Modify Configuration Parameters
page appears.
76
3 On the Modify Configuration Parameters page, set the
owm.features.MiniPasswordPolicy.allow parameter to true.
This parameter must be true for the other password parameters on this page to take
effect. To disable the other password parameters, set
owm.features.MiniPasswordPolicy.allow to false.
4 Set the values for the password parameters listed inTable 2-7.
5 Click Save.
6 To apply these parameter changes to other cores in a multimaster mesh, you must
restart the other cores.
Resetting Initial Passwords
To require users to reset their passwords the first time they log in to SA, perform the
following steps:
2 Select the Security Settings tab.
3 Select Reset.
Setting Password Expiration
To require SA users to change passwords after a certain number of days, perform the
following steps:
Table 2-7: Password Requirements on the Modify Configuration Parameters Page
PASSWORD
REQUIREMENT
PARAMETER
ALLOWED
VALUES
DEFAULT
VALUE
maximum number of
repeating, consecutive
characters
owm.pwpolicy.maxRepeats must be greater
than 0
2
minimum number of
characters
owm.pwpolicy.minChars positive integer 6
minimum number of non-
alphabetic characters
owm.pwpolicy.
minNonAlphaChars
must be less than
value of
owm.pwpolicy.min
Chars
0
77
3 In the checkboxes next to the Expiration label, select the number of days for the
password expiration and the number of grace logins.
A grace login allows the user to log in with the old password. Typically, the grace
login is set to 1, enabling the user to log in to the SAS Web Client, access the My
Profile page, and change the password.
4 To specify the number of previous passwords allowed by users, select Retention and
enter a value.
This setting prohibits users from re-using the same set of passwords. For example, if
the value is 10, the users are not be allowed to re-use their previous 10 passwords.
For information on Login Failure and Account Inactivity, see Suspending a User on page
63.
Specifying Session Timeout
You can specify the timeout interval (in minutes) of inactive SA Client sessions. When a
session times out, the user must re-enter the password or log out.
To specify the timeout for SA Client sessions, perform the following steps:
1 From the navigation panel of the SAS Web Client, select Administration Users &
Groups.
3 Select Session Inactivity and specify the number of minutes.
The Session Inactivity parameter does not affect SAS Web Client sessions. The default
session timeout for the SAS Web Client is 60 minutes. To change the default, you edit a
configuration file and restart the OCC core component. For instructions on editing the
configuration file, contact your HP support representative.
Setting the User Agreement
If you enable the user agreement, when users log in with the SA Client or the SAS Web
Client, a dialog appears with a specified message. To continue the log in procedure, the
users must click Agree. (In some products, a user agreement dialog is called a login
approval screen.)
78
To set the user agreement, perform the following steps:
3 In the User Agreement section, select Display and enter text in the Message field.
Setting the Banner
If you enable the banner, after the users log in, the specified text appears in a banner at
the top of the SA Client and the SAS Web Client. To set the banner, perform the following
steps:
3 In the Banner Settings section, select Display
4 In the Message field, enter the text to be displayed in the banner.
5 To set the background color of the banner, select an item from Color Code or enter a
hex value in the adjacent field.
External LDAP Directory Service with SA
You can configure SA to use an external LDAP directory service for user authentication.
With external authentication, you do not have to maintain separate user names and
passwords for SA. When users log in to the SAS Web Client, they enter their LDAP user
names and passwords.
Imported Users
With the SAS Web Client, you search for users in the external LDAP and then you import
selected users into SA. You can limit the search results by specifying a filter. The import
process fetches the following user attributes from the LDAP:
firstName
lastName
fullName
emailAddress
phoneNumber
street
city
state
country
79
After the import process, you may edit the preceeding list of attributes within the SAS Web
Client. However, you cannot change the user login name or password. Importing a user is
a one-time, one-way process. Changes to the user attributes you make using the SAS
Web Client are not propagated back to the external LDAP directory server, and vice versa.
Imported users are managed in the same way as users created by the SAS Web Client.
For example, you use the SAS Web Client to assign imported users to user groups and to
delete imported users from SA. If you delete an imported user with the SAS Web Client,
the user is not deleted from the external LDAP directory.
If you use external authentication, you can still create separate users with the SAS Web
Client. However, this practice is not recommended.
To see which users have been imported, view the Users tab of the SAS Web Client and
note the users with External in the Credential Store column.
SSL and External Authentication
Although SSL is not required for external authentication, it is strongly recommended. The
certificate files needed for LDAP over SSL must be in Privacy Enhanced Mail (PEM)
format. Depending on the LDAP server, you may need to convert the server's CA
certificate to PEM format.
Supported External LDAP Directory Servers
The following directory server products may be used with SA:
Microsoft Active Directory (Windows 2000 or Windows 2003)
Novell eDirectory 8.7
SunDS 5.2
Using an LDAP Directory Server with SA
To use an LDAP directory server with SA, perform the following basic steps:
1 Add the aaa.ldap entries to the twistOverrides.conf file with a text editor.
See Modifying the Web Services Data Access Engine Configuration File on
page 80.
2 Get the SSL server certificate from the LDAP directory server. See Importing a
Server Certificate from the LDAP into SA on page 84. (Use of SSL is not required,
but strongly recommended.)
80
3 Edit the loginModule.conf file with a text editor. See Configuring the JAAS Login
Module (loginModule.conf) on page 85.
4 Restart the Web Services Data Access Engine:
/etc/init.d/opsware-sas restart twist
5 Use the SAS Web Client to import users from the LDAP directory server into SA. See
Importing External LDAP Users on page 85.
In a mulitmaster mesh, you must perform steps 1 - 4 on each Web Services Data Access
Engine.
Modifying the Web Services Data Access Engine Configuration File
To modify twistOverrides.conf, perform the following steps:
1 Log in as root to the system running the Web Services Data Access Engine, an SA
Core Component.
2 In a text editor, open this file:
/etc/opt/opsware/twist/twistOverrides.conf
3 In the text editor, add the necessary properties (listed in Table 2-8) to the
twistOverrides.conf file. Although not required, the SSL properties are
recommended. For examples of the lines required for the twistOverrides.conf
file see, the sections that follow Table 2-8.
4 Save the twistOverrides.conf file and exit the text editor.
5 Make sure that the Unix twist user has write access to the
twistOverrides.conf file.
Table 2-8: Properties in twistOverrides.conf for an External LDAP
PROPERTY DESCRIPTION
aaa.ldap.hostname The host name of the system running the
LDAP directory server.
aaa.ldap.port The port number of the LDAP directory
server.
aaa.ldap.search.binddn The BIND DN (Distinguished Name) for
LDAP is required by the search of the
import user operation. A blank value
denotes an anonymous BIND.
81
aaa.ldap.search.pw The BIND password for LDAP is required
by the search for the import user
operation. This value is encrypted when
the Web Services Data Access Engine is
restarted. A blank value denotes an
anonymous BIND.
aaa.ldap.search.filter.template The search filter template is used, with
optional filter substitution, as the filter in
the LDAP search for the user import. Any
dollar sign ($) character in the template
will be replaced by the filter string
specified in the Import Users page of the
SAS Web Client. (The default value is an
asterisk (*) which matches all entries.)
aaa.ldap.search.base.template The configurable template allows support
for a range of DIT configurations and
schema in the LDAP service. The search
base template string is used for the
search base in the LDAP search
operations for the user import.
aaa.ldap.search.naming.attribute The naming attribute allows support for a
range of schema in the LDAP services.
Some use uid, others use cn, and so on.
The value of this attribute is used for the
internal user ID in SA.
aaa.ldap.search.naming.display.
name
The naming attribute allows support for a
range of schema in the LDAP services.
Some use cn, others use displayName,
and so on. The value of this attribute is
used for the Full Name of SA user.
aaa.ldap.ssl SSL: A value of true enables SSL.
aaa.ldap.secureport SSL: The secure port of the LDAP
directory server.
Table 2-8: Properties in twistOverrides.conf for an External LDAP (continued)
82
Example: twistOverrides.conf for Microsoft Active Directory Without SSL
aaa.ldap.search.binddn=cn=Administrator,cn=users,dc=example,dc=
com
aaa.ldap.search.pw=secret
aaa.ldap.hostname=myservername.internal.example.com
aaa.ldap.port=389
aaa.ldap.search.filter.template=(&(objectclass=user)(cn=$))
aaa.ldap.search.base.template=cn=users,dc=example,dc=com
aaa.ldap.search.naming.attribute=samaccountname
aaa.ldap.search.naming.display.name=cn
Example: twistOverrides.conf for Microsoft Active Directory With SSL
aaa.ldap.search.binddn=cn=Administrator,cn=users,dc=example,dc=
com
aaa.ldap.secureport=636
aaa.ldap.ssl=true
aaa.ldap.servercert.ca.fname=/var/opt/opsware/crypto/twist/
cert.pem
aaa.ldap.search.filter.template=(&(objectclass=user)(cn=$))
aaa.ldap.search.base.template=cn=users,dc=example,dc=com
aaa.ldap.search.naming.attribute=samaccountname
aaa.ldap.usestarttls SSL: A value of true enables Start
TLS.
aaa.ldap.servercert.ca.fname SSL: The fully qualified file name of the
server CA certificate.
aaa.ldap.clientcert SSL: A value of true enables client
certificate use.
aaa.ldap.clientcert.fname SSL: The fully qualified file name of the
client certificate.
aaa.ldap.clientcert.ca.fname SSL: The fully qualified file name of the
client CA certificate.
Table 2-8: Properties in twistOverrides.conf for an External LDAP (continued)
83
Example: twistOverrides.conf for Novell eDirectory Without SSL
aaa.ldap.search.binddn=cn=admin,o=example
aaa.ldap.port=389
aaa.ldap.search.filter.template=(&(objectclass=inetorgperson)(u
id=$))
aaa.ldap.search.base.template=o=example
aaa.ldap.search.naming.attribute=uid
Example: twistOverrides.conf for Novell eDirectory With SSL
aaa.ldap.search.binddn=cn=admin,o=example
aaa.ldap.ssl=true
ldapcert.pem
id=$))
aaa.ldap.search.base.template=o=example
Example: twistOverrides.conf for SunDS Without SSL
aaa.ldap.search.binddn=cn=Directory Manager
aaa.ldap.port=389
id=$))
aaa.ldap.search.base.template=ou=people,dc=example,dc=com
Example: twistOverrides.conf for SunDS With SSL
aaa.ldap.search.binddn=cn=Directory Manager
aaa.ldap.ssl=true
ldapcert.pem
84
id=$))
aaa.ldap.search.base.template=ou=people,dc=example,dc=com
Importing a Server Certificate from the LDAP into SA
For SSL, the necessary certificates must be extracted from the LDAP and copied over
to SA.
To import a server certificate from the LDAP into SA, perform the following steps:
1 Extract the server certificate from the external LDAP. For instructions, see the
following sections.
2 Convert the extracted certificate to PEM format.
Certificates created on Windows systems are in Distinguished Encoding Rules (DER)
format. The following example converts a certificate from DER to PEM format with the
openssl utility:
OpenSSL> x509 -inform DER -outform PEM -in mycert.der \
-out mycert.pem
3 Copy the server certificate to the location specified by the Web Services Data
Access Engine configuration file (twistOverrides.conf). For example, the
twistOverrides.conf file could have the following line:
ldapcert.pem
Extracting the Server Certificate from Microsoft Active Directory
To extract the server certificate, perform the following steps:
1 Run either the Certificates MMC snap-in console or the Certificate Services web
interface.
2 Export the Root CA cert from the Windows CA into DER format.
Extracting the Server Certificate from Novell eDirectory
To extract the server certificate, perform the following steps:
1 Find out the name of the local CA entry. (Example: CN=CORP-TREE
CA.CN=Security)
2 Open the eDirectory Administration utility and click Modify Object.
3 Enter the entry name (CN=CORP-TREE CA.CN=Security).
85
4 Select the Certificates tab.
5 Click Self Signed Certificate.
6 Click Export.
7 In the dialog, click No for exporting the private key and then click Next.
8 Select the appropriate format (usually DER).
9 Click Save the exported certificate to a file.
Extracting the Server Certificate from SunDS
Typically, instead of exporting a server CA certificate from SunDS, you obtain the
certificate that was imported into SunDS.
Configuring the JAAS Login Module (loginModule.conf)
To configure the JAAS login module, perform the following steps:
1 Log in as root to the system running the Web Services Data Access Engine, an SA
Core Component.
2 In a text editor, open this file:
/etc/opt/opsware/twist/loginModule.conf
3 In the text editor, modify the loginModule.conf file so that it contains the
following lines:
/** Login configuration for JAAS modules **/

TruthLoginModule {
com.opsware.login.TruthLoginModule sufficient debug=true;
com.opsware.login.LdapLoginModule sufficient debug=true;
};
4 Save the loginModule.conf file and exit the text editor.
Importing External LDAP Users
Before importing external LDAP users, you must complete the prerequisite steps. See
Using an LDAP Directory Server with SA on page 79 in this chapter for more information.
After you import the users, the users may log in to the SAS Web Client with their LDAP
user names and passwords.
86
To import external users, perform the following steps:
1 In the SAS Web Client, from the navigation panel, select Administration Users &
Groups.
2 Select the Users tab. The page lists the existing SA users.
3 On the Users tab, click Import External Users.
The page displays the users in the LDAP that match the search filter. The default filter
is an asterisk (*), indicating that all users are selected. If a check box does not
appear to the left of the user name, then the user already exists in SA and cannot be
imported.
If SA cannot connect to the LDAP, check for error messages in the following file:
/var/log/opsware/twist/stdout.log
4 To change the search filter, enter a value in the field to the left of Change Filter. For
example, to fetch only those user names beginning with the letter A, you enter A* in
the field.
5 If you modified the search filter in the preceding step, click Change Filter. The page
displays the users in the LDAP that match the search filter.
6 You can assign users to the user groups listed at the bottom of the page or you can
assign them later.
7 Select the check boxes for the users you want to import. To import all users
displayed, select the top check box.
8 On the Import Users page, click Import.
Code Deployment Permissions
Permissions to perform CDR operations are based on user membership in user groups
predefined specifically for CDR. Users must also have the necessary permissions for the
customer associated with the servers. Except for the Super User group, CDR operations
are customer specific. A member of the Super User group can perform CDR operations
on the servers of any customer.
The SAS Web Client might still show the legacy term CDS. However, all documentation
references use SA Code Deployment & Rollback term CDR.
87
The SAS Web Client includes predefined user groups that have specific permissions to
perform CDR operations. SA administrators create and add users to these user groups to
grant them permissions to perform specific CDR operations, based on their role in an
organization. When logged on to the SAS Web Client, users see only the services,
synchronizations, and sequences that they have authorization to perform because of their
user group membership. Users are assigned to these groups as part of the Create User
process.
See Code Deployment User Groups on page 312 in Appendix for more information.
See the SA Users Guide: Server Automation for information about the process to deploy
code and content to managed servers.
When a user requests a service operation, synchronization, or sequence, an e-mail
notification is sent to the individuals assigned to actually perform the requested service
operation or synchronization.
Adding Members to a Code Deployment User Group
Permissions to perform specific Code Deployment operations are granted based on a
user's membership in specific Code Deployment user groups.
1 From the navigation panel, select Administration Users & Groups. The Manage
Users: View Users page appears.
2 Select the Code Deployment tab.
3 Select the code deployment user group that you want to modify by clicking the
hyperlinked user group name.
The Users and Groups: Edit Code Deployment Group - [group name] page appears.
4 From the drop-down list, choose the customer whose group membership you want
to modify.
Code Deployment permission is assigned based on the associated SA customer. You
cannot select Customer Independent, Not assigned, and SA customers and modify their
group membership.
88
5 To add a user to the group, select the name in the left box, and then click the right
arrow.
6 Click Save when you finish moving the user names to the box on the right.
A confirmation page appears.
7 Click Continue.
The Users & Groups: View Code Deployment Group page appears. You can continue
modifying Code Deployment Groups, or you can select another function.
User and Security Reports
The Reporting feature in SA allows you to generate reports that provide a summary of the
Client and Feature permissions across servers. These reports are only available when you
login to the SA Client as an Administrator.
SA allows you to run the following User and Security Reports:
Client and Feature Permissions
Customer/Facility Permissions and Device Group Permission Overrides
User Group Membership
User Login
Administrator Actions
User and Authorizations, By User Group
User and Authorizations, By Individual User Group
Administrator Customer Groups
Server Permissions, by User
Server Permissions, by Server
OGFS Permissions, by User
OGFS Permissions, by Server
89
Chapter 3: Multimaster Mesh Administration
This section documents how to administer and maintain an existing Multimaster Mesh, it
does not document how to configure SA for a Multimaster Mesh. For more information
about Multimaster architecture and planning for and installing a Multimaster Mesh, see
the SA Planning and Installation Guide or consult your SA Support Representative.
Multimaster Facilities Administration
In the SAS Web Client, the term Facility refers to the collection of servers that a single
SA Core or Satellite manages. For more information about what Facilities are and how
they fit into Multimaster architecture, see the SA Planning and Installation Guide.
After a Facility has been created, you can modify certain information for the Facility from
the SAS Web Client. A Facility is uniquely identified by a Facility name and a Facility ID.
You can modify the Facility name and custom attributes used to provide parameters to SA
to, for example, customize displays or provide settings to use during installation or
configuration of packaged software in the operational environment. For more information
about custom attributes, see the SA Users Guide: Server Automation.
Multimaster Facilities Administration
Multimaster Mesh Conflict Administration
Best Practices for Preventing Multimaster Conflicts
Examining the State of the Multimaster Mesh
Best Practices for Resolving Database Conflicts
Model Repository Multimaster Component Conflicts
90
Modifying a Facilitys Name
Perform the following steps to modify a facilitys name:
1 From the SAS Web Client Navigation panel, click Environment Facilities. The
Facilities page appears and displays the names of the current facilities.
2 Click the hyperlink name of the facility that you want to modify. The Facilities: Edit
Facility page appears with the Properties tab automatically selected, as Figure 3-1
shows.
Figure 3-1: Properties Tab of the Edit Facility Page
3 To change the name of the facility that appears in the SAS Web Client, edit the Name
field or click the Return to Facilities link to exit without making any changes.
4 To save the new Facility name, click Save. The SAS Web Client displays a message
that confirms that the properties for that facility were updated.
Adding or Modifying a Facilitys Custom Attributes
Perform the following steps to update a facilitys custom attributes:
1 From the navigation panel, click Environment Facilities. The Facilities page
appears and displays the names of the current facilities.
91
2 Click the hyperlink name of the facility that you want to modify. The Facilities: Edit
Facility page appears with the Properties tab automatically selected, as Figure 3-1
shows.
3 Select the Custom Attributes tab.
The Custom Attributes page appears, which provides name-value pairs associated
with this customer.
4 Click the hyperlinked name of an attribute to display the Facilities: Edit Attribute for
[facility name] dialogue and make changes to its associated value.
5 To add a new attribute name and to specify a value to associate with the attribute,
click New.
Be careful when you update or remove existing attribute settings as it might affect or
disrupt operation of the operational environment. Contact your SA Support Representative
to help you determine the appropriate changes to make when you update the information
or settings for a specific facility.
6 When you finish making updates to the facility properties or custom attributes, click
the Return to Facilities link.
Contact your SA Support Representative if you need to make other changes not
described in this section to the Facility properties.
92
Multimaster Mesh Conflict Administration
Multimaster Mesh administration tasks typically involve detecting, preventing, and
resolving the various types of conflicts that can occur when you have users in multiple
Facilities updating multiple, replicated Model Repositories. This section provides
information on Multimaster Mesh administration within SA and contains the following
topics:
Types of Conflicts
Causes of Conflicts
User Overlap
User Duplication of Actions
Out of Order Transactions
Types of Conflicts
A Multimaster Mesh installation can experience conflicts with two types:
Transaction Conflicts
Transaction Conflicts
A transaction conflict can occur when updates are made to the same record in different
Model Repositories.
When transaction conflicts occur, the SA Multimaster components detect them and can
be configured to email alerts to responsible parties.
The SA components themselves cannot resolve the conflicts. SA administrators must use
the Multimaster Tools in the SAS Web Client to resolve the conflicts at the target
databases when they occur to ensure that the transaction updates are not lost. The
administrator can also use the Multimaster Status Monitor described in the SA Planning
and Installation Guide to detect where there are conflicts.
93
Replication conflicts occur in an environment in which concurrent updates to the same
data at multiple sites occurs. For example, when two transactions originating from users
accessing different Model Repositories update the same row at nearly the same time, a
conflict can occur. If you need basic information about database conflicts, see your
Oracle Database documentation.
The probability of Multimaster conflicts occurring varies depending on the following
factors:
The number of servers under management the more servers, the more likely that
conflicts can occur
The number of Facilities in the mesh
The number of installed SAS Web Clients more users making updates
The propensity for users to make changes in more than one facility by using different
SAS Web Clients
How SA Handles Conflicts
When a conflict is flagged, SA takes the following actions:
1 The transaction is canceled.
2 All rows affected by the transaction are locked, thereby preventing further changes to
those rows.
3 The Outbound Model Repository Multimaster Component propagates this change in
a new transaction to all remote databases, thereby locking the rows in all Facilities.
4 An alert message with the conflict information is emailed to a user-configured
mailing list.
5 The Inbound Model Repository Multimaster Component continues on to the next
transaction.
If the Inbound or Outbound Model Repository Multimaster Component encounters an
exception that prevents it from going on to the next transaction, it sends an email to the
user-configured mailing list specifying the problem and shuts down.
94
An SA administrator must manually resolve conflicts using the SAS Web Client. Resolving
the conflict unlocks the rows. See Best Practices for Resolving Database Conflicts on
page 98 in this chapter for more information.
Causes of Conflicts
Conflicts can have the following causes:
User Overlap
User Overlap
Conflicts occur when a user concurrently makes a change using the SAS Web Client in
one Facility as another user makes a change to the same object in another Facility.
For example:
1 Alice removes Node A from a server in the Atlanta Facility.
2 Bob removes Node A from the same server in the Boston Facility.
3 SA propagates the change from the Atlanta Facility to the Boston Facility; however,
Bob has already removed Node A from the server in the Boston Facility. SA
generates a Model Repository Multimaster Component conflict alert because now it
appears that Alice is requesting that a node that does not exist be removed.
4 SA also propagates Bobs update in Step 2 from the Boston Facility to the Atlanta
Facility; however, Alice has already removed Node A from the server in the Atlanta
facility. SA generates a second Model Repository Multimaster Component conflict
alert.
Conflicts can also occur when a user, for various reasons, attempts make an update to a
Model Repository, does not wait long enough for the update to propagate to the other
Model repositories in the Mesh, thinks the update failed, and so attempts to make the
update again, thus creating duplicate updates.
For example, this sequence of events could occur:
95
1 From a server in the Seattle facility, Carol uses the SA Command Line Interface
(OCLI) to upload the package carol.conf.
2 Carol immediately logs in to the SAS Web Client In the Phoenix facility and searches
for the package. She does not see the package because that data has not yet
propagated from Seattle to Phoenix. Carol allowed enough time for data propagation
between facilities.
3 Carol uploads the package carol.conf by using the SAS Web Client in Phoenix.
4 When the data eventually propagates from Seattle, SA generates a conflict because
the data already exists in Phoenix.
Out of order transactions occur only in a Multimaster Mesh with three or more facilities.
Transactions between two Facilities arrive in the order in which they were sent. However, if
a third Facility is involved in the transactions, the correct ordering is not guaranteed.
For example,
1 A user changes or inserts data at Facility A (Model Repository A).
2 The transaction for that change propagates to Facility B (Model Repository B) and to
Facility C (Model Repository C).
3 However, the data is modified again or referenced at Facility B (Model Repository B)
and then propagated to Facilities A and C.
4 If the transaction from Facility B (Step 3) reaches Facility C (Model Repository C)
before the transaction from Facility A (Step 1), a conflict occurs.
This conflict often occurs when a user uploads a package using the OCLI in one Facility,
and immediately adds the package to a Software Policy using the SA Client in different
Facility.
The occurrence of out of order transactions can be aggravated by concurrent updates in
different Facilities and/or problems with inter-Facility network connections.
For example:
1 Henry uses the OCLI on a server in the Denver Facility to upload the package
henry.conf.
96
2 SA propagates data about the package to all Facilities in the mesh; however, it
cannot propagate the data to the Paris Facility because the network connection is
down.
3 Henry logs on to a server in the Miami Facility and uses the SA Client to update the
description of the package henry.conf.
4 SA propagates data about the updated package description to all other Facilities in
the mesh; however, it cannot propagate the data to the Paris Facility because the
network connection is still down.
5 Network connectivity to the Paris Facility is restored and the delayed transactions
from Steps 2 and 4 are propagated to the Paris Facility.
6 The transaction for the updated package description arrives at the Paris Facility
before the transaction that uploaded henry.conf. Therefore, the Model Repository
in the Paris Facility does not contain data about henry.conf, so SA generates a
conflict alert.
7 The transaction uploading henry.conf arrives at the Paris Facility and is processed
without error. The package data exists in the Paris Model Repository, but the package
description differs from all the other facilities in the mesh.
Best Practices for Preventing Multimaster Conflicts
There are measures you can take to keep the number of Multimaster conflicts to a
minimum.
Users
Your users should be aware of the following:
Users in multiple Facilities are able to modify the same data at the same time, so when
possible coordinate updates to avoid conflicts.
Users should not change data in one Facility and immediately make the same change
in another Facility.
A slight time delay occurs before changes that a user makes can propagate to other SA
Facilities. The length of delay varies depending on a number of factors, including
network connectivity and bandwidth. If an update has not propagated to all the other
Model Repositories in the mesh, wait a reasonable period of time to insure that the
97
transaction hasnt been delayed before attempting to redo the transaction or perform
another update that depends on other recent transactions.
Administrators
Implement the following best practices to reduce the chance of data conflicts:
Ensure that your network connections are reliable and there is sufficient network
bandwidth between Facilities in the mesh. The risk of conflicts increases with degraded
network connectivity.
See Network Administration for Multimaster on page 112 in this chapter for more
information.
Also see your see the SA Planning and Installation Guide for information about network
connectivity when running SA with a Multimaster Mesh or contact your SA Support
Representative.
When possible, partition the data space so that more than one user cannot change the
same object in different Facilities concurrently.
Have a user, or a small group of coordinated users, manage a given set of servers.
Partitioning the data space ensures accountability of server ownership and prevents
users from changing each other's data.
The SAS Web Client allows you to set permissions by Customer, Facility, and User
Group types.
See Chapter 2 for more information about User Groups and SA Permissions.
Examining the State of the Multimaster Mesh
You can examine the state of a Multimaster Mesh by launching the SAS Web Client and
selecting the Multimaster Tools option
When you select the Multimaster Tools option, the Multimaster Tools: State View
page appears. In addition to a color-coded legend that shows possible transaction states:
Table 3-1: Multimaster Transaction State Color Code
COLOR STATE
Red Conflict
Orange Not Sent
98
The Multimaster Tools: State View page also provides:
An overview of the health of the Multimaster Mesh achieved by an automatic check of
all Facilities in the mesh.
A display of the state of the last five transactions in the mesh and a list of all conflicting
and unpublished transactions.
The time that the SAS Web Client generated and cached the data. Click Refresh to
refresh the time.
System Diagnosis Tools
Administrators can also use the System Diagnosis tools in the SAS Web Client to view
information about the health of the multimaster components.
See SA Diagnosis on page 142 in Chapter 5 for more information.
Multimaster State Monitoring Utility
If you prefer a command line utility, you can use the Multimaster State Monitoring Utility to
get information about conflicts in your mesh. For more information, see the SA Planning
and Installation Guide.
Best Practices for Resolving Database Conflicts
This section provides information on identifying the kind of conflict you may have and the
steps you can take to resolve the conflict. You should also see your Oracle Database
Administration documentation for much more detailed information about identifying and
resolving data and transaction conflicts.
Yellow Not Received
Gray Unable to Connect
green Good
Table 3-1: Multimaster Transaction State Color Code (continued)
COLOR STATE
99
Types of Conflicts
Guidelines for Resolving Each Type of Conflict
Types of Conflicts
The following are the most typically seen conflicts:
Table 3-2: Types of Conflicts
CONFLICT DESCRIPTION
Identical data conflict The Multimaster Tools show a conflicting transaction
but the data is the same between facilities. The data is
the same because users made the same change in dif-
ferent facilities.
Simple transaction conflict The row exists in all facilities, but some columns have
different values or the row does not exist in some facili-
ties (missing objects).
Unique-key constraint conflict The object does not exist in a facility and cannot be
inserted there because inserting it would violate a
unique-key constraint.
Foreign-key constraint conflict The row does not exist in some facilities and cannot be
inserted because the data contains a foreign key to
another object that also does not exist in that facility.
Linked object conflict A type of conflict encountered in rare cases. SA
includes business logic that links specific related
objects in SA, such as a custom attribute name and
value, and a customer created in the SAS Web Client UI
(appears in lists) and the associated node for the cus-
tomer in the node hierarchy. SA ensures that links
between related objects are maintained. Resolving a
linked object conflict can be complex because you
must attempt to preserve the intent of the transaction
that caused the conflict. Contact your SA Support Rep-
resentative to help you resolve linked object conflicts.
100
Guidelines for Resolving Each Type of Conflict
In general, when you resolve conflicts, apply updates so that the target always reflects the
most current data based on the time stamp of the originating changes.
When you cannot follow one of the preceding guidelines, attempt to preserve the intent of
the transaction. Contact the users who are generating the transactions and determine
what types of changes in the managed environment each user was trying to make.
Identical Data Conflict
All objects in a transaction contain exactly the same data across all facilities. This type of
conflict includes the case where the objects do not exist in all facilities.
To resolve an identical data conflict, simply mark the conflict resolved.
Identical Data Conflict (Locked)
All objects in a transaction contain exactly the same data across all facilities but the
objects in the transaction are still locked (marked conflicting).
To resolve this type of conflict, pick an arbitrary facility and synchronize all objects from it.
Performing this action unlocks the objects. After synchronizing the data, mark the conflict
resolved.
Simple Transaction Conflict
The data is different between facilities or some objects are missing from some facilities.
None of the objects depend on the actions of other conflicting transactions. The results of
synchronizing the objects does not result in a database foreign-key or unique-key
constraint violation.
To resolve a simple transaction conflict, choose the facility that contains the correct data
and synchronize from it. How you determine which facility contains the correct data varies
depending on the type of transaction:
If the conflict is the result of two users overriding each others work, talk to the users
and determine which user's change should be correct.
If the conflict is the result of automated processes overriding each other's data, the
most recent change is usually correct.
If the conflict is the result of out-of-order transactions, the most recent change is usually
correct.
After synchronizing the data, mark the conflict resolved.
101
Unique-Key Constraint Conflict
Resolving these conflicts results in a unique-key constraint violation.
For example, this sequence of events occurs:
1 From the SAS Web Client in the London facility, John creates Node A1 as a
subordinate node of Node A.
2 From the v in the San Francisco facility, Ann performs the same action. She creates
Node A1 as a subordinate node of Node A.
3 Node names must be unique in each branch of the node hierarchy.
4 SA propagates the node changes from the London and San Francisco facilities to the
other facilities. Inserting the rows into the Model Repository databases at other
facilities causes a unique-key constraint violation and a conflict.
Resolving this conflict by inserting the updates from the London facility in all facilities
would fail with the same unique-key constraint violation.
Perform the following steps to resolve a unique-key constraint conflict:
1 Locate all the involved transactions and synchronize one transaction from a facility
where the object does not exist, thereby deleting it in all facilities.
2 Synchronize the other transaction from a facility where the object exists, thereby
inserting the object in all facilities. One of the two uniquely conflicting objects will
take the place of the other.
Foreign-Key Constraint Conflict
Resolving these conflicts results in a foreign-key constraint violation.
For example, this sequence of events occurs:
1 Jerry creates Node B in facility 1.
2 Before that transaction has time to propagate to other facilities, Jerry creates Node C
as a subordinate node of Node B.
3 When the first transaction arrives at facility 2, it generates a conflict for unrelated
reasons.
4 When the second transaction arrives at facility 2, inserting the row for Node C causes
a foreign-key constraint conflict because the parent Node (Node B) does not exist.
Resolving the second conflict first by inserting the update for Node C into all facilities
would fail with the same foreign-key constraint violation.
102
Perform the following steps to resolve a foreign-key constraint conflict:
1 Resolve the conflicting transaction for Node B (the parent Node) by synchronizing
the first transaction from the facility where the object exists.
2 Synchronize the second transaction (the Node C update) from the facility where the
object exists.
Generally, resolving conflicts in the order in which they were created avoids generating
foreign-key constraint conflicts.
This section provides information on resolving model repository, multimaster component
conflicts and contains the following topics:
Overview of Resolving Model Repository Multimaster Component Conflicts
Resolving a Conflict by Object
Resolving a Conflict by Transaction
Overview of Resolving Model Repository Multimaster Component Conflicts
SA administrators can view and resolve multimaster conflicts in any SAS Web Client by
using the Multimaster Tools. The Multimaster Tools are available in all SAS Web Clients.
Before you resolve conflicts, notify the subscribers of the email alert alias. Notifying these
users helps to prevent other SA administrators from undoing or affecting each others
conflict resolution efforts. While resolving conflicts, you should resolve the conflict from
the SAS Web Client of a single facility. Do not attempt to resolve the same conflict
multiple times from the SAS Web Client of different facilities.
If you see a large volume of conflicts that you cannot resolve by using the Multimaster
Tools, contact your SA Support Representative for assistance synchronizing databases.
103
Resolving a Conflict by Object
Perform the following steps to resolve conflicting transactions by object:
1 From the navigation panel, click Administration Multimaster Tools. The Multimaster
Tools: State View page appears, showing a summary of all transactions and, if they
exist, all conflicts. See Figure 3-2.
Figure 3-2: Transaction Table That Shows Conflicts
Different types of transaction statuses are indicated by color-coded boxes:
Green: The last five transactions that were successfully sent.
Orange: All transactions that have not been published (sent to other facilities).
Red: All conflicts.
104
Each box is displayed in a color scheme to indicate the status and success of the
transaction. A key that explains the significance of the colors, like the one shown in
Figure 3-3, is listed at the top of the page.
Figure 3-3: Conflict Color Key
Red boxes indicate that one or more transactions between facilities are in conflict
and need to be resolved.
2 To resolve a conflict, select the Conflict View tab. The Multimaster Tools: Conflict View
page appears, as shown in Figure 3-4.
Figure 3-4: Transaction Differences Page That Lists all Transactions in Conflict in the Multimaster Mesh
The page lists each transaction by ID number (clickable link), the actions that caused
the conflict, the database objects affected by the conflict, the user responsible for the
conflict (listed by the IP of the SAS Web Client where the user made the change),
when the offending action occurred, the source facility that originated the transaction,
and the facilities where the transaction conflicted.
The page might show a conflict where the data is the same in both facilities but a conflict
exists, because the same change was made in both facilities. Even though the data is
correct, the conflict still exists and must be resolved. See Best Practices for Resolving
Database Conflicts on page 98 in this chapter for more information.
105
3 To resolve a conflict, click the transaction ID number link. You see the Multimaster
Tools: Transaction Differences page, which shows a comparison of the objects
between facilities, with any differences shown in red, as illustrated in Figure 3-5.
Figure 3-5: Transaction Differences Page for Multimaster Tools Showing Conflicts Between Facilities
4 To resolve each object, click Synchronize From at the bottom of the object.
The Multimaster Tools insert or delete objects in the transaction where necessary,
and then propagate the change to every facility in the Multimaster Mesh.
106
The Multimaster Tools: Object Synchronization Results page appears, displaying the
results of the transaction synchronization, as shown in Figure 3-6.
Figure 3-6: Object Synchronization Result Page
107
5 Click the Return to Transaction Differences link. The Multimaster Tools: Transaction
Difference page appears. Notice that the object you synchronized shows on the
page as being identical between the facilities, as shown in Figure 3-7.
Figure 3-7: Single Object Resolved
108
6 Continue synchronizing the objects in the transaction until all objects in the
transaction are synchronized. (Repeat steps 3 and 4.) When all objects in the
transaction are synchronized, Mark Resolved appears at the bottom of the page, as
Figure 3-8 shows.
Figure 3-8: When All Conflicts Are Resolved, the Mark Resolved Button Appears
7 Click Mark Resolved. The Multimaster Tools: Mark Conflict Resolved page appears,
as Figure 3-9 shows. The page displays the results of marking a transaction resolved.
Figure 3-9: Multimaster Tools Mark Conflict Resolved Page
After it is marked resolved, the transaction disappears from the State and Conflicts
views after SA refreshes the data in the Multimaster Tools.
8 Click the link to return to the Conflict view.
Resolving a Conflict by Transaction
Perform the following steps If you know that synchronizing all objects from one facility will
resolve the conflict:
1 From the navigation panel, click Administration Multimaster Tools. The Multimaster
Tools: State View page appears, showing a summary of all transactions and, if they
exist, all conflicts.
109
2 To resolve a conflict, select the Conflict View tab. The Multimaster Tools: Conflict View
page appears, as shown in Figure 3-10.
Figure 3-10: Transaction Differences Page That Lists all Transactions in Conflict
The page lists each transaction by ID number (clickable link), the actions that caused
the conflict, the database objects affected by the conflict, the user responsible for the
conflict (listed by the IP of the SAS Web Client where the user made the change),
when the offending action occurred, the source facility that originated the transaction,
and the facilities where the transaction conflicted.
110
3 Click the link of the transaction you want to resolve. You now see the Multimaster
Tools: Transaction Differences page, as shown in Figure 3-11.
Figure 3-11: Transaction Differences Page for Multimaster Tools Showing Conflicts Between Facilities
111
4 From the Synchronize all objects from drop-down list at the top of the page, select
the facility to use as the correct source of data, as Figure 3-12 shows.
Figure 3-12: By Transaction
See Best Practices for Resolving Database Conflicts on page 98 in this chapter for
more information
5 Click Update beside the drop-down list. The Multimaster Tools: Transaction
Synchronization Results page appears, as shown in Figure 3-13.
Figure 3-13: Transaction Synchronization Results for All Objects in Transaction
This page shows the results of the synchronization and prompts you to mark the
conflicts resolved.
6 Click Mark Resolved. The Multimaster Tools: Mark Conflict Resolved page appears.
The page displays the results of marking a transaction resolved.
7 Click the link to return to the Conflict view. After it is marked resolved, the transaction
disappears form the State and Conflicts views after SA refreshes the data in the
Multimaster Tools.
112
Network Administration for Multimaster
SA does not require that a multimaster configuration meet specific guidelines on network
uptime. A multimaster configuration functions acceptably in a production environment that
experiences temporary inter-facility network outages.
However, as the duration of a network outage increases, the probability of multimaster
conflicts increases. Extended network outages between facilities can cause the following
problems:
Multimaster messages fail to propagate between facilities.
The Multimaster Tools stop functioning.
SAS Web Clients cannot contact the multimaster central Data Access Engine.
Production experience for multimaster configurations supports the performance data that
Table 3-3 shows.
Network connectivity issues include TIBCO or multicast routing problems.
Multimaster Alert Emails
When multimaster conflicts occur or multimaster components experience problems, SA
sends an email to the configured multimaster email alias.
This email address is configured when SA is installed in a facility. For assistance changing
this email address, contact your SA Support Representative or See SA Configuration on
page 219 in Chapter 7 for more information.
Table 3-3: Performance Data for Multimaster Configurations
# FACILITIES DURATION NETWORK OUTAGE
# MULTIMASTER
CONFLICTS *
8 facilities
(SA core installed in each
facility)
12 hour outage
(1 facility looses network
connectivity to the other facilities)
12 to 24 conflicts
(average number
generated)
* The propensity of users to manage servers in the disconnected facility with SAS Web
Clients in other facilities increases the number of conflicts.
113
The subject line of the alert email specifies:
The type of error that occurred when a transaction was being applied to a Model
Repository database
The type of error that caused problems with the multimaster operation
Contact your SA Support Representative for assistance troubleshooting and resolving SA
problems that affect the multimaster operation.
See Table 3-4 for error messages.
Table 3-4: Multimaster Error Messages
SUBJECT LINE TYPE OF ERROR DETAILS
vault.ApplyTransactionError Multimaster Transaction
Conflict
The local database was not
successfully updated with the
changes from the other database.
Each update must affect only one
row and not result in any
database errors.
vault.configValueMissing SA Problem No value was specified for a
given configuration parameter.
Log into the SAS Web Client and
provide the value for this
configuration parameter. Contact
your SA Support Representative
for assistance setting SA
configuration values.
vault.DatabaseError Multimaster Transaction
Conflict
An error occurred while querying
the database for updates to send
to other databases or while
applying updates from other
databases. Restart the Model
Repository Multimaster
Component.
114
vault.InitializationError SA Problem An error occurred when the Model
Repository Multimaster
Component process started. The
application returned the message
specified. The thread that
encountered the error stopped
running. This error occurs when
running SA in multimaster mode.
Resolve the error condition.
Restart the Model Repository
Multimaster Component.
vault.ParserError Multimaster Transaction
Conflict
An error occurred when parsing
the XML representation of the
transaction. The application
returned the message specified.
This error occurs when running
SA in multimaster mode.
Run the SA Admin Multimaster
Tools and verify that the
transaction data does not contain
special characters that the XML
parser might be unable to
interpret.
Table 3-4: Multimaster Error Messages (continued)
115
vault.SOAPError Multimaster Transaction
Conflict
An error occurred while using
SOAP libraries to marshal or un-
marshal transactions into XML.
The application returned the
message specified. This error
occurs when running SA in
multimaster mode.
Run the SA Admin Multimaster
Tools and verify that the
transaction data does not contain
special characters SOAP might be
unable to interpret.
vault.TibcoError SA Problem The TIBCO transport raised an
error. The application returned the
message specified. The thread
that encountered the error
stopped running. This error occurs
when running SA in multimaster
mode.
Resolve the TIBCO transport error.
See TIBCO User's Guide. Restart
the Model Repository Multimaster
Component.
vault.UnknownError SA Problem The Model Repository Multimaster
Component process encountered
an unknown error. Contact
technical support and provide the
database name and SA
component's log file.
Table 3-4: Multimaster Error Messages (continued)
116
117
Chapter 4: Satellite Administration
Overview of the SA Satellite
A Satellite installation can be a solution for remote sites that do not have a large enough
number of potentially Managed Servers to justify a full SA Core installation. A Satellite
installation allows you to install only the minimum necessary Core Components on the
Satellite host which then accesses the Primary Cores database and other services
through a Gateway connection.
A Satellite installation can also relieve bandwidth problems for remote sites that may be
connected to a primary facility through a limited network connection. You can cap a
Satellites use of network bandwidth to a specified bit rate limit. This allows you to insure
that Satellite network traffic will not interfere with your other critical systems network
bandwidth requirements on the same pipe.
A Satellite installation typically consists of, at minimum, a Satellite Gateway and a
Software Repository Cache and still allows you to fully manage servers at a remote facility.
The Software Repository Cache contains local copies of software packages to be
installed on Managed Servers in the Satellite while the Satellite Gateway handles
communication with the Primary Core. You can optionally install the OS Provisioning Boot
Server and Media Server on the Satellite host to support remote OS Provisioning.
Installing other components on the Satellite host is not supported.
For information about how to install and configure a Satellite, see the SA Planning and
Installation Guide.
Overview of the SA Satellite
Satellite Information and Access
Software Repository Cache Management
Creation of Manual Updates
118
Figure 4-1, shows a Satellite linked to a Single-Node Core via the Management Gateway.
Figure 4-2, shows two Satellites linked to an SA core via the Management Gateway.
Figure 4-1: A Single-Node Core with a Single Satellite
Software
Repository
San Francisco CORE
Model
Repository
Agent
Gateway
Gateway
A A A
Other Components
San Jose SATELLITE
OS Prov
Media
Server
OS Prov
Boot
Server
Software
Repository
Cache
A A A
Management
Satellite
Gateway
Core
Gateway
119
Figure 4-2: Single-Node Core with Multiple Satellites
Management Gateway
Connectivity with an SA core is achieved through a Management Gateway that resides in
the same IP address space as the servers that it manages. This Management Gateway
maintains a connection to the Core Gateway, either directly or through a network of
Gateways. All traffic between the servers in the Satellite and the core that manages them
is routed through Gateways.
Facilities and Realms
To support Server Agents in overlapping IP address spaces, an SA core supports realms.
Software
Repository
San Francisco CORE
Model
Repository
Agent
Gateway
Gateway
A A A
Software
Repository
Cache
San Jose SATELLITE
Gateway
A A A A A A
Other Components
Software
Repository
Cache
Gateway
Sunnyvale SATELLITE
Management
Satellite
Satellite
Core
Gateway
120
One or more Gateways service the managed servers contained within a realm. In SA, a
realm is a routable IP address space, which is serviced by one or more Gateways. All
managed servers that connect to an SA core via a Gateway are identified as being in that
Gateways realm.
A facility is a collection of servers that reside in a single physical location. A facility can be
all or part of a data center, server room, or computer lab. A facility can contain multiple
realms to support managed servers with overlapping IP address spaces. Each IP address
space requires a separate realm. Typically, each physical building is modeled as a facility
that has as many realms as needed.
Satellite Information and Access
Permissions Required for Managing Satellites
Viewing Facilities
Viewing the Realm of a Managed Server
Viewing Gateway Information
Permissions Required for Managing Satellites
To access the Manage Gateway feature, you must have the Manage Gateway permission.
By default, this permission is included in the SA System Administrators group. To view
facility information, you must have Read (or Read & Write) permission for the specific
facility. Chapter 2, User and Group Setup for more information about user groups and SA
permissions.
121
Viewing Facilities
The Facilities page in the SAS Web Client lists the core and Satellite facilities. In particular,
the Facilities page displays Unreachable Facilities, as shown in Figure 4-3.
Figure 4-3: Facilities Channel
Clicking the link for a facility, and then selecting the Realms tab displays the configured
bandwidth of the connections between the realms in that facility, as shown in Figure 4-4.
Figure 4-4: Realms in Facilities
122
Additionally, you can view the facilities that contain realms by clicking Administration
System Configuration as shown in Figure 4-5.
Figure 4-5: Satellite Configuration Parameters
123
Enabling the Display of Realm Information
By default, the SAS Web Client does not display realm information, which is needed by
users who manage Gateways and Software Repository Caches.
To enable access to the realm information, perform the following steps:
1 Log into the SAS Web Client as a user that belongs the Administrators group and to
a group that has the Configure Opsware permission.
2 From the navigation panel, click Administration System Configuration.
3 Select the Opsware Server Automation System Web Client link.
4 In the System Configuration page, for the name owm.features.Realms.allow,
type the value true.
5 Click Save.
Viewing the Realm of a Managed Server
When installed in a Satellite configuration, SA can manage servers with overlapping IP
addresses. This situation can occur when servers are behind NAT devices or firewalls.
Servers with overlapping IP addresses must reside in different realms.
When retrieving a list of servers resulting from a search, you might see multiple servers
with the same IP address but in different realms. You might also see multiple servers with
the same IP address when you are planning to run a custom extension and you are
prompted to select the servers to run the extension on.
124
The SAS Web Client displays additional information to make it clear which server contains
the server corresponding to the IP address, as shown in Figure 4-6.
Figure 4-6: Server Properties Page Showing the Realm of a Managed Server
125
Viewing Gateway Information
To access the Manage Gateway feature, click Administration Gateway in the SAS Web
Client navigation panel. The Manage Gateway page appears, as Figure 4-7 shows. From
the left list, select the Gateway you want to view information for, and then click the link for
the page you want to view.
Figure 4-7: Status Page of the Manage Gateway Feature
You use the Manage Gateway feature for the following tasks:
To obtain debugging and status information about the Gateways and the tunnels
between Gateways
To perform specific tasks for Gateways, such as changing the bandwidth limits or
tunnel cost between Gateway instances, restarting Gateway processes, or changing
the logging levels for Gateway processes
Page Selection
Gateway
Selection
126
Viewing Diagnostic and Debugging Information
1 From the navigation panel, click Administration Gateway. The Manage Gateway
page appears.
2 From the left list, select the Gateway that you want to view information for. The Status
page for that Gateway appears.
The Status page displays the following information for the Gateway:
A table of active tunnels. This table includes tunnel cost, bandwidth constraints,
bandwidth estimations, and the age of the tunnels.
Information about the internal message queues. Each column in the table for a
queue displays data in this format:
Number of messages in the queue | The message high-water mark for the queue|
Maximum value configured for the queue | The last time the message high-water
mark was reached for the queue
You can use the timestamp indicating when the message high-water mark was
last reached to troubleshoot Gateway issues. The timestamp is displayed in the
format days:hours:minutes: seconds.
3 To view the details and statistics for a tunnel between Gateways, click the link for the
Gateway that terminates the tunnel, as Figure 4-8 shows.
Figure 4-8: Manage Gateway Feature Status Page
The page refreshes and displays the tunnel details and statistics.
4 To view the following pages containing diagnostic information, click the link for the
page in the menu bar.
127
Flows page: Displays information about all open connections for the selected
Gateway.
Routing page: Displays the inter-Gateway routing table. This table shows which
tunnel will be used to reach another Gateway in the mesh. The routing table is
computed from the data in the path database.
When a tunnel collapses, the route information is retained for 2 minutes by default
in the routing table to provide some inertia and stability for the Gateway mesh.
The routing computation automatically updates when the link cost for a connection
is changed.
Path database (PathDB) page: Displays the least cost route to all reachable
Gateways in the Gateway mesh. The least cost route to all reachable Gateways is
determined by using the data in the link state database.
Link State database (LSDB) page: Displays information for the state of all
tunnels from the perspective of each Gateway instance. The LSDB contains the
data for all tunnels and the bandwidth constraint for each tunnel.
Configuration (Config) page: Displays the properties file for the Gateway you are
viewing information for. The page includes the path to the properties file on the
server running the Gateway component.
Below the properties values, the page contains crypto file information and the
mesh properties database.
Above the properties values, the Properties Cache field appears. When you
change the bandwidth or link cost for a connection between Gateways, the
updated value appears in this field if the update was successful.
History: Displays historical information about the inbound (ingress) and outbound
(egress) connections between hosts using the Gateway mesh. For example, when
host A in realm A connected to host B in realm B.
Finding the Source IP Address and Realm for a Connection
The Ident page provides an interface to the real-time connection identification database. If
necessary, contact HP Support for additional information about how to run this tool.
page appears.
2 From the top bar (the page selector), click Ident. The page refreshes with an interface
to the real-time connection identification database.
128
3 In the text field, enter the protocol and source port for an active connection (for
example, TCP:25679).
4 Click Lookup.
The page refreshes with the client realm and client IP address where the connection
came from.
Changing the Bandwidth Usage or Link Cost Between Gateways
page appears.
2 To set a bandwidth limit for a connection:
1. From the top bar (the page selector), click Bandwidth. The page refreshes with
fields to specify the bandwidth for the connection between Gateway instances.
2. Specify two Gateway instance names that are connected by a tunnel.
3. Specify the bandwidth limit you want in kilobits per second (Kbps). Specify zero
(0) to remove bandwidth constraints for the connection.
4. Click Apply.
3 To set a link cost for a connection:
1. From the top bar (the page selector), click Link Cost. The page refreshes with
fields to specify the link cost for the connection between Gateway instances.
2. Specify two Gateway instance names that are connected by a tunnel.
3. Specify the cost you want in the Cost field.
4. Click Apply.
Viewing the Gateway Log or Change the Log Level
Changing the logging level to LOG_DEBUG or LOG_TRACE greatly increases the log
output of the Gateway and can impact the performance of the Gateway.
page appears.
2 From the top bar (the page selector), click Logging. The page refreshes with the tail
of the Gateway log file.
129
3 To change the logging level, select an option: LOG_INFO, LOG_DEBUG, or LOG_
TRACE.
4 Click Submit.
Restarting or Stopping a Gateway Process
page appears.
2 From the top bar (the page selector), click Process Control. The page refreshes.
3 To restart the Gateway process, click Restart.
4 To stop the Gateway watchdog and the Gateway, click Shutdown.
Stopping a Gateway process can cause problems for an SA core. For example, if you stop
a core Gateway process, you will stop all multimaster traffic to that SA core. Additionally,
the Manage Gateway UI is unavailable after stopping the process.
To restart the Gateway after stopping it from the Manage Gateway page, you must log
onto the server running the Gateway component and manually restart the process.
Software Repository Cache Management
The largest amount of traffic in an SA core is between the Software Repository and the
Server Agent (during software or patch installation) and between a server being
provisioned and the media server servicing the installation.
When a Satellite is connected by a low-bandwidth network link, during software
installation on servers SA performance in the Satellite will be poor unless special steps
are taken, for example, installing a 1GB software package onto a server in a Satellite
connected by a 56 kbps link will take a long time.
By placing a local copy of the Software Repository and OS installation media local to the
Satellite in a Software Repository Cache, bandwidth utilization can be optimized. In a
Satellite, the Software Repository Cache contains copies of files that are local to the
Satellite.
130
The Software Repository Cache stores files from the Software Repository in an SA core or
from another Software Repository Cache, and supplies the cached files to Server Agents
on managed servers. The Satellite supports multiple Software Repository Cache per
realm.
Availability of Packages on the Software Repository Cache
All content, such as patches, software updates, and so on, might not be available locally
at all Satellites. SA indicates whether a package is available locally or whether the Satellite
needs to obtain an update from the Software Repository in the SA core.
The SAS Web Client does not proactively warn you that software installation will fail
because the package is unavailable locally and caching constraints do not allow On-
demand Updates.
Instead, when SA is attempting to remediate the software onto a managed server, the
SAS Web Client generates an error and displays a complete list of missing packages to
help you identify the packages that need to be staged.
The SAS Web Client does not provide a User Interface to push packages to Satellites. To
push packages to a Satellite, the command-line tool stage_pkg_in_realm may be
used. This tool is found on the wordbot in /opt/opsware/mm_wordbot/util. The
Software Repository Cache allows a client to request that it obtain a file, but that it not
actually send the file to the client. If the file is not already cached, the Software Repository
Cache will obtain it from the parent Software Repository Cache if the caching policy
allows it. To use this feature, the client includes the argument checkonly=1 in the URL
request for the file.
Ways to Distribute Packages to Satellites
To update files in a Satellite, the Software Repository Cache in that facility can be
configured to update cached copies of files as requests are received (On-demand
Updates) or to update the cached copy of a file manually (Manual Updates):
On-demand Update: The local Software Repository Cache obtains current files when
needed from the Software Repository in the SA core.
Manual Update: Software packages are staged to a Satellite's Software Repository
Cache in advance of package installation so that performance will be about the same
as if the managed server was in the same data center as the core.
131
It is always possible to stage a file on a Software Repository Cache regardless of the
caching policy. See Staging Files to a Software Repository Cache on page 137 in this
chapter for more information.
If the file is already present on the local Software Repository Cache and is current, no
action will be taken. If the file is not present locally or it is not current, the Software
Repository Cache will attempt to download the file in the background from the upstream
Software Repository Cache or Software Repository. If the caching policy for the realm of
the Software Repository Cache is on-demand, the download will be successful. If the
caching policy is Manual Update, the Software Repository Cache will raise a
wordbot.unableToCacheFile exception.
The flowchart in Figure 4-9 illustrates the logic that the Software Repository Cache uses
to update packages in a Satellite.
Figure 4-9: Software Repository Cache Update Logic
Download
PequesI
Peceived
Call
locaIePeer()
Serve from
peer,
local_only=1.
File noI found.
(Policy prevenIs
a download.)
Serve file
locally.
UpdaIe
PealmUniI if iI
doesn'I exisI.
DeleIe local
file.
DeleIe
PealmUniI
if iI exisIs.
Serve from
service name
"wordcache",
local_only = 0.
UpdaIe PealmUniI
if successful.
|s file
locally
available?
Peer
found
?
Does a
PealmUniI
for Ihis
realm
exisI
?
|s Ihe
cache policy
sneakerneI
only
?
CalculaIe
checksum.
|s iI ==
in IruIh
?
NO NO
NO
NO
NO
YES
YES
YES
YES
YES
132
Setting the Update Policy
You can specify the Software Repository Cache update policy for specific facilities by
performing the following steps:
1 From the SAS Web Client navigation panel, click System Configuration under
Administration. The Select a Product page appears.
2 Click the link of the realm for which you want to set the Software Repository Cache
update policy. The configuration values for that facility appear.
3 For the parameter named word.caching_policy, set the caching policy value by
selecting the Use default value option or the Use value option and typing
SNEAKERNET, as shown in Figure 4-10. In the SAS Web Client, On-demand Update
is referred to as Just-in-time (JIT) and Manual Update is referred to as Sneakernet.
Figure 4-10: Software Repository Cache Configuration Parameters
4 Click Save to apply your configuration change. Since the Software Repository Cache
polls for configuration changes every five minutes (by default), it make take up to five
minutes for your change to take affect.
133
On-demand Updates
Each time a Server Agent on a managed server in a Satellite requests a package, the
local Software Repository Cache checks the currentness of its cached copy of the file. If
the cached file is out of date (or missing), the Software Repository Cache obtains an
updated copy of the file from the upstream Software Repository Cache or from the
Software Repository in the core and sends it to the Server Agent.
When configured for On-demand Updates, the Software Repository Cache requests the
checksum of each requested file from the Model Repository.
For security purposes, SA caches the checksums about the currentness of a file for a
configurable period of time only.
If the checksum is the same as the locally-stored file, the Software Repository Cache
serves the file to the requester. If the checksum does not match or the local file is not
present, the Software Repository Cache requests a copy of the file. The Gateway routes
the request to the upstream Software Repository Cache in the Gateway hierarchy or to the
Software Repository if no upstream Software Repository Cache exists.
If network connectivity is lost while the Software Repository Cache is downloading a file
from an upstream Software Repository Cache or from the Software Repository in the core,
the next time an Server Agent requests the same file, the Software Repository Cache will
resume the file download from the point it stopped.
Manual Updates
In Satellites that are behind low-bandwidth network links, the Manual method for updating
a Software Repository Cache can be used to pre-populate a cache at installation time or
to refresh a cache. The Software Repository Cache is populated by an out-of-band
method, such as by cutting CDs of the required packages and shipping them to the
Satellite.
When configured for Manual Updates, a Software Repository Cache does not
communicate with upstream Software Repository Cache or the Software Repository in the
core unless requested. It treats its cache as authoritative.
134
Emergency updates can still be manually pushed over the network to Satellites even if the
caching policy is Manual only Update. You do not need to reconfigure the Software
Repository Cache's caching policy to push emergency updates to a Software Repository
Cache. For example, an emergency patch can be staged to a Satellite and applied
without waiting for a shipment of CDs to arrive.
The SAS Web Client displays a warning when a user stages a package to a Software
Repository Cache that is configured for Manual Update.
Additionally, a Manual Update can be applied to any Software Repository Cache
regardless of its update policy.
When applying manual updates in a Satellite with multiple Software Repository Caches,
you must apply the update to each Software Repository Cache in the Satellite. Otherwise,
when performing operations that retrieve files from the Cache (for example, when
installing software on a server in the affected Satellite), you may get the
wordbot.unableToCache file error.
Hierarchical Software Repository Caches
When SA contains hierarchal realms, each realm can contain a local Software Repository
Cache.
When a Server Agent requests an unavailable file from its local Software Repository
Cache, the Software Repository Cache checks its configuration to see if it is allowed to
perform an On-demand Update. If configured for updates, the request is passed up the
topology chain only until the requested file is found or until a Software Repository Cache
is configured for Manual Updates.
If the file is unavailable because of the caching policy, you can stage the file to the local
Software Repository Cache. Because of this behavior, Manual Updates need only be
applied to the top-level Software Repository Cache within a Manual Update only zone.
Cache Size Management
If you apply a Manual Update to a Software Repository Cache configured for Manual only
updates, the Software Repository Cache will remove files that have not been recently
accessed when the cache size limit is exceeded.
When the Software Repository Cache exceeds the cache size limit, the least-recently
accessed packages are deleted first, regardless of whether they are current or not.
135
The Software Repository Cache removes the files the next time it cleans up its cache. By
default, the cache is cleaned up every 12 hours. Packages are deleted so that the
available disk space goes below the low water mark.
You must have enough disk space to store all necessary packages for the Software
Repository Cache to ensure that the Software Repository Cache does not exceed the
cache size limit.
Creation of Manual Updates
To create a Manual Update, you can use the SA DCML Exchange Tool (DET) to copy
existing packages from an SA core. You can then save the exported file to CD or DVD to
apply later to a Satellite Software Repository Cache.
Creating a Manual Update Using the DCML Exchange Tool (DET)
Applying a Manual Update to a Software Repository Cache
Staging Files to a Software Repository Cache
Microsoft Utility Uploads and Manual Updates
Creating a Manual Update Using the DCML Exchange Tool (DET)
You perform this procedure by using the DCML Exchange Tool (DET). Using the DET, you
export the packages you want for the Manual Update and export the packages
associated with selected software policies.
See the SA Content Utilities Guide for more information about the DET.
To create a Manual Update perform the following steps:
1 On the server where you installed the DET component, enter the following command
to create the following directory:
mkdir /var/tmp/sneakernet
2 From the server running the SAS Web Client component in the SA core, copy the
following files from the /var/opt/opsware/crypto/occ directory:
opsware-ca.crt
136
spog.pkcs.8
to the following directory:
/usr/cbt/crypto
This is the directory where you installed the DET.
3 Create the following file /usr/cbt/conf/cbt.conf so that it contains this
content:
twist.host=<twist's hostname>
twist.port=1032
twist.protocol=t3s
twist.username=buildmgr
twist.password=buildmgr
twist.certPaths=/usr/cbt/crypto/opsware-ca.crt
spike.username=<your username>
spike.password=<your password>
spike.host=<way's hostname>
way.host=<way's hostname>
spin.host=<spin's hostname>
word.host=<word's hostname>
ssl.keyPairs=/usr/cbt/crypto/spog.pkcs8
ssl.trustCerts=/usr/cbt/crypto/opsware-ca.crt
4 Create the following DCML Exchange Tool filter file /usr/cbt/filters/
myfilter.rdf that contains this content:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF [
<!ENTITY filter "http://www.opsware.com/ns/cbt/0.1/filter#">
]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
ns#"
xmlns="http://www.opsware.com/ns/cbt/0.1/filter#">
<ApplicationFilter rdf:ID="a1">
<path>/Other Applications</path>
<directive rdf:resource="&filter;Descendants" />
</ApplicationFilter>
</rdf:RDF>
In the <path> directive of the filter file, replace /Other Applications with the
path to the node you want to export (all node information about that node, its
descendants, and all associated packages will be exported).
This filter will export from the Applications area of the SAS Web Client. If you want to
export packages from some other category of software in the SAS Web Client, you
need to create a different filter. See the SA Content Utilities Guide for information.
137
5 On the server where you installed the DET component, run the DCML Exchange Tool
by entering the following command:
/usr/cbt/bin/cbt -e /var/tmp/myexport --config /usr/cbt/
conf/cbt.conf --filter /usr/cbt/filters/myfilter.rdf
The DCML Exchange Tool places the packages associated with the exported nodes
in the following directory:
/var/tmp/myexport/blob
The packages are named unitid_nnnnnnn.pkg.
6 Copy all of the .pkg files to a directory on the server running the Software
Repository Cache, either over the network or by burning the files to a set of CDs.
Applying a Manual Update to a Software Repository Cache
To apply a Manual Update to a Software Repository Cache, you run a utility
(import_sneakernet), which moves or copies the packages you want to update into
the right location on the Software Repository Cache and registers them with the Model
Repository in the SA core.
To apply a Manual Update to a Software Repository Cache, perform the following steps:
1 Log in as root on the server running the Software Repository Cache in the Satellite.
2 Mount the CD containing the packages or copy them to a temporary directory.
3 Enter the following command to change directories:
cd /opt/opsware/mm_wordbot/util
4 Enter the following command to import the contents of the Manual update to the
Software repository Cache:
./import_sneakernet -d dir
where dir is the CD mount point or the temporary directory containing the
packages.
Staging Files to a Software Repository Cache
The Software Repository Cache allows a Server Agent on a managed server to override
the caching policy in effect for the realm. The ability to override the caching policy of a
Software Repository Cache allows you to stage a file to a Manual Update only Satellite in
the following types of situations:
138
You need to circulate an emergency patch when you do not have time to create a
Manual update set and physically visit the facility.
A necessary patch will be installed during a specified maintenance time period and the
time period is not long enough to download the patch and install it on all managed
servers.
The utilization of the network link to the Satellite is known to be low at a particular time
of day.
To force package staging, the client includes the argument override_caching_
policy=1 in the URL request for the file.
The Software Repository Cache allows a client to request that it obtain a file, but that it not
request for the file.
Running the Staging Utility
To run the staging utility, perform the following steps:
1 On the server running the Software Repository component, verify that the certificate
token.srv is in your CRYPTO_PATH. During installation token.srv is copied to
/var/opt/opsware/crypto/gateway/token.srv.
2 Log into the server running the Software Repository component.
3 Enter the following command to change directories:
cd /opt/opsware/mm_wordbot/util
4 To stage the files you want, run the utility stage_pkg_in_realm which has the
following syntax:
./stage_pkg_in_realm [-h | --help] [-d | --debug]
[--user <USER>] --pkgid <ID> --realm <REALM> [--gw
<IP:PORT>] [--spinurl <URL>] [--wayurl <URL>] [--word
<IP:PORT>]
Example: Command to Run the Staging Utility
./stage_pkg_in_realm --user admin --pkgid 80002 --realm luna
--gw 192.168.164.131:3001
139
Password for admin: <password>
Package /packages/opsware/Linux/3ES/miniagent is now being
staged in realm luna
Microsoft Utility Uploads and Manual Updates
When you upload new Microsoft utilities, including the Microsoft Patch Database
(mssecure.cab), the Microsoft Baseline Security Analyzer (mbsacli.exe), or the
Windows chain.exe utility to the Software Repository, you should immediately stage
those files to all realms where the Software Repository Cache is configured for Manual
only Updates.
If you do not stage these files to the remote realms, Server Agents running on Windows
servers in those realms will be unable to download new versions of the utilities and will be
unable to register their software packages. It is not necessary to stage packages to
realms where the Software Repository Cache is configured for On-demand Updates.
The Software Repository Cache allows a client to request that it obtain a file, but that it not
request for the file. See Running the Staging Utility on page 138 in this chapter for
information about how to stage files.
140
141
Chapter 5: SA Maintenance
Possible SA Problems
This section provides information about possible SA problems and contains the following
topics:
SA Component Troubleshooting
While maintaining SA, you might encounter the following types of problems:
Operational problems: processes failing or becoming unresponsive (Data Access
Engine, Command Engine, Software Repository)
Failure of an SA component, which causes other components to fail
SA Diagnosis
The Health Check Monitor for an SA Core
Extensibility of the Health Check Monitor
Logs for SA Components
Global Shell Audit Logs
Start Script for SA
SA Software
Mass Deletion of Backup Files
Designations for Multiple Data Access Engines
Web Services Data Access Engine Configuration Parameters
142
The following examples describe the effects of some component failures:
If the Data Access Engine fails, the SAS Web Client the Command Engine, and the
Software Repository components will fail.
If the Software Repository fails to contact the Data Access Engine, downloads from the
Software Repository are impossible.
If the Model Repository fails, the Data Access Engine fails.
The Software Repository fails to contact the Data Access Engine without either a
functioning DNS, or a properly-configured /etc/hosts file.
Unreachable servers existing in the managed environment.
Many problems with the Code Deployment & Rollback (CDR) feature are caused by errors
with the CDR configuration and setup. See the SA Users Guide: Server Automation for
information about CDR configuration.
SA Diagnosis
This section provides information about how to diagnose SA problems and contains the
following topics:
Diagnosis Tool Functionality
System Diagnosis Test Components
Data Access Engine Tests
Software Repository Tests
Web Services Data Access Tests
Command Engine Tests
Model Repository Multimaster Component Tests
Running a System Diagnosis of SA Core Components
143
The following mechanisms for troubleshooting SA are available:
Running SA Diagnosis tool (a tool for debugging common problems with SA Core
Components). See SA Diagnosis on page 142 in this chapter for more information.
Reviewing error logs for components. See Logs for SA Components on page 162 in
this chapter for more information.
Diagnosis Tool Functionality
By using the System Diagnosis tool, you can check the functionality of the SA Core
Components and the ability of servers running in the managed environment to interact
with the SA Core.
You can troubleshoot most of the errors that occur within the SA Core by running the SA
Diagnosis tool.
System Diagnosis Testing Process
The System Diagnosis tool tests the SA Core Components first, and then, optionally, tests
the servers that you specify, which are running in the managed environment.
The System Diagnosis tool performs intensive tests which check the functionality of the
SA components:
Standalone Tests: The first suite of tests, which tests as much of the functionality of
that component as possible without the use of other SA components. The Standalone
Tests are run to verify a base level of functionality and the component's ability to
respond to an XML-RPC call.
Comprehensive Tests: The second suite of tests, which tests the full functionality of
each component.
On completion of the Comprehensive Tests, the System Diagnosis tool displays the
success of each test, the results, and error information for the tests that failed.
The components are not tested in a specific order; however, the tests generally occur in
this order:
Server Agent Standalone Tests
Server Agent Comprehensive Tests
144
Component Standalone Tests
Component Comprehensive Tests
System Diagnosis Test Components
The tests for the components simulate all the functionality that each component
represents. In addition to errors, the tests verify that each component is functioning within
certain conditions (for example, whether database connections are near maximum on the
Data Access Engine).
The System Diagnosis tool tests the following components:
Data Access Engine
Software Repository
Command Engine
Server Agents on SA Core servers
Model Repository Multimaster Component
The System Diagnosis tool does not test the Build Manager.
When using the System Diagnosis function in an environment with multiple facilities,
System Diagnosis can only be run on one facility at a time.
Data Access Engine Tests
The following section describes two types of Data Access Engine diagnostic tests:
Standalone and comprehensive.
Standalone Tests
Check for the current Data Access Engine version.
Check for the current Model Repository database version.
Obtain a Device object.
Obtain a MegaDevice object.
145
Verifies advanced query functioning.
Verify a Device object.
Obtain the list of facilities.
Obtain the names of the Data Access Engine cronbot jobs.
Check whether the usage of database connections is below the acceptable level.
Check whether any database connection has been open more than 600 seconds.
Check whether the Data Access Engine and Model Repository are in the same facility.
Verify that all Model Repository garbage-collectors are running when the Model
Repository is running in multimaster mode.
If the Data Access Engine is configured as the central multimaster Data Access Engine:
Check whether multimaster transactions are being published.
Check whether multimaster transactions are showing up at remote facilities.
Check for multimaster transaction conflicts.
Comprehensive Tests
Test connectivity to the Model Repository on the configured port.
Test connectivity to the Command Engine on the configured port.
Test connectivity to the Software Repository on the configured port.
Errors Caused By Additional Database Privileges
If an additional privilege (permission) has been made manually to the Oracle database
(Model Repository), the following error message might appear:
Test Results: The following tables differ between the Data
Access Engine and the Model Repository: facilities.
To fix this problem, revoke the database grant. For instructions, see Troubleshooting
System Diagnosis Errors in the SA Planning and Installation Guide.
Software Repository Tests
The following section describes two types of Software Repository diagnostic tests: stand
alone and comprehensive.
Standalone Tests
None.
146
Comprehensive Tests
Test whether a file that is not a package can be uploaded to the Software Repository
process that serves encrypted files. This test verifies whether the file is present in the
Software Repository file system and that the file size matches the source.
Verify that a file can be downloaded from the Software Repository.
Verify whether the Software Repository process that serves unencrypted files is running
and serving files.
Try to download a file without encryption.
Verify that a package can be uploaded to the Software Repository and that the
package is registered with the Model Repository.
Verify that a package can be deleted from the Software Repository and removed from
the Model Repository.
Web Services Data Access Tests
The following section describes two types of Web Services Data Access diagnostic tests:
Standalone and comprehensive.
Standalone Tests
Connect to the Web Services Data Access Engine and retrieve its version information.
Comprehensive Tests
Connect to the Web Services Data Access Engine.
Read a server record from the Model Repository and thereby check connectivity to the
Model Repository.
Command Engine Tests
The following section describes two types of Command Engine diagnostic tests: stand
alone and comprehensive.
Standalone Tests
Check the state machine.
Check session tables.
Check lock-down status.
Check for signature failures.
147
Check command and service tables.
Check the facility cache.
Comprehensive Tests
Check Data Access Engine connectivity.
Check security signatures.
Check lock operation.
Run an internal script.
Run an external script.
Model Repository Multimaster Component Tests
The following section describes two types of Model Repository Multimaster Component
diagnostic tests: stand alone and comprehensive.
Standalone Tests
Check the ledger state by examining the ledger file.
Report the total number of messages sent, number of messages still in the ledger file
(for example, not confirmed by all listeners), and the sequence number of the last
message confirmed by each listener.
Check the sender health by examining the state of the Outbound Model Repository
Check the receiver health by examining the state of the Inbound Model Repository
Comprehensive Tests
None.
Running a System Diagnosis of SA Core Components
To access the System Diagnosis tool, your user must belong to the Administrators group.
The SAS Web Client has access to all the Server Agents running on the SA Core
Component servers.
148
Perform the following steps to run a system diagnosis of the SA Core Components:
1 From the navigation panel, click Administration System Diagnosis. The System
Diagnosis: Begin Diagnosis page appears.
2 Select the components that you want to test. By default, all components are selected
(the Data Access Engine, the Software Repository, Command Engine, and Web
Services Data Access Engine; in multiple core environments, there is also a selection
for the Model Repository Multimaster Component). See Figure 5-1.
Figure 5-1: System Diagnosis Page Showing SA Components Selected for Testing
3 Click Run Diagnosis.
The System Diagnosis: Performing Diagnosis window appears, which displays a
progress bar while the tests are running, as Figure 5-2 shows.
Figure 5-2: System Diagnosis Progress Bar
149
When all the tests are complete, the window closes and the System Diagnosis:
Failed Tests page appears in the main SAS Web Client window. If all tests passed,
the System Diagnosis: Successful Tests page appears.
4 To review the results of a test, click the linked test name in the Test column. The
System Diagnosis: Test Information page appears. If the test contained an error, error
information appears at the bottom of the page.
The Health Check Monitor for an SA Core
The Health Check Monitor (HCM) includes a suite of tests to check the state of an SA
Core. You can run the HCM on SA version 6.0.2 or greater. The scripts that comprise the
HCM are installed by the HP BSA Installer. There is some overlap between the HCM
documented in this section and the System Diagnosis Tool described in SA Diagnosis
on page 142.
The HCM has two types of tests:
Local Tests: Validate the health of a core on a component-by-component basis.
Global Tests: Validate the health of a core on a holistic basis.
Overview of HCM Local Tests
The HCM local tests validate individual core components. The local tests reside on the
same server as the components they validate. You run local tests by running the SA Start
script (/etc/init.d/opsware-sas) and specifying the test modes and optional
component names. The mode determines which set of tests to run. (You cannot specify
individual tests.) Each test is run only once, even if you specify multiple components that
require the same test. The test results are displayed on stdout.
Validating Core Components by Running HCM Local Tests
To run the local tests, perform the following steps:
1 Log on as root to the server running the SA Core Components that you want to
check.
2 Use the status command. Specify the mode (test category) and one or more
components. (See the next section for the command options.) For example, the
following verifies that the Web Services Data Access Engine is available.
/etc/init.d/opsware-sas status twist
150
Syntax of the Script for HCM Local Tests
The script that runs HCM local tests has the following syntax:
/etc/init.d/opsware-sas <mode> [<component>[<component>...]]
[<name>=<value>[<name>=<value>]...]
Table 5-1 describes the options for this syntax. For a description of the opsware-sas
options for starting and stopping a core, see Table 5-6.
Table 5-1: Options for the HCM Local Test Script
OPTION DESCRIPTION
mode The category of tests to run. The mode can be one of the
following strings:
status: Runs tests that verify the availability of the
specified components. For example, the tests verify that
the components are listening on the correct ports and
responding to basic queries.
verify_post: Same as status.
verify_pre: Runs tests that validate the conditions
necessary for the specified components to operate.
verify_functionality: Runs tests that are similar to
the tests run by the status mode; however, they might
take longer to run. Therefore, you might choose to skip
these tests to save time.
health: Runs the tests of the status, verify_pre,
and verify_functionality modes and provides an
overview of the overall state of the specified components.
component The internal name of the core component. If this option is
not specified, then all components are validated. To view the
internal names of the components installed on the local
server, enter the following command:
/etc/init.d/opsware-sas list
151
Overview of HCM Global Tests
A global HCM test checks an entire SA Core. You run these tests by executing the run_
all_probes.sh script on the following hosts:
Sliced configuration the server hosting the cores Management Gateway and/or
Infrastructure Component (in a Typical Install, the Management Gateway is installed on
the server that hosts the Infrastructure Component).
name=value Options that control how the tests are run. Allowed values:
terse=[true|false]: If true, summarizes the
results of all successful tests for each component in a
single SUCCESS message; however, the results of failed
tests are displayed individually. By default, this option is
set to false. (This option is passed to the individual
tests.)
parsable=[true|false]: If true, summarizes the
results from all tests for each component with a single
SUCCESS or FAILURE message. By default, this option is
set to false. (This option is passed to the individual
tests.)
verify_filter=<regex>: Runs only the tests whose
file names match the regular expression you enter. For
example, specifying verify_filter="OPSW" runs
only tests with file names that contain the string OPSW,
such as 100_OPSWcheck_host_spin.sh. By default,
this option is not defined. (This option is not passed to the
individual tests.)
If a given test is a symbolic link to another file, the filter will
be evaluated against the target of the symbolic link, not
the name of the symbolic link. If the test is a symbolic link,
verify_filter uses the file name of the file it is
pointing to for comparisons.
Table 5-1: Options for the HCM Local Test Script (continued)
OPTION DESCRIPTION
152
Non-sliced configuration the server hosting the Primary Model repository
Multimaster Component for the core being validated.
Test results are displayed on stdout. The global tests cannot check the status of other
cores in a multimaster mesh.
In a multi-server core, the global tests connect to the other core servers using SSH. All
connections are made as root. Authentication is performed by specifying the root
password or the key file on the command line. If both are specified, then the root
password is used. One of these authentication methods must be specified unless the
server is the local host.
Validating a Core By Running HCM Global Tests
To run the HCM global tests, perform the following steps:
1 Log in as root to the server that hosts the Model Repository Multimaster
Component and/or the Infrastructure Component.
2 Execute the run_all_probes.sh script with the run option. (See the following
section for details on the options.) For example, to check the tablespace usage in the
Oracle database of the Model Repository, enter the following command:
/opt/opsware/oi_util/bin/run_all_probes.sh run \
check_database_tables
Syntax of the Script for HCM Global Tests
The script that runs HCM global tests has the following syntax:
/opt/opsware/oi_util/bin/run_all_probes.sh run|list
[<test> [<test>...]
[hosts="<system>[:<password>] [<system>[:<password>]]..."
[keyfile=<keyfiletype>:<keyfile>[:<passphrase>]]
Table 5-2 describes the options for this syntax.
Table 5-2: Options for the HCM Global Test Script
OPTION DESCRIPTION
list Lists the available tests.
run Runs the specified tests.
153
test The name of the test to run. If no tests are specified, all tests
are run. When shipped, the script includes the following
tests:
check_opsware_services: Runs the local tests on all
specified servers by running the following command
remotely on each core server:
/etc/init.d/opsware-sas health
check_MM_state: For a multimaster source core,
checks the multimaster state of the core.
check_time: In a multi-server core, verifies that the
system clocks are in sync across core servers.
check_opsware_version: Validates that the versions
of all the components in the core are the same version.
check_database_tables: Validates that the Model
Repository tablespace usage is within acceptable limits.
For more information on tablespaces, see Oracle Setup
for Model Repository in the SA Planning and Installation
Guide.
check_OS_resources: Validates whether the virtual
memory and disk space on SA partitions is within
acceptable thresholds.
system:password Specifies a remote core server (host name or IP address)
and optional root password for the server.
keyfiletype Specifies the type of key file to use. Allowed values:
rsa_key_file
dsa_key_file.
keyfile Specifies the file containing the current server's SSH private
key.
passphrase Specifies the passphrase that was used to encrypt the
SSH private key.
Table 5-2: Options for the HCM Global Test Script (continued)
OPTION DESCRIPTION
154
Setting up Passwordless SSH for Global Tests
The global tests access remote servers in a core through the SSH daemon. These tests
require you to supply root passwords or to use SSH public/private keys.
To set up authentication using public/private keys generated by ssh-keygen, perform
the following steps:
1 Run the following commands on the trusted server and accept the defaults. The
commands are different for Linux and Solaris.
Linux:
cd /root/.ssh
ssh-keygen -t dsa
Solaris:
cd /.ssh
ssh-keygen -t dsa
2 Update the client server by copying the id_dsa.pub file to the client server's .ssh
directory and then renaming it to authorized_keys. Here are some example
commands for Linux and Solaris:
Linux:
scp id_dsa.pub <host>:/.ssh/authorized_keys
/root/.ssh/authorized_keys
Solaris:
scp id_dsa.pub <host>:/.ssh/authorized_keys
/.ssh/authorized_keys
3 Verify the trusted server. Run the following command to validate that the trusted
server can connect to the client server without a password:
ssh -l root <host>
155
Extensibility of the Health Check Monitor
This section is intended for advanced system administrators with experience in Unix shell
programming and SA administration.
The Health Check Monitor (HCM) is implemented as a series of Unix shell scripts that
perform local or global tests on the core servers. The scripts conform to specific naming
conventions and reside in pre-defined directories. You can extend the HCM by writing
your own scripts and copying them to the correct directories under
/opt/opsware/oi_util.
Requirements for Extensions to HCM Local Tests
An HCM local test is a script that is run by the /etc/init.d/opsware-sas script.
(See Validating Core Components by Running HCM Local Tests on page 149.) A local
test script must meet the following requirements:
Unix Shell Script: It is a Unix shell script that runs as root.
Component Server: The script resides and runs on the server of the component
validated by the script. For example, if the script validates the Data Access Engine
(spin), it resides on the server that runs the Data Access Engine.
Executable: The script is an executable file (chmod u+x).
File Name: The file name of the script has the following syntax:
<int><test>.sh
In this syntax, int is an integer that specifies the test execution order and test is the
name of the test. Note that the HCM scripts provided with SA contain OPSW in the script
file name; for example, 100_OPSWportping.sh.
Directory: The script resides in the following directory:
/opt/opsware/oi_util/local_probes/<component>/[verify_pre |
verify_post | verify_functionality]/
In this path, component is the internal name of the core component, such as spin or
twist. The directories beneath the component directory match the category of the
test. For example, if the test performs a runtime validation on a core component, the
script resides in the verify_functionality subdirectory. For details, see
Categories and Local Test Directories on page 157.
The directories beneath the component directory map to the mode options of the
/etc/init.d/opsware-sas command. For example, if you save a script in the
156
verify_pre subdirectory, the script is executed when you run opsware-sas with
the verify_pre option. If you specify the health option of opsware-sas, the
scripts in all three directories are executed. The following table describes the mapping
between the directory names and the mode options.
Exit Code: The script returns an exit code of zero to indicate success or non-zero for
failure. The /etc/init.d/opsware-sas command uses the exit code to determine
the status for the test.
Results Displayed: The script displays test results on stdout.
Local Preamble Script: The test script runs the local_probe_preamble.sh
script, as shown by HCM Local Test Example on page 158. The local_probe_
preamble.sh script contains a superset of the libraries and shell variables used by
the /etc/init.d/opsware-sas command.
The local_probe_preamble.sh script performs the following tasks:
Sets shell variables used by the local tests. For example, it sets $PYTHON (which
points to the Python 1.5.2 interpreter) and $UTILS_DIR (which points to the
directory of utilities available to the tests).
Parses the command line, evaluates all name=value pairs, and sets shell variables.
For example, if you specify timeout=60 on the command line when running /etc/
init.d/opsware-sas, the local_probe_preamble.sh script sets the
variable $timeout to the value 60.
Table 5-3: Modes of opsware-sas and the Subdirectories of Local Test Scripts
MODE OPTION OF
COMMAND LINE
SUBDIRECTORY OF SCRIPTS RUN FOR
THIS OPTION
health verify_pre
verify_post
verify_functionality
status verify_post
verify_functionality verify_functionality
verify_post verify_post
verify_pre verify_pre
157
Provides access to useful functions such as retry, which executes a command
multiple times until it succeeds or exceeds the specified timeout.
Shell Variables: The test script takes into account the variables specified by the
name=value options on the command line. For a list of pre-defined names, see the
name=value option in Table 5-1.
Categories and Local Test Directories
The /opt/opsware/oi_util directory has the following subdirectories.
local_probes/<component>/verify_pre
This directory includes prerequisite tests for each component. These tests validate that
the necessary conditions exist for the component to operate. For example, the directory
twist/verify_pre contains the test script 10check_localhost_spin.sh
because the Data Access Engine component must be available for the Web Services
Data Access Engine component to function.
local_probes/<component>/verify_post
This directory includes validation tests for each component. These tests verify that a given
component is available. For example, the directory spin/verify_post contains the
test script 10check_primary_spin.sh to validate that the Data Access Engine
component is listening on port 1004 and responds to basic queries.
local_probes/<component>/verify_functionality
This directory includes runtime validation tests for each component. These tests verify that
a component is fully operational. They are similar to verify_post tests, however, they
might take longer to run; therefore, you might choose to skip these tests to save time.
Directory Layout for HCM Local Tests
The following directory layout shows where the local tests reside:
/opt/opsware/oi_util/
|
|_lib
| |_local_probe_preamble.sh
|
|_local_probes
|
|_COMMON
| |_<test>
| |_ ...
158
|
|_<component>
| |
| |_verify_pre
| | |_ <int><test> (can be symlink to ../../COMMON/<test>)
| | |_ ...
| |
| |_verify_post
| | |_ <int><test> (can be symlink to ../../COMMON/<test>)
| | |_ ...
| |
| |_verify_functionality
| |_<int><test> (can be symlink to ../../COMMON/<test>)
| |_...
|
|_<component>
...
HCM Local Test Example
The following script verifies that the cron utility is running on the local server.
#!/bin/sh
# Verify that cron is running
# Read in our libraries / standard variable settings and parse
# the command line.
/opt/opsware/oi_util/lib/local_probe_preamble.sh
printf "Verify \"cron\" is running:"
process_running=`ps -eo fname | egrep '^cron$' | head -1`
if [ -z "$process_running" ]; then
echo "FAILURE (cron does not exist in the process table)"
exit 1
else
echo "SUCCESS"
exit 0
fi
Requirements for Extensions to HCM Global Tests
An HCM global test is a script invoked by the run_global_probes.sh command.
(See Validating a Core By Running HCM Global Tests on page 152.) A global test script
must meet the following requirements:
Unix Shell Script: It is a Unix shell script that runs as root.
Model Repository Server: The script resides on the Model Repository Server but it can
run remotely on any core server.
159
Executable: The script is an executable file (chmod u+x).
File Name: The file name of the script has the following syntax:
<int><test>.sh[.remote]
In this syntax, int is an integer that specifies the test execution order and test is the
name of the test specified on the command line. Note that the HCM scripts provided
with SA contain OPSW in the script file name; for example,
300_OPSWcheck_time.sh.
Remote Execution: If the test script runs on a core server other than those described
in Overview of HCM Global Tests on page 151, then the file name must have the
.remote extension. When you execute run_all_probes.sh and specify such a
test, the script is automatically copied to all specified servers and executed remotely
with the SSH protocol.
The .remote file name extension is not required for tests that run on the same server
as the Model Repository. Multimaster Component (in non-sliced installations) or the
Management Gateway/Infrastructure Component (in Sliced installations). Examples of
these tests are the checks for Model Repository integrity and mulitmaster conflicts. If
the script does not have the .remote extension and it needs to communicate with
remote servers, the script must use SSH. The global preamble script includes helper
functions for handing remote communications with SSH.
Directory: The script resides in the following directory:
/opt/opsware/oi_util/global_probes/[verify_pre | verify_post ]/
For details, see HCM Global Test Directories on page 161.
Exit Code: The script returns an exit code of zero to indicate success or non-zero for
failure. The run_global_probes.sh command uses the exit code to determine the
status for the test.
Results Displayed: The script displays test results on stdout.
Global Preamble Script: The test script runs the global_probe_preamble.sh
script, as shown by HCM Global Test Example on page 160. The global_probe_
preamble.sh script contains a superset of the libraries and shell variables used by
the HCM global tests.
The global_probe_preamble.sh script performs the following tasks:
Sets shell variables used by the tests.
160
Parses the command line and evaluates all name=value pairs, setting them as shell
variables. For example, if you specify hosts="sys1:pw1 sys2:pw2" on the
command line with run_all_probes.sh, the global_probe_preamble.sh
script sets the variable $hosts to the value "sys1:pw1 sys2:pw2".
Provides access to the following functions:
copy_and_run_on_multiple_hosts: Copies and executes a shell script on
multiple remote servers.
copy_from_remote: Copies a file from a remote server.
copy_to_remote: Copies a file to a remote server.
run_on_multiple_hosts: Runs an existing command on multiple servers.
run_on_single_host: Runs an existing command on a single server.
Shell Variables: The test script takes into account the shell variables specified by the
name=value options on the command line.
Authentication: The script sets up authentication or public/private key generation. See
Setting up Passwordless SSH for Global Tests on page 154.
HCM Global Test Example
The following script checks the free disk space of the file systems used by SA. This script
runs on the core servers specified by the hosts option of the run_all_probes.sh
command.
# Check for freespace percentage on Opsware SAS filesystems
# Read in our libraries, standard variable settings, and parse
# the command line.
/opt/opsware/oi_util/lib/global_probe_preamble.sh
MAX_PERCENTAGE=80
for filesystem in /opt/opsware /var/opt/opsware \
/var/log/opsware; do
# The leading and trailing spaces in the following printf
# are to improve readability.
printf " Checking $filesystem: "
percent_free=`df -k $filesystem 2> /dev/null | \
grep -v Filesystem | \
awk '{print $5}' | \
sed 's/%//'`
if [ $percent_free -ge $MAX_PERCENTAGE ] ; then
echo "FAILURE (percent freespace > $MAX_PERCENTAGE)"
exit_code=1
else
161
echo "SUCCESS"
exit_code=0
fi
done
exit $exit_code
Directory Layout for HCM Global Tests:
The following directory layout shows where the global tests reside.
/opt/opsware/oi_util/
|_bin
| |_run_all_probes.sh
| |_remote_host.py
| |_<support_utility>
| |_...
| |_lib
| |_global_probe_preamble
|
|_global_probes
|
|_verify_pre
| |_<int><probe>.remote
|
|_verify_post
|_int<probe>[.remote]
|_ ...
HCM Global Test Directories
The /opt/opsware/oi_util directory has the following subdirectories.
global_probes/verify_pre
This directory includes tests that determine whether the specified servers are core
servers. When a global test in this category determines that a server is not running an SA
component or the server is unreachable, no further tests are run against that server.
Only tests with a .remote extension are allowed under the verify_pre directory.
global_probes/verify_post
This directory includes tests to determine the state of a specific aspect of the entire core.
For example, the directory includes the 600_OPSWcheck_OS_resources
.sh.remote script, which checks resources such as virtual memory and disk space.
162
Logs for SA Components
SA components record events in log files that are useful for troubleshooting. To view a log
file, in a terminal window log into the server running the component and use a command-
line utility such as more, grep, or vi.
The log file for a component resides on the server where the component is installed.
By default, the logging debug levels are configured for the highest value (indicating higher
priority). The default for the maximum log file size is 10 MB. When the specified maximum
file size is reached, additional logs are created. To change the log levels or file sizes,
contact your support representative for assistance.
Boot Server Logs
The Boot Server does not generate its own logs. The Boot Server uses these services:
TFTP with INETD, NFS server, and ISC DHCPD. All of these services log with syslog.
Consult your vendor documentation for more information. See also the syslog.conf file
that was used to configure the Boot Server to determine how the logging has been
configured for this component.
Build Manager Logs
These logs are in the following file:
/var/log/opsware/buildmgr/buildmgr.log
Command Engine Logs
These logs are in the following files:
/var/log/opsware/waybot/waybot.err*
/var/log/opsware/waybot/waybot.log*
Data Access Engine Logs
/var/log/opsware/spin/spin.err*
/var/log/opsware/spin/spin.log*
163
In a core with multiple Data Access Engines, each server running an engine has a set of
these log files.
Media Server Logs
/var/log/opsware/samba/log.smbd
/var/log/opsware/samba/log.nmbd
Solaris and Linux OS provisioning use of vendor-provided services such as NFSD. These
services typically log through syslog. Consult your vendor documentation for more
information on these log files.
Model Repository Logs
The Model Repository is an Oracle database. The location logs the database is specific to
your installation. For more information, see the Monitoring Oracle Log Files section in the
SA Planning and Installation Guide.
Model Repository Multimaster Component Logs
/var/log/opsware/vault/err*
/var/log/opsware/vault/vault.log.*
/var/log/opsware/rvrd/rvrdlog*
To configure the log file name, log file size, or logging level, in the SAS Web Client, go to
Administration System Configuration Model Repository Multimaster Component.
Agents Logs
The Agents create the following log files on managed servers.
Unix:
/var/log/opsware/agent/agent.log*
/var/log/opsware/agent/agent.err*
Windows:
%ProgramFiles%Common Files\opsware\log\agent\agent.log*
%ProgramFiles%Common Files\opsware\log\agent\agent.err*
164
SAS Web Client Logs
The SAS Web Client does not generate its own logs. The SAS Web Client uses JBoss
server, which writes to the following log files:
/var/log/opsware/occ/server.log*
/var/log/opsware/httpsProxy/*log*
Software Repository Logs
/var/log/opsware/mm_wordbot/wordbot.err*
/var/log/opsware/mm_wordbot/wordbot.log*
/var/log/opsware/mm_wordbot-clear/wordbot-clear.err*
/var/log/opsware/mm_wordbot-clear/wordbot-clear.log*
Software Repository Replicator Logs
/var/log/opsware/replicator/replicator.err*
/var/log/opsware/replicator/daemonbot.out
/var/log/opsware/replicator/replicator.log*
Web Services Data Access Engine Logs
The Web Services Data Access Engine contains the following log files:
/var/log/opsware/twist/stdout.log*
/var/log/opsware/twist/twist.log
/var/log/opsware/twist/access.log
/var/log/opsware/twist/server.log*
/var/log/opsware/twist/boot.log
/var/log/opsware/twist/watchdog.log
The stdout.log file contains debug output and logging of every exception that the
server generates. The file does not conform to a specific format. * indicates the files are
1og.1, log.2, log.3, and so forth. The number of files and the size of each file can both be
configured via twist.conf. Additional logs are created when the specified maximum file
size is reached. The stdout.log is the most recent, and stdout.log.1 through 5 are
progressively older files. The file is also rotated on startup. This file also contains the
output of any System.out.println(), System.err.println() and e.printStackTrace() statements.
The twist.log file contains JBoss-specific error or informational messages and
Weblogic specific messages. These files are rotated on startup.
165
The access.log file contains access information in common log format. These files are
rotated when the file reaches 5MB in size.
The server.log file contains debug messages generated from the Web Services Data
Access Engine. The debug messages are controlled by the log level set at the package or
class level in the twist.conf file. * indicates the files are 1og.1, log.2, log.3, and so forth. The
number of files and the size of each file can both be configured via twist.conf. The
server.log.0 is always the current file, while server.log.9 is the oldest.
The boot.log file contains information on the initial stdout and stderr messages generated
when the Web Services Data Access engine starts In addition, the boot.log file contains
the output from Kill QUIT commands.
The watchdog.log file records the status of the Web Services Data Access Engine once
every minute.
Gateway Logs
/var/log/opsware/gateway-name/opswgw.log*
Global File System Logs
/var/log/opsware/hub/OPSWhub.log*
/var/log/opsware/ogfs/ogsh.err*
/var/log/opsware/adapter/adapter.err*
/var/log/opsware/agentcache/agentcache.log
/var/log/opsware/spoke/spoke-*.log
/var/log/opsware/spoke/stdout.log
HTTPS Server Proxy Logs
These logs are found in:
/cust/apache/servers/https-Proxy/logs
The log file ssl_request_log can grow quite large and should be inspected if you are
concerned about disk space availability.
166
Global Shell Audit Logs
When a user accesses or modifies a managed server with the Global Shell feature, SA
records the event in an audit log. The Global Shell audit logs contain information about
the following events:
Logins and logouts with Global Shell and Remote Terminal sessions
The commands entered in Global Shell and Remote Terminal sessions
File system operations (such as create and remove) on managed servers
Commands and scripts that run on managed servers through the Remote Shell (rosh)
The Global Shell audit logs are on the server where the Global File System (OGFS) is
installed.
To view a log file, open a terminal window, log into the server running the OGFS, and use
a command-line utility such as more, grep, or tail. For an example that uses the tail
command, see Example of Monitoring Global Shell Audit Logs on page 168.
The Global Shell audit logs are made up of three sets of logs files:
Shell event logs
Shell stream logs
Shell script logs
Shell Event Logs
The shell event logs contain information about operations that users have performed on
managed servers with the Global Shell. These logs are in the following directory (where
ogfs-host is the name of the server running the OGFS):
/var/opt/opsware/ogfs/mnt/audit/event/ogfs-host
The log file name has the following syntax (where n is the log rotation number):
audit.log.n
For each event, SA writes a single line to an event log file. Each line in the log file contains
the following information about the event:
Unique ID of the event
167
Unique ID of the parent event
Date of the operation
ID of the SA user who performed the operation
Name of the SA user who performed the operation
Name of the component that generated the audit event
Version of the SA component that generated the audit event
Name of the SA feature which generated the audit event
Name of the operation (action)
Verbosity level
Exit status of the event
ID of the managed server
Name of the managed server
Details of the event
The following example shows a single line in an audit event log file:
jdoe@m185:051202182224813:13 jdoe@m185:051202182224790:12
2006/01/28-12:40:19.622 User.Id=2610003 User.Name=jdoe
Hub:1.1 GlobalShell AgentRunTrustedScript 1 OK
Device.Id=10003 Device.Name=m192.dev.opsware.com
ConnectMethod=PUSH RemotePath= RemoteUser=root
ScriptName=__global__.sc_snapshot.sh
ScriptVersion=30b.2.1572 ChangeTime=1128971572
RemoteErrorName=
In this example, the first field is the ID of the event:
jdoe@m185:051202182224813:13
This ID field has the following syntax:
opsware-user@ogfs-host:YYMMDDHHmmssSSS:n
The n at the end of the ID field is a sequence number of the audit event generated in a
session. The ID field matches the name of a shell stream log file.
168
Shell Stream Logs
The shell stream logs contain the stdout of scripts that are run from the Global Shell.
These logs are in the following directory (where ogfs-host is the name of the server
running the OGFS):
/var/opt/opsware/ogfs/mnt/audit/streams/ogfs-host
The log file name has the following syntax:
opsware-user@ogfs-host:YYMMDDHHmmssSSS:n
The log file name matches the ID field in the shell event log. A header line in the log file
contains the file name, character set, version, and SA user name. If the stdout of the
script contains control characters, the shell stream log will contain the same control
characters.
Shell Script Logs
The shell script logs contain the contents of scripts that are run from the Global Shell.
These logs are in the following directory (where ogfs-host is the name of the server
running the OGFS):
/var/opt/opsware/ogfs/mnt/audit/scripts/ogfs-host
The log file name is a hash string based on the script contents, for example:
23f1d546cc657137fa012f78d0adfdd56095c3b5
A header line in the log file contains the file name, character set, version, and SA user
name.
Example of Monitoring Global Shell Audit Logs
The following example monitors the commands entered by an end-user who logs into a
managed server with a Remote Terminal session.
1 In a terminal window, as root, log into the core server running the OGFS. The steps
that follow refer to this window as the auditing window.
2 In the auditing window, go to the audit/event directory:
cd /var/opt/opsware/ogfs/mnt/audit/event/ogfs-host
3 In the SA Client, open a Remote Terminal to a Unix managed server.
4 In the auditing window, examine the last line in the audit.log file:
tail -1 audit.log.n
169
For example, the following entry from the audit.log file indicates that the SA user
jdoe opened a Remote Terminal to the host (Device.Name)
toro.example.com. The event ID is jdoe@m235:060413184452579:59.
jdoe@m235:060413184452595:60 jdoe@m235:060413184452579:59
2006/04/13-18:44:52.728 User.Id=6220044 User.Name=jdoe
Hub:1.1 GlobalShellAgentLogin 1 OK Device.Id=840044
Device.Name=toro.example.com ConnectMethod=JUMP RemotePath=
RemoteUser=root
5 In the auditing window, go to the audit/streams directory:
cd /var/opt/opsware/ogfs/mnt/audit/streams/ogfs-host
6 In the auditing window, use the tail -f command to monitor the file that
corresponds to the Remote Terminal session. The file name is the same as the event
ID. For example, if the event ID is jdoe@m235:060413184452579:59, then you
would enter the following command:
tail -f jdoe*59
7 In the Remote Terminal window, enter some Unix commands such as pwd and ls.
8 Watch the auditing window. The commands (and their output) from the Remote
Terminal session are written to the file in the audit/streams directory.
Digital Signatures in the Global Shell Audit Logs
The shell stream and script log files contain digital signatures and fingerprints, which are
generated with the RSA-SHA1 algorithm. To verify the signature and fingerprint of a log
file, open a terminal window, log into the OGFS, and enter the following command:
/opt/opsware/agentproxy/bin/auditverify stream_file_name \
rsa_key_path
This is an example in bash:
STREAMDIR=/var/opt/opsware/ogfs/mnt/audit/streams/acct.opsw.com
STREAMFILE=jdoe@somehost:051210003000111:61
RSAKEYPATH=/var/opt/opsware/crypto/waybot/waybot.srv
/opt/opsware/agentproxy/bin/auditverify $STREAMDIR/$STREAMFILE
\ $RSAKEYPATH
If the log file has not been tampered with, auditverify displays the following
message:
[AuditVerify]: Verification Result: Valid Signature
By default, the logs are signed with the private key in the following file:
170
/var/opt/opsware/crypto/agent/agent.srv
To change the key file used for signing, modify the audit.signature.key_path parameter in
the System Configuration page of the SAS Web Client. For instructions on accessing the
System Configuration page, see Configuring the Global Shell Audit Logs on page 171.
Storage Management for the Global Shell Audit Logs
By periodically removing the shell stream and script log files, SA prevents these files from
filling up the available disk space. The System Configuration page of the SAS Web Client
contains parameters that determine when the log files are removed. These parameters
enable you to specify the removal of the log files based on the age (archive_days) of the
files or the amount of disk space (archive_size) used by the files.
The following parameters specify the age of the files to remove:
audit.stream.archive_days
audit.script.archive_days
The following parameters specify the amount of disk space that the files can occupy
before they are removed:
audit.stream.archive_size
audit.script.archive_size
For details on these parameters, see Table 5-4. For instructions on accessing the System
Configuration page of the SAS Web Client, see Configuring the Global Shell Audit Logs
on page 171.
Table 5-4: Parameters for Global Shell Audit Log Configuration
PARAMETER DESCRIPTION DEFAULT VALUE
audit.root.dir The root directory for audit
streams and scripts.
/var/opt/opsware/ogfs/
mnt/audit/
audit.script.archive_days Audit script files older than
this value (in days) are
deleted. 0 means files are
never deleted.
100
audit.script.archive_size Maximum amount of disk
space (in MB) used by all
audit script files. Older files
are removed first. 0 means
no maximum.
100
171
Configuring the Global Shell Audit Logs
You can change parameters such as the maximum log file size. For a list of the
parameters, see Table 5-4 on page 170. To configure the parameters, perform the
following steps:
1 In the SAS Web Client, under Administration click the System Configuration link.
2 On the System Configuration: Select Product page, click the hub link.
3 On the System Configuration: Set Configuration Parameters page, you can change
parameters such as audit.root.dir.
4 Click Save.
audit.signature.algorithm Signature algorithm to use
when signing audit streams.
RSA-SHA1
audit.signature.key_path Location of the private key
used when signing audit
streams.
/var/opt/opsware/crypto/
waybot/waybot.srv
audit.stream.archive_days Audit stream files older than
this value (in days) are
deleted. 0 means files are
never deleted.
10
audit.stream.archive_size Maximum amount of disk
space (in MB) used by all
audit stream files. Older files
are removed first. 0 means
no maximum.
1000
audit.stream.file_keep Maximum number of rotated
audit stream files.
50
audit.stream.file_size Maximum file size for audit
streams. Specified in MB.
The largest allowed value is
50MB.
10
Table 5-4: Parameters for Global Shell Audit Log Configuration (continued)
PARAMETER DESCRIPTION DEFAULT VALUE
172
Start Script for SA
SA includes a unified Start script. You can use the Start script to display all SA
components installed on a server, to start, stop, or restart all components installed on a
server, or to start, stop, or restart specific SA components.
When running the script on a core server, the Start script performs the necessary
prerequisite checks for each component installed on the local system.
When an SA core consists of components distributed across multiple servers, the Start
script does not interact directly with remote servers to start or stop components. However,
the Start script can connect to remote servers running SA components and determine
whether prerequisites are met before starting dependent components locally.
When checking prerequisites for components running on remote servers, the Start script
uses timeout values to allow for different boot times and speed differences among
servers. If any of the prerequisite checks fail, the Start script terminates with an error.
The Start script runs in the background when a server running a component reboots; thus,
ensuring that the multiuser boot process will not hang until SA has fully started.
Dependency Checking by the Start Script
The Start script has knowledge of SA component dependencies and starts SA
components in the correct order. The prerequisite checks verify that dependencies are
met before the Start script starts a given component; thus, ensuring that the SA
components installed across multiple servers start in the correct order.
For example, if the component you are attempting to start requires that another
component is running, the Start script can verify whether:
The required components hostname is resolvable
The host on which the required component is running is listening on a given port
Starting the Oracle Database (Model Repository)
SA stores information in the Model Repository, which is an Oracle database. The SA Start
script does not start the Oracle database, which must be up and running before the SA
components can be started. Before you start the SA components, be sure to start the
Oracle listener and database by entering the following command:
/etc/init.d/opsware-oracle start
173
Logging by the Start Script
The Start script writes to the following logs:
Syntax of the Start Script
The SA Start Script has the following syntax:
/etc/init.d/opsware-sas [options] [component1] [component2]...
When you specify specific components to start, stop, or restart, those components must
be installed on the local system and you must enter the names exactly as they are
displayed by the list option. Table 5-6 lists the options for the SA Start script. To see the
options of the Health Check Monitor (HCM) also invoked with opsware-sas, see
Table 5-1.
Table 5-5: Start Script Logging
LOG NOTES
/var/log/opsware/startup When the server boots, the Start script logs
the full text (all text sent to stdout) of the
start process for all SA components
installed on the local system.
stdout When invoked from the command line, the
Start script displays the full text of the start
process for the components.
syslog When the server boots, the Start script runs
as a background process and sends status
messages to the system event logger.
Table 5-6: Options for the SA Start Script
OPTION DESCRIPTION
list Displays all components that are installed on the local
system and managed by the Start script. The Start script
displays the components in the order that they are started.
174
start Starts all components installed on the local system in the
correct order. When you use the start option to start a
specific component, the Start script performs the necessary
prerequisitite checks, then starts the component.
The start option does not start the Oracle database
(Model Repository), which must be up and running before
the SA components can be started.
Some SA components, such as the Web Services Data
Access Engine (twist), can take longer to start. For these
components, you can run the Start script with the start
option so that the Start script runs on the local system as a
background process and logs errors and failed checks to
the components log file.
NOTE: When you use the start option to start multiple
components installed on a server, the Start script will always
run the /etc/init.d/opsware-sas command with the
startsync option.
startsync The startsync option starts all components installed on
the local system in a synchronous mode.
When you use the startsync option, the Start script runs
in the foreground and displays summary messages of its
progress to stdout.
restart Stops and starts all components installed on the local
system in a synchronous mode. First, the Start script stops
all local components in reverse older; then, executes the
startsync option to restart the components in the correct
order.
stop Stops all components installed on the local system in the
correct order.
This option does not stop the Oracle database.
Table 5-6: Options for the SA Start Script (continued) (continued)
OPTION DESCRIPTION
175
Starting an SA Core
To start a core that has been installed on a single server, perform the following steps:
1 Log in as root to the core server.
2 Start the Oracle listener and database for the Model Repository:
3 Start all core components:
/etc/init.d/opsware-sas start
Starting a Multiple-Server SA Core
To start a core that has been installed on multiple servers, perform the following steps:
1 Find out which servers contain which SA core components. To list the components
installed on a particular server, log in to the server as root and enter the following
command:
2 Log in as root to the server with the Model Repository and start the Oracle listener
and database:
3 In the order listed in Details: Start Order for SA Components on page 176, log in as
root to each core server and enter the following command:
/etc/init.d/opsware-sas start
Starting an SA Core Component
You can specify one or more components to start as long as those components are
running on the local system. You must enter the component names exactly as they are
displayed by the list option of the opsware-sas command.
To start individual components of an SA core, perform the following steps:
1 Log in as root to the server that has the component you want to start.
2 (Optional) To list the SA components installed on a server, enter the following
command:
176
3 Enter the following command, wherecomponent is the name as displayed by the
list option:
/etc/init.d/opsware-sas start component
For example, if the list option displayed buildmgr, you would enter the following
command to start the OS Provisioning Build Manager:
/etc/init.d/opsware-sas start buildmgr
Alternatively, you can enter the startsync option when starting a component on a
server. See Table 5-6 on page 173 in this chapter for a description of the startsync
option.
Details: Start Order for SA Components
The Start script starts SA components in the following order. When stopping an SA core,
the components are stopped in the reverse order.
1 opswgw-cgw0-<facility>: The core-side Gateway for the facility in which the
core is running
2 rvrdscript: The RVRD script for TIBCO, which SA uses as part of its multimaster
functionality
3 vaultdaemon: The Model Repository Multimaster Component
4 dhcpd: A component of the OS Provisioning feature
5 spin: The Data Access Engine
6 mm_wordbot: A component of the Software Repository
7 waybot: The Command Engine
8 smb: A component of the OS Provisioning feature
9 twist: The Web Services Data Access Engine
10 buildmgr: The OS Provisioning Build Manager
11 opswgw-agw0-<facility>: The agent-side Gateway for the facility in which the
core is running
12 opswgw-lb: A component of the Gateway
13 sshd: A component of the Global File System
177
14 hub: A component of the Global File System
15 spoke: A component of the Global File System
16 agentcache: A component of the Global File System
17 occ.server: A component of the SAS Web Client
18 httpsProxy: A component of the SAS Web Client
19 opsware-agent: The Agent
SA Software
The SA Software function is populated during SA installation.
Each component of SA is shown by its internal name. You cannot add or delete
components or nodes in this area of SA.
Table 5-7 shows the internal and external names of SA components.
Table 5-7: Internal and External Component Names
INTERNAL NAME EXTERNAL NAME
Agent Agent
buildmgr OS Provisioning Build Manager
hub Global File System
occ SA Command Center
spin Data Access Engine
truth Model Repository
twist Web Services Data Access Engine
vault Model Repository Multimaster Component
way Command Engine
word Software Repository
178
Some of the functionality available in the Server Management area of the system is also
available to be applied to the servers that appear on the Members tab. Take care in
applying changes to the core servers. In particular, do not assign or unassign servers to
these nodes or install or uninstall software or change networking unless directed to do so
during the installation process by the SA Planning and Installation Guide.
To view the servers on which each component is installed, click the components
hyperlinked name, then select the Members tab. The number of servers associated with
that component appears on the tab itself, and detailed information about those servers
shows when you select the tab.
Mass Deletion of Backup Files
SA includes a script that you can run as a cron job for performing mass deletions of
backup files. Backup files are created by configuration tracking. They can accumulate
quickly and take up disk space. Consequently, performance when viewing backup history
in the SAS Web Client can be sluggish, and the information that displays might be
cluttered with out-of-date configuration tracking data.
When the backup deletion script is run, it deletes all backed up files with the exception
that it always keeps one copy of the latest version of every file ever backed up. If you want
to delete those files, use the process for deleting backups individually or a few at a time
that is covered in the SA Users Guide: Server Automation.
The script is called backup_delete.pyc. It is located on the server where the Data
Access Engine resides, in the following directory:
/opt/opsware/spin/util
The script is run using a configuration file that contains the script arguments such as host
name, port number, whether you want full or incremental backups, the backup retention
period, the name of the log file to use, email addresses for notifications, and the email
server to use. See Table 5-8, Configuration File Options, for the arguments, their values,
and their descriptions.
Syntax of Backup Deletion Script
backup_delete.pyc [options]
Usage: backup_delete.py [-c <conf_filename>]
179
Deleting Backup Files with the Mass Deletion Script
Perform the following steps to use the mass deletion script to delete backup files:
1 Log in as root to the server where the Data Access Engine is installed.
2 Make sure that /opt/opsware/pylibs is in your PYTHONPATH environment
variable.
3 Create a file that contains the arguments and values that you want SA to use with the
mass deletion script. See Table 5-8 on page 179, Configuration File Options, for the
available arguments.
For example, the following file specifies that a host called
spin.yourcore.example.com, on port 1004 will have incremental backups that
are three months old deleted. In addition, a log file called run.log, located in /tmp
will be used to capture events, and email will be sent to [email protected] from
[email protected] reporting that the mass deletion was performed
successfully.
host: spin.yourcore.example.com
port: 1004
inc: 1
time: 3m
logfile: /tmp/run.log
emailto: [email protected]
emailserver: smtp.example.com
emailfrom: [email protected]
emailsuccess: 1
Table 5-8: Configuration File Options
ARGUMENTS VALUES DESCRIPTION
host host: [hostname], for
example
host:
spin.yourcore.examp
le.com
Host name of the Data
Access Engine
port port: [port number],
for example
port: 1004
Port of the Data Access
Engine (defaults to 1004)
180
full Set value to 1 to enable, for
example full:1
Delete full backups. You
must specify Either full
or inc.
inc Set value to 1 to enable, for
example inc:1
Delete incremental
backups. You must specify
either full or inc.
time time: [digits][dmy],
for example, 6d equals six
days. 3m equals three
months. 1y equals one
year.
Retention period beyond
which backups should be
deleted.
hostsfile hostsfile:
[filename]
The hostsfile should
contain the name of each
host on a line by itself, for
example
<hostname>
<hostname>
The script deletes backups
on every managed server
in your system, unless you
provide a hostsfile that
contains a specific list of
servers on which to
perform the mass backup
deletion.
logfile logfile: [filename],
for example
logfile: /tmp/
run.log
File to use for log events.
emailto emailto: [email
address], for example
emailto:
[email protected]
Optional email notification
recipient.
emailserver emailserver:
[server name], for
example
emailserver:
smtp.example.com
The SMTP server to send
email through. Optional if
emailto not specified,
otherwise required.
Table 5-8: Configuration File Options (continued)
181
4 Optionally, if you want to run the script as a cron job, create a crontab entry.
For example, to run the job at 3:00 AM daily, create the following entry:
0 3 * * * env PYTHONPATH=/opt/opsware/spin/util/
backup_delete.pyc -c <path>/<your_backup_filename.conf>
The crontab entry must be all on one line.
5 If you do not plan to run the script as a cron job, enter the following command at the
prompt:
# python /opt/opsware/spin/util/backup_delete.pyc\-c /[conf_
filename]
Designations for Multiple Data Access Engines
Overview of Designations for Multiple Data Access Engines
Reassigning the Data Access Engine to a Secondary Role
Designating the Multimaster Central Data Access Engine
Overview of Designations for Multiple Data Access Engines
In a core with multiple instances of the Data Access Engine, each instance may be
designated in one of the following ways:
emailfrom emailfrom: [email
address], for example
emailfrom:
[email protected]
Email address to appear in
the From: line. Optional if
emailto not specified,
otherwise required.
emailsuccess Set value to 1 to enable, for
example
emailsuccess: 1
Send email even if no
errors occurred deleting
backups and more than
one backup was deleted.
Table 5-8: Configuration File Options (continued)
182
Primary Data Access Engine: Each facility has only one primary Data Access Engine.
This Data Access Engine periodically checks the managed servers to determine if SA
can communicate with them. If a facility has more than one primary Data Access
Engine, the competing reachability checks can interfere with each other.
Secondary Data Access Engine: When a facility has multiple Data Access Engines
installed (for scalability), the additional ones are designated secondary. The first Data
Access Engine installed is designated the Primary or Multimaster Central Data Access
Engine. A secondary Data Access Engine does not check managed servers to
determine if they are reachable. It only communicates with the Model Repository write
or read data.
Multimaster Central Data Access Engine: An SA multimaster mesh of cores has only
one multimaster central Data Access Engine. Although any of the cores may have
multiple Data Access Engines, only one engine in the mutilmaster mesh can be the
central engine.
Reassigning the Data Access Engine to a Secondary Role
If you installed an additional Data Access Engine, you must perform the following steps to
reassign the new Data Access Engine to a secondary role:
1 Log into the SAS Web Client as a user that belongs to SA Administrators group.
The SAS Web Client should be installed and listening. The SAS Web Client home
page appears.
2 From the navigation panel, click Administration Opsware Software. The
Software page appears.
3 Click the spin link. The Opsware Software | spin page appears.
4 Select the Members tab. The list of servers that are running the Data Access Engine
in the core appears.
5 Select the check box for the additional Data Access Engine server.
6 From the Tasks menu, select Re-Assign Node.
7 Select the option for the Service Levels | Opsware | spin node.
8 Click Select.
9 Navigate the node hierarchy by clicking the following nodes:
Opsware
183
spin
Secondary
10 Click Re-Assign.
11 In a terminal window, log in as root to the server running the additional Data Access
Engine and enter the following command to restart the Data Access Engine:
/etc/init.d/opsware-sas restart spin
Designating the Multimaster Central Data Access Engine
The HP BSA Installer automatically assigns the multimaster central Data Access Engine.
In most case, you should not change the multimaster central Data Access Engine after
the installation. Doing so can cause problems when upgrading the SA core to a new
version. Before following the steps in this section, contact your support representative
Perform the following steps to designate the multimaster central data access engine:
1 Log into the SAS Web Client as a user that belongs to the SA System Administrators
group.
2 From the Navigation panel, click Opsware Software under Administration. The
Opsware Software page appears.
3 Click the spin link.
4 Select the Servers tab.
5 Select the check box for the Data Access Engine server for the new core.
6 From the Server menu, select Re-Assign Node.
7 Select the option for the Service Levels | Opsware | spin | node.
8 Click Select.
9 Navigate the node hierarchy by clicking each node: Opsware | Spin | Multimaster
Central.
10 Click Re-Assign.
11 Restart the Multimaster Central Data Access Engine.
/etc/init.d/opsware-sas restart spin
184
Web Services Data Access Engine Configuration
Parameters
This section discusses how to change these parameters with the SAS Web Client or by
editing the configuration file. Be sure to restart the Web Services Data Access Engine
after changing the parameters.
Changing a Web Services Data Access Engine Parameter
This section describes how to change the parameters displayed by the SAS Web Client.
However, the SAS Web Client does not list all of the Web Services Data Access Engine
parameters. If you want to change an unlisted parameter, follow the instructions in the
next section.
To change a parameter in the SAS Web Client, perform the following steps:
1 Log into the SAS Web Client as a member of the Administrators group (admin) and
from the navigation panel, click System Configuration under Administration. The
Select a Product page appears.
2 Under Select a Product, click Web Services Data Access Engine.
3 Update the parameters you want to change.
4 Click Save.
5 Restart the Web Services Data Access Engine.
Web Services Data Access Engine Configuration File
The Web Services Data Access Engine configuration file includes properties that affect
the server side of the SA Web Services API 2.2. (These properties are not displayed in the
SAS Web Client.) The fully-qualified name of the configuration file follows:
/etc/opt/opsware/twist/twist.conf
During an upgrade of SA, the twist.conf file is replaced, but the
twistOverrides.conf file is preserved. When you upgrade to a new version of SA, to
retain the configuration settings, you must edit the twistOverrides.conf file. The
properties in twistOverrides.conf override those specified in twist.conf. T Unix
twist user must have write access to the twistOverrides.conf file.
185
To change a property defined in the configuration file:
1 Edit the twist.conf file with a text editor.
2 Save the changed file.
3 Restart the Web Services Data Access Engine on the server.
You must belong to the Administrators group (admin) in order to modify the twist.conf
file. Once the file is changed, the Web Services Data Access Engine must be restarted to
apply the changes.
The following table lists the properties of the configuration file that affect the SA Web
Services API 2.2. Several of these properties are related to the cache (sliding window) of
server events. SA maintains a sliding window (with a default size of two hours) of events
describing changes to SA objects. This window makes enables software developers to
update a client-side cache of objects without having to retrieve all of the objects. For more
information, see the API documentation for EventCacheService.
Table 5-9: Configuration File for SA Web Services API 2.2
PROPERTY DEFAULT DESCRIPTION
twist.webservices.debug
.level
1 An integer value that sets the
debug level for the SA Web
Services API on the server
side. Allowed values:
0 - basic info
1 - more detailed information
2 - stack trace
3 - for printing the server
event cache entries whenever
there is an item added to the
cache.
186
twist.webservices.local
e.country
US The country
Internationalization parameter
for the Localizer utility.
Currently only the US code is
supported.
twist.webservices.local
e.language
en Sets the language
Internationalization parameter
for the Localizer utility.
Currently only the en code is
supported.
twist.webservices.cachi
ng.windowsize
120 In minutes, the size of the
sliding window maintaining
the server event cache.
ng.windowslide
15 In minutes, the sliding scope
for the window maintaining the
server event cache.
ng.safetybuffer
5 In minutes, the safety buffer
for the sliding window
maintaining the server event
cache.
ng.minwindowsize
30 In minutes, the minimum size
of the sliding window that
maintains the server event
cache.
ng.maxwindowsize
240 In minutes, the maximum size
of the sliding window that
maintains the server event
cache.
Table 5-9: Configuration File for SA Web Services API 2.2 (continued)
PROPERTY DEFAULT DESCRIPTION
187
Chapter 6: Monitoring SA
Overview of SA Monitoring
Agent Monitoring
Agent Cache Monitoring
Command Center Monitoring
Load Balancing Gateway Monitoring
Data Access Engine Monitoring
Web Services Data Access Engine Monitoring
Command Engine Monitoring
Software Repository Monitoring
Model Repository Monitoring
Model Repository Multimaster Component Monitoring
TIBCO Monitoring
Global File System Monitoring
Spoke Monitoring
Gateway Monitoring
OS Build Manager Monitoring
OS Boot Server Monitoring
OS Media Server Monitoring
188
Overview of SA Monitoring
SA has a built-in system diagnosis function in the SAS Web Client, which allows you to
diagnosis the functionality of the following SA components:
Data Access Engine
Software Repository
Command Engine
Multimaster Infrastructure Components (referred to as the Model Repository
Multimaster Component in the SA documentation)
This chapter provides information for performing basic monitoring of the components
listed above and for the following additional SA components:
Server Agent
Agent Cache
SAS Web Client
Model Repository
TIBCO
Spoke
Gateways
OS Build Manager
OS Boot Server
OS Media Server
The commands and other information shown in this document are identical to those in
the SAS Web Client.
The information contained in this document should be used when the System Diagnosis
feature cannot be used because the SAS Web Client cannot be reached or when your
managed environment is already set up for automated monitoring. In that case, you can
use these commands to automate your system diagnosis and to monitor SA.
189
The type of monitoring information described in this document includes:
Commands to confirm specific component processes are running as well as examples
of the expected output
Commands provided by component and by operating system
Component specific ports, logs, and administrative URLs
The commands shown in this document must be entered all on one line. However, to
make sure that the commands and the resulting output are readable, they might have
been modified with spaces, blank lines, and line breaks, or backslashes (\) to indicate
where a command has been continued on the following line. Also, the output shown is
intended as an example only. The output on your servers will be different.
For a description of each of the SA components mentioned in this document, see the
Architecture chapter in the SA Planning and Installation Guide.
Agent Monitoring
A Server Agent is an intelligent agent running on each server managed by SA. Whenever
a change needs to be made to a managed server, the Server Agent brokers the requests.
For more information about the Server Agent, see the SA Users Guide: Server
Automation.
To use the SAS Web Client to test an SA Cores communication with a Server Agent
running on a managed server, see the following sections in the SA Users Guide: Server
Automation:
Agent Reachability Communication Tests
Communication Test Troubleshooting
Agent Port
The Server Agent uses port 1002.
190
Monitoring Processes for Agents
On Windows, from the Start menu, choose Run. In the Run dialog, enter taskmgr. In
the Windows Task Manager dialog, click the Process tab and look for the processes
called watchdog.exe and python.exe.
On Unix (Solaris, Linux, AIX, and HP-UX), the Server Agent has two running processes.
On Solaris, execute the command:
# ps -flg `awk -F= '($1=="pgrp") {print $2}' /var/opt/
opsware/agent/daemonbot.pid`
Running this command should produce output similar to the following output:
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
8 S root 9541 9539 0 41 20 ? 1768 ? Aug
08 ? 1:23 /opt
/opsware/agent/bin/python /opt/opsware/agent/pylibs/
shadowbot/daemonbot.pyc --conf /etc/opt/opsware/agent/
agent.args
8 S root 9539 1 0 99 20 ? 398 ? Aug 08 ? 0:00 /opt
/opsware/agent/bin/python /opt/opsware/agent/pylibs/
agent.args
On Linux, execute the command:
1 S root 2538 1 0 85 0 - 3184 wait4 Sep11 ? 00:00:00
/opt/opsware/agent/bin/python /opt/opsware/agent/pylibs/
agent.args
5 S root 2539 2538 0 75 0 - 30890 schedu Sep11 ? 00:02:56
/opt/opsware/agent/bin/python /opt/opsware/agent/pylibs/
agent.args
The daemon monitor is the process with a PPID of 1. The others are server or monitor
threads.
On AIX, execute the command:
191
40001 A root 110600 168026 0 60 20 2000d018 16208 * Sep 05 - 7:15 /opt/
opsware/agent/bin/python /opt/opsware/agent/pylibs/
agent.args
40001 A root 168026 1 0 60 20 2000f25c 1352 Sep 05 - 0:02 /opt/
agent.args
On HP-UX, execute the command:
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME COMD
1 R root 10009 1 0 152 20 437eb1c0 266 - Sep 22 ? 0:00 /opt/
agent.args
1 R root 10010 10009 0 152 20 434fb440 2190 - Sep 22 ? 3:29 /opt/
agent.args
Agent URL
https://<hostname>:1002
Agent Logs
The Server Agents create the following log files on managed servers.
Windows:
%ProgramFiles%Common Files\opsware\log\agent\agent.log*
%ProgramFiles%Common Files\opsware\log\agent\agent.err*
Unix:
/var/log/opsware/agent/agent.log*
/var/log/opsware/agent/agent.err*
Conditions to monitor in the Unix logs:
Strings containing Traceback
Strings containing OpswareError
192
Agent Cache Monitoring
The Agent Cache is a component that serves Server Agent installation files during the
Agent deployment process. The Agent Cache component caches the most recent version
of the Agent that is available. The Discovery and Agent Deployment (ODAD) feature
obtains the agent installation binaries from the Agent Cache component during agent
deployment.
Agent Cache Ports
The Agent Cache uses port 8081.
Monitoring Processes for the Agent Cache
In all configurations, the Agent Cache component has a single running process.
On Solaris or Linux, execute the command on the server running the Gateway (in an SA
core and an Satellite):
# ps auxwww | grep -v grep | grep agentcache
root 22288 0.5 0.1 15920 4464 ? S 19:55 0:08 /opt/opsware/bin/
python /opt/opsware/agentcache/AgentCache.pyc -d /var/opt/
opsware/agent_installers -p 8081 -b
Agent Cache Logs
The Agent Cache logs are in the following files:
/var/log/opsware/agentcache/agentcache.log
/var/log/opsware/agentcache/agentcache.err
Conditions to monitor in the logs:
Strings containing Error downloading agent
Strings containing Another process is listening on port
Command Center Monitoring
The Command Center is a web-based user interface to SA. You use the SAS Web Client
to access the Command Center.
SA users connect to the Command Center component through an Apache HTTPS Proxy
(installed by the HP BSA Installer with the Command Center component).
193
Command Center Ports
The HTTPS Proxy uses port 443 (HTTPS) and port 80 and directs connections to the
Command Center component, which uses port 1031 (the Web Services port).
Monitoring Processes for the Command Center
On Solaris or Linux, execute the command on the server running the Command Center
component:
# ps -eaf | grep -v grep | grep java | grep occ
occ 17373 1 6 19:46 ? 00:02:35 /opt/opsware/j2sdk1.4.2_10/bin/
java -server -Xms256m -Xmx384m -XX:NewRatio=3 -Docc.home=/
opt/opsware/occ -Docc.cfg.dir=/etc/opt/opsware/occ -
Dopsware.deploy.urls=,/opt/opsware/occ/deploy/ -
Djboss.server.name=occ -Djboss.server.home.dir=/opt/
opsware/occ/occ -Djboss.server.
To monitor the Command Center component, you can also set up an automatic
monitoring process to send a URL query (using tools such as Wget) to the Command
Center URL. If the Command Center component returns its login page, it indicates that
both the Apache HTTPS Proxy and Command Center processes are functioning normally.
Command Center URL
https://occ.<data_center>
Command Center Logs
The Command Center does not generate its own logs. The Command Center uses the
JBoss server, which writes to the following log files:
/var/log/opsware/occ/server.log*
/var/log/opsware/httpsProxy/*log*
java.net.ConnectionException
java.net.SocketException
java.lang.NullPointerException
194
Load Balancing Gateway Monitoring
The Load Balancing Gateway provides High Availability and horizontal scaling in an SA
core.
When you run the HP BSA Installer, it installs a Load Balancing Gateway with the
Command Center component.
Load Balancing Gateway Ports
By default, the Load Balancing Gateway uses the port 8080.
Monitoring Processes for the Load Balancing Gateway
In all configurations, the Load Balancing Gateway component has two running process
the Gateway process itself and its watchdog process.
On Solaris or Linux, execute the commands on the server running the Command Center
component:
# ps -eaf | grep -v grep | grep opswgw | grep lb
root 32149 1 0 Sep27 ? 00:00:00 [opswgw-watchdog-2.1.1: lb]
--PropertiesFile /etc/opt/opsware/opswgw-lb/
opswgw.properties --BinPath /opt/opsware/opswgw/bin/opswgw
root 32156 32149 0 Sep27 ? 00:24:31 [opswgw-gateway-2.1.1: lb]
--PropertiesFile /etc/opt/opsware/opswgw-lb/
--Child true
Load Balancing Gateway Logs
The Load Balancing Gateway logs are in the following files:
Strings containing ERROR
Strings containing FATAL (indicates that the process will terminate)
195
Data Access Engine Monitoring
The Data Access Engine simplifies interaction with various clients in SA, such as the
Command Center, system data collection, and monitoring agents on servers.
Data Access Engine Port
The Data Access Engine uses port 1004 (HTTPS) externally and 1007 (the loopback
interface) for SA components installed on the same server.
Multimaster Central Data Access Engine Port Forwarding
SQLnet traffic between the Multimaster Central Data Access Engine in a mesh and the
Model Repositories in other SA Cores in the mesh is routed over the SA Gateway mesh.
The tnsnames.ora file on the server running the Multimaster Central Data Access
Engine points to a specified port on each core-side Gateway in the other SA cores. The
core-side Gateway in the core running the Multimaster Central Data Access Engine
forwards the connection to the core-side Gateway in each other core, which in turn
forwards it to the Model Repositories in the other cores.
The port number on the core-side Gateway is calculated as 20000 + data_center_id. For
example, if the multimaster mesh has two facilities, Facility A (facility ID 1) and Facility B
(facility ID 2), the Multimaster Central Data Access Engine in Facility A connects to port
20002 on the server running the Gateway to reach the Model Repository in Facility B.
For information about the Multimaster Central Data Access Engine, see Designations for
Multiple Data Access Engines on page 181.
For information about the Gateway mesh topology, see the SA Planning and Installation
Guide.
Monitoring Processes for the Data Access Engine
On Solaris, execute the command on the server running the Data Access Engine
component:
# /usr/ucb/ps auxwww | grep -v grep | grep spin | grep -v
java
root 8010 0.5 0.84541631552 ? S 19:36:42 4:56 /opt/opsware/bin/
python /opt/opsware/pylibs/shadowbot/daemonbot.pyc --conf
/etc/opt/opsware/spin/spin.args
root 8008 0.0 0.1 4040 2080 ? S 19:36:42 0:00 /opt/opsware/bin/
196
root 8026 0.0 0.53224018224 ? S 19:36:57 0:01 /opt/opsware/bin/
python /opt/opsware/spin/certgenmain.pyc --start --conf
On Solaris, you see multiple process that look like the first line of the output above;
however, there should be only one process that contains certgenmain in the
output.
On Linux, execute the command on the server running the Data Access Engine
component:
# ps auxwww | grep -v grep | grep spin | grep -v java
root 30202 0.0 0.0 13592 1500 ? S Sep11 0:01 /opt/opsware/bin/
root 30204 1.3 0.6 154928 25316 ? S Sep11 411:15 /opt/opsware/
bin/python /opt/opsware/pylibs/shadowbot/daemonbot.pyc
--conf /etc/opt/opsware/spin/spin.args
bin/python /opt/opsware/spin/certgenmain.pyc --start
--conf /etc/opt/opsware/spin/spin.args
Data Access Engine URLs
https://spin.<data_center>:1004
To access the Data Access Engine (spin) UI, you need the browser certificate
browser.p12.
https://spin.<data_center>:1004/
ObjectBrowser.py?cls=Account&id=0
Accessing the second URL fails when the Model Repository component is not running.
https://spin.<data_center>:1004/sys/dbstatus.py
Accessing this URL shows the database connection status in the HTML page. Your
automatic monitoring system can use a regular expression to extract the number of
active database connections.
Data Access Engine Logs
The Data Access Engine logs are in the following files:
/var/log/opsware/spin/spin.err* (The main Data Access Engine error file)
197
/var/log/opsware/spin/spin.log* (The main Data Access Engine log file)
/var/log/opsware/spin/spin_db.log
/var/log/opsware/spin/daemonbot.out (Output from the application server)
In a core with multiple Data Access Engines, each server running a Data Access Engines
has a set of these log files.
Web Services Data Access Engine Monitoring
The Web Services Data Access Engine provides increased performance to other SA
components.
The Web Services Data Access Engine component is installed as part of the Slice
Component bundle.
Web Services Data Access Engine Port
The Web Services Data Access Engine uses port 1032.
The Command Center component communicate with the Web Services Data Access
Engine on port 1026 (a private loopback port).
Monitoring Processes for the Web Services Data Access Engine
On Solaris, execute the command on the server running the Command Center
component and on the server running the Slice Component bundle:
# /usr/ucb/ps auxwww | grep -v grep | grep \/opt\/opsware\/
twist
twist 9274 0.0 1.416748054040 ? S Aug 08 410:33 /opt/opsware/
j2sdk1.4.2_10/bin/java -server -Xms16m -Xmx128m -
Dtwist.port=1026 ...... -classpath opt/opsware/j2sdk1.4.2_
10/jre ......
twist 9238 0.0 0.1 1088 744 ? S Aug 08 0:00 /bin/sh /opt/
opsware/twist/watchdog.sh start 60
On Linux, execute the command on the server running the Command Center component
and on the server running the Slice Component bundle:
# ps auxwww | grep -v grep | grep \/opt\/opsware\/twist
twist 4039 0.2 11.3 2058528 458816 ? S Sep11 80:51 /opt/opsware/
198
XX:MaxPermSize=192m -
Dorg.apache.commons.logging.Log=org.apache.commons.logging
.impl.Jdk14Logger ......
twist 4704 0.0 0.0 4236 1124 ? S Sep11 1:28 /bin/sh /opt/
opsware/twist/watchdog.sh start 60'
twist 4743 0.0 0.6 376224 27160 ? S Sep11 18:31 /opt/opsware/
Dtwist.port=1026 ...... -classpath /opt/opsware/
j2sdk1.4.2_10/jre/......
Web Services Data Access Engine URL
https://occ.<data_center>:1032
Web Services Data Access Engine Logs
The Web Services Data Access Engine logs are in the following files:
/var/log/opsware/twist/stdout.log*
/var/log/opsware/twist/twist.log
/var/log/opsware/twist/access.log
/var/log/opsware/twist/server.log* (Application level logging)
/var/log/opsware/twist/boot.log
/var/log/opsware/twist/watchdog.log
The stdout.log files contain stdout and stderr and logs the output of any
System.out.println(), System.err.println() and e.printStackTrace()
messages; however, only some of the exceptions will show up in these logs. The number
of files and the size of each file can be configured via twist.conf. Additional logs are
created when the specified maximum file size is reached. The stdout.log is the most
recent, and stdout.log.1 through stdout.log.5 are progressively older files. The
file is also rotated on startup.
The twist.log file contains WebLogic-specific messages and WebLogic level
exceptions. These files are rotated on startup. Monitor the twist.log files for
exceptions that indicate when the Web Services Data Access Engine (Twist) component
failed to start correctly. If errors are encountered during Model Repository (Truth)
connection setup, errors are logged in the twist.log files; for example, you might see
the following error message:
199
####<Oct 14, 2006 1:37:43 AM UTC> <Error> <JDBC> <localhost.localdomain>
<twist> <main> <<WLS Kernel>> <> <BEA-001150> <Connection Pool
"TruthPool" deployment failed with the following error:
<Specific message, such as Oracle error codes and tracebacks>
The access.log file contains access information in common log format. These files are
rotated when the file reaches 5MB in size.
The server.log files contain application level exceptions and debug messages
generated from the Web Services Data Access Engine. The server.log files will also
contain errors resulting from Model Repository (Truth) connection setup problems. The
debug messages are controlled by the log level set at the package or class level in the
twist.conf file. The number of files and the size of each file can both be configured via
twist.conf. The server.log.0 is always the current file, while server.log.9 is
the oldest.
The boot.log file contains information on the initial stdout and stderr messages
generated when the Web Services Data Access Engine starts. In addition, the boot.log
file contains the output from Kill QUIT commands.
The watchdog.log file records the status of the Web Services Data Access Engine
once every minute.
Command Engine Monitoring
The Command Engine is the means by which distributed programs such as Server
Agents run across many servers. Command Engine scripts are written in Python and run
on the Command Engine server. Command Engine scripts can issue commands to
Server Agents. These calls are delivered in a secure manner and are auditable by using
data stored in the Model Repository.
Command Engine Port
The Command Engine uses port 1018.
Monitoring Processes for the Command Engine
On Solaris, execute the command on the server running the Command Engine
component:
# /usr/ucb/ps auxwww | egrep '(COMMAND$|waybot)' | grep -v
grep
200
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
root 1246 0.0 0.1 4040 2064 ? S Sep 24 0:00 /opt/opsware/bin/
/etc/opt/opsware/waybot/waybot.args
root 1248 0.0 0.41596814592 ? S Sep 24 2:19 /opt/opsware/bin/
/etc/opt/opsware/waybot/waybot.args
On Solaris, the Command Engine has two processes one process for the daemon
monitor and one process for the server.
On Linux, execute the command on the server running the Command Engine
component:
# ps auxwww | egrep '(COMMAND$|waybot)' | grep -v grep
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
bin/python /opt/opsware/pylibs/shadowbot/daemonbot.pyc
--conf /etc/opt/opsware/waybot/waybot.args
On Linux servers running kernel 2.4 or later, the Command Engine has one process.
Command Engine URL
https://way.<data_center>:1018
Command Engine Logs
The Command Engine logs are in the following files:
/var/log/opsware/waybot/waybot.err*
/var/log/opsware/waybot/waybot.log*
/var/log/opsware/waybot/daemonbot.out*
Software Repository Monitoring
The Software Repository is where all software managed by SA is stored.
Software Repository Ports
The Software Repository uses the following ports:
1003 (Encrypted)
1006 (Cleartext)
201
1005 (Replicator administrative user interface)
5679 (Multimaster Software Repository)
Monitoring Processes for the Software Repository
On Solaris, execute the command on the server running the Software Repository
component:
# /usr/ucb/ps auxwwww | grep -v grep | grep mm_wordbot
root 8625 0.0 0.1 4048 1912 ? S Aug 08 0:00 /opt/opsware/bin/
/etc/opt/opsware/mm_wordbot/mm_wordbot.args
root 8627 0.0 0.52034418600 ? S Aug 08 7:38 /opt/opsware/bin/
root 8675 0.0 0.1 4032 1904 ? S Aug 08 0:00 /opt/opsware/bin/
/etc/opt/opsware/mm_wordbot/mm_wordbot-clear.args
root 8677 0.0 0.210104 8096 ? S Aug 08 0:01 /opt/opsware/bin/
On Solaris, the Software Repository has four running processes two processes for
the encrypted Software Repository and two for the cleartext Software Repository.
On Linux, execute the command on the server running the Software Repository
component:
# ps auxwwww | grep -v grep | grep mm_wordbot
202
On Linux, the Software Repository has multiple running processes (most are
threads), which are for the encrypted Software Repository and for the cleartext
Software Repository.
Software Repository URL
https://theword.<data_center>:1003
Software Repository Logs
The logs for the Software Repository are in the following files:
/var/log/opsware/mm_wordbot/wordbot.err*
/var/log/opsware/mm_wordbot/wordbot.log*
/var/log/opsware/mm_wordbot-clear/wordbot-clear.err*
/var/log/opsware/mm_wordbot-clear/wordbot-clear.log*
Model Repository Monitoring
The Model Repository is an Oracle database that contains essential information
necessary to build, operate, and maintain a list of all managed servers, their hardware,
their configuration, the operating system and all other applications.
For more information about the Model Repository, including detailed information about
monitoring the Model Repository, see the Oracle Setup for the Model Repository
appendix in the SA Planning and Installation Guide.
Model Repository Port
The default port for the Model Repository is 1521, however, this might have been modified
by the database administrator who installed it.
Monitoring Processes for the Model Repository
Monitor the Oracle Database process. If the process is not found, the database has failed
or was not started.
On Solaris or Linux, execute the command on the server running Oracle:
# ps -fu oracle | grep pmon
oracle 2112 1 0 21:22 ? 00:00:00 ora_pmon_truth
203
(The process name might include the database SID, truth, as shown in this example.)
If the process is not found, the listener has failed or was not started.
On Solaris or Linux, use this command to monitor the Oracle Listener process:
# ps -fu oracle | grep tnslsnr
oracle 2021 1 0 21:22 ? 00:00:01 /u01/app/oracle/
product/10.2.0/db_1/bin/tnslsnr LISTENER -inherit
Model Repository Logs
Log files for the Model Repository are produced by the Oracle database and their location
is specific to your installation.
By default, SA uses a directory for each SID (in this case truth) for the Model Repository
logs. (This could be different based on how Oracle was installed.)
/u01/app/oracle/admin/truth/bdump/alter_truth.log
Conditions to monitor:
Not all errors indicate a problem with the database. Some errors might be caused by an
application.
In these examples, there is a problem if the command has output.
grep ORA- /u01/app/oracle/admin/truth/bdump/alter_truth.log
ORA-00600: internal error code, arguments: [729], [480],
[space leak], [], [], [], [], []
ORA-07445: exception encountered: core dump [lxmcpen()+0]
[SIGSEGV] [Address not mapped to object] ...
Table Space Usage
Tablespace usage should be monitored against a threshold, usually increasing in severity
(for example., over 80% is a warning, over 90% is an error, over 95% is a critical error).
There are several ways to monitor tablespace usage. For a SQL query that you can run to
check for sufficient free disk space in the tablespaces, see the Oracle Setup for the
Model Repository appendix in the SA Planning and Installation Guide. The SQL query
provided in the installation guide must be executed as a privileged database user.
204
Multimaster Conflicts
The number of conflicting transactions in any Model Repository can be found by running
the following SQL query as any SA database user.
select count(*) from transaction_conflicts where resolved = 'N';
Multimaster conflicts should be monitored in stages, with increasing numbers of conflicts
resulting in increasing levels of escalation. The values used for the stages depend on
patterns of use.
The SA administrator should record the number of conflicts for some period of time
(perhaps a week) and use that information to determine the level of alert raised by the
monitoring system.
Model Repository Multimaster Component Monitoring
The Model Repository Multimaster Component is a Java program responsible for keeping
multiple Model Repositories synchronized and propagating changes for the originating
Model Repository to all other Model Repository databases.
Model Repository Multimaster Component Port
The Model Repository Multimaster Component uses port 5678.
Monitoring Processes for the Model Repository Multimaster Component
On Solaris, execute the command on the server running the Model Repository
Multimaster component [the server where you installed the Multimaster Infrastructure
Components (vault) with the HP BSA Installer]:
# /usr/ucb/ps auxwww | grep -v grep | grep vault | grep -v
twist
root 3884 0.0 0.1 2792 1568 ? S Jul 26 0:00 /opt/opsware//bin/
python /opt/opsware//pylibs/shadowbot/etc/daemonizer.pyc
--runpath /var/log/opsware/vault --cmd /opt/opsware/
j2sdk1.4.2_10/bin/java -classpath /opt/opsware/vault
...... -ms120m -mx1024m -DCONF=/etc/opt/opsware/vault/
-DHOSTNAME= com.loudcloud.vault.Vault
root 3885 0.0 0.1 1096 848 ? S Jul 26 0:00 /bin/sh -c /opt/
opsware/j2sdk1.4.2_10/bin/java -classpath /opt/opsware/
vault/cl
root 3887 0.0 3.9194192155784 ? S Jul 26 2:34 /opt/opsware/
205
j2sdk1.4.2_10/bin/java -classpath /opt/opsware/vault
...... -ms120m -mx1024m -DCONF=/etc/opt/opsware/vault/
-DHOSTNAME= com.loudcloud.vault.Vault
On Linux, execute the command on the server running the Model Repository Multimaster
component [the server where you installed the Multimaster Infrastructure Components
(vault) with the HP BSA Installer]:
# ps auxwww | grep -v grep | grep vault | grep -v twist
root 28662 0.0 0.0 2284 532 ? S Sep27 0:00 /opt/opsware//bin/
python /opt/opsware//pylibs/shadowbot/etc/daemonizer.pyc
--runpath /var/opt/opsware/vault --cmd /opt/opsware/
j2sdk1.4.2_10/bin/java -classpath /opt/opsware/vault/
classes:/opt/opsware/vault ...... -ms120m -mx1024m
-DCONF=/etc/opt/opsware/vault/
-DHOSTNAME=m234.dev.opsware.com com.loudcloud.vault.Vault
j2sdk1.4.2_10/bin/java -classpath /opt/opsware/vault/
classes:/opt/opsware/vault ...... -ms120m -mx1024m
-DCONF=/etc/opt/opsware/vault/
-DHOSTNAME=m234.dev.opsware.com com.loudcloud.vault.Vault
Model Repository Multimaster Component Logs
The Model Repository Multimaster Component logs are in the following files:
/var/log/opsware/vault/log.*
Condition to monitor in the logs: The string Traceback
To configure the log file name, log file size, or logging level, in the SAS Web Client, go to
Administration System Configuration Model Repository Multimaster Component.
TIBCO Monitoring
In a multimaster mesh, SA uses the TIBCO Certified Messaging system to synchronize the
Model Repositories in different facilities. The HP BSA Installer automatically installs and
configures TIBCO Rendezvous. By default, the installer configures the Rendezvous
neighbors in a star topology, in which the source core is at the center.
TIBCO traffic between SA Cores is routed over the SA Gateway mesh. Each core contains
a Model Repository with data that is synchronized with the Model Repositories in other
cores. This synchronization data passes through the core Gateways.
206
For information about this topology, the SA Planning and Installation Guide.
For information about TIBCO configuration in a multimaster mesh, see the TIBCO
Rendezvous Configuration for Multimaster appendix in the SA Planning and Installation
Guide.
TIBCO Ports
TIBCO uses the following ports:
7500 for connections to the local network (UDP) [TIBCO Rendezvous daemon (rvd)]
7501 for neighbor connections [TIBCO Rendezvous routing daemon (rvrd)]
7580 for TIBCO Management
The TIBCO Rendezvous routing daemon (rvrd), which listens on port 7501 for neighbor
connections from other SA cores, uses port forwarding through the Gateway mesh to
reach TIBCO neighbors in other SA cores.
The port number on the core-side Gateway is calculated as 10000 + data_center_id_of_
the_neighbor. For example, if the multimaster mesh has two facilities, Facility A (facility ID
1) and Facility B (facility ID 2), the core-side Gateway in Facility A forwards port 10002 and
the core-side Gateway in Facility B forwards port 100001.
Monitoring Processes for TIBCO
On Solaris, execute the command on the server running the Model Repository
component:
# /usr/ucb/ps auxwww | grep -v grep | grep rvrd
nobody4 3831 0.0 0.52469618000 ? S Jul 26 0:01 /opt/opsware/
tibco/bin/rvrd -http 7580 -https 7581 -permanent -store
/var/opt/opsware/rvrd/rvrdstore -logfile /var/log/opsware/
rvrd/rvrdlog
On Linux, execute the command on the server running the Model Repository component:
# ps auxwww | grep -v grep | grep rvrd
65534 18095 0.0 0.5 162032 10468 ? S 16:39 0:04 /opt/opsware/
207
tibco/bin/rvrd -http 7580 -https 7581 -permanent -store
/var/opt/opsware/rvrd/rvrdstore -logfile /var/log/opsware/
rvrd/rvrdlog
Additionally, on the server running the Software Repository component, execute the
commands to monitor TIBCO processes.
On Solaris, execute the command on the server running the Software Repository
component:
# /usr/ucb/ps auxwww | grep -v grep | grep rvd
nobody4 1274 0.0 0.62657610576 ? S Oct 13 0:35 rvd -listen
tcp:7500 -no-permanent
On Linux, execute the command on the server running the Software Repository
component:
# ps auxwww | grep -v grep | grep rvd
65534 8609 0.0 0.3 135024 13708 ? S Oct12 0:29 rvd -listen
When the Web Services Data Access Engine (Twist) component is installed on a server
without the Model Repository Multimaster Component (vault), you must monitor the
TIBCO rvd processes used by the Web Services Data Access Engine (Twist) component.
Within an SA core, TIBCO rvd is used to communicate with the Web Services Data
Access Engine (Twist) running on the other servers and notify it to refresh the data in its
cache after multimaster transactions are published to the Model Repository in the core.
On Solaris, execute the commands on the server running the Command Center (OCC)
component and on the server running the Slice Component bundle):
# /usr/ucb/ps auxwww | grep -v grep | grep rvd
nobody4 1274 0.0 0.62657610576 ? S Oct 13 0:34 rvd -listen
On Linux, execute the commands on the server running the Command Center (OCC)
component and on the server running the Slice Component bundle:
# ps auxwww | grep -v grep | grep rvd
twist 3500 0.0 0.8 137584 17172 ? S Oct13 1:47 rvd -listen
208
TIBCO URL
http://truth.<hostname>:7580 (Displays the TIBCO Rendezvous web client)
Where the <hostname> is the IP address or fully-qualified host name of the server
running the Model Repository Multimaster Component (vault). The TIBCO Rendezvous
General Information page appears.
Additionally, you can use the TIBCO Rendezvous web client to check status, such as
whether a TIBCO Rendezvous Neighbor has connections to an SA facility.
TIBCO Logs
The TIBCO logs are in the following file:
/var/log/opsware/rvrd/rvrdlog
(You can adjust the logging level by using the TIBCO Rendezvous web client.)
Global File System Monitoring
The Global Shell feature is installed as part of any Slice Component bundle, and
dynamically constructs a virtual file system the Global File System (OGFS).
The Global Shell can connect to an Server Agent to open a Unix shell or a Windows
Remote Desktop connection on a managed server.
For information about using the Global Shell, see the Global Shell chapter and
appendices in the SA Users Guide: Server Automation.
The Global File System component consists of the following programs:
Hub: A Java program that interacts with other Core Components and Agents on
Managed Servers (though the Agent Proxy) to compose the file system view.
Adapter: On Linux, a C program that transports file system requests and replies
between the FUSE (a module in the kernel) and the Hub and uses the FUSE userspace
library to communicate with the FUSE kernel module. On Solaris, a Python program that
communicates with a custom kernel module.
Agent Proxy: A Python program that provides the Hub with SSL connectivity to Agents
running on managed servers.
FUSE (Linux Only): A file system in Userspace (FUSE) (software governed by the GNU
GPL license) that provides in-kernel dispatch of file system requests into the Adapter.
209
The process group ID file for the Hub is located in the following directory:
/var/opt/opsware/hub/hub.pgrp
All Global File System programs (Hub, Adapter, Agent Proxy, and their log rotators) run in
this process group.
Monitoring Process for the Global File System
On Solaris, execute the command on the server(s) running the Slice Component bundle:
# ptree $(ps -g $(cat /var/opt/opsware/hub/hub.pgrp) -o
pid=)
7594 /opt/opsware/bin/python /opt/opsware/hub/bin/rotator.py /opt/
opsware/j2sdk1.4.2......
7598 /opt/opsware/j2sdk1.4.2_10/bin/java -server -Xms64m -Xmx1024m
-Dhub.kernel=SunO......
7613 /opt/opsware/bin/python /opt/opsware/adapter/SunOS/bin/rotator.py
/opt/opsware/......
7617 /opt/opsware/ogfsutils/bin/python2.4 /opt/opsware/adapter/
SunOS/lib/adapter.py......
7618 /opt/opsware/adapter/SunOS/bin/mount -o hostpath=
/hostpath,nosuid /dev/ogdrv /v......
7619 /opt/opsware/bin/python /opt/opsware/agentproxy/bin/rotator.pyc
/opt/opsware/bi......
7625 /opt/opsware/bin/python /opt/opsware/agentproxy/lib/
main.pyc......
On Solaris, the OGFS (specifically, the programs Hub, Adapter, and Agent Proxy) has
seven running processes.
On Linux, execute the following command on the server running the Slice Component
bundle.
# ps u -g $(cat /var/opt/opsware/hub/hub.pgrp)
Running this command should produce output similar to the following:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
bin/python /opt/opsware/hub/bin/rotator.py /opt/opsware/
j2sdk1.4.2_10/b......
root 8868 0.1 1.8 1256536 76672 ? S Sep29 35:51 /opt/opsware/j2sdk1.4.2_
10/bin/java -server -Xms64m -Xmx1024m -Dhub.kernel=Linux -
Dh......
210
root 8906 0.0 0.0 2412 1304 ? S Sep29 0:28 /opt/opsware/bin/python /opt/
opsware/adapter/bin/adapter......
root 8908 0.0 0.0 13088 684 ? S Sep29 0:10 /opt/opsware/adapter/Linux/
bin/adapter.bin /var/opt/opsware/ogfs/mnt/ogfs -f -o
none......
root 8913 0.0 0.0 2308 1132 ? S Sep29 0:00 /opt/opsware/bin/python /opt/
opsware/agentproxy/bin/rotator.pyc /opt/opsware/bin/
pyt......
root 8923 0.0 0.1 153120 6544 ? S Sep29 5:56 /opt/opsware/bin/python
/opt/opsware/agentproxy/lib/main.pyc......
On Linux, OGFS (specifically, the programs Hub, Adapter, and Agent Proxy) has six
running processes.
The Global File System also supports a status option to the init script for both Linux
and Solaris.
On Linux or Solaris, execute the following command on the server running the Slice
Component bundle to run this status option:
# /etc/opt/opsware/startup/hub status
Testing for presence of Hub process group file (/var/opt/opsware/hub/
hub.pgrp) ... OK
Testing that processes are running in Hub process group (8862) ... OK
Testing that OGFS is mounted ... OK
Testing that the OGFS authenticate file is present ... OK
OGFS is running
Global File System Logs
The Hub logs are in the following files:
/var/log/opsware/hub/hub.log*
/var/log/opsware/hub/hub.out*
Conditions to monitor in the Hub logs:
Strings containing Cant establish twist connection
The Adapter logs are in the following files:
/var/log/opsware/adapter/adapter.err*
The Agent Proxy logs are in the following files:
/var/log/opsware/agentproxy/agentproxy.err*
211
Monitoring Processes for FUSE (Linux Only)
On Linux, execute the command on the server running the Slice Component bundle:
# lsmod | grep -v grep | grep fuse
fuse 31196 2
FUSE logs messages in the following file:
/var/log/messages
Monitoring Processes for the SunOS Kernel Module
On Solaris, the OGFS functionality relies on the SunOS kernel module.
Execute the command on the server running the Slice Component bundle:
# modinfo | grep -i opsware
137 1322cd8 43a9 272 1 ogdrv (Opsware GFS driver v1.13)
138 13ac227 338df 18 1 ogfs (Opsware Global Filesystem v1.14)
The Global File System logs messages related to SunOS kernel module in the following
file:
/var/adm/messages
Spoke Monitoring
The Spoke is the back-end component of the SA Client. The Spoke, a Java RMI server,
provides access to the files in the Global File System (OGFS) and provides access to run
commands inside an OGFS session.
Spoke Ports
The Spoke uses port 8020.
Monitoring Processes for the Spoke
On Solaris, execute the command on the server running the Slice Component bundle:
# /usr/ucb/ps auxwww | grep -v grep | grep Spoke
212
root 4831 0.1 1.316426451168 pts/1 S Jul 26 167:58 /opt/opsware/
j2sdk1.4.2_10/bin/java -server -Xms32m -Xmx256m
-Dbea.home=/opt/opsware/spoke/etc -Dspoke.home=/opt/
opsware/spoke -Dspoke.cryptodir=/var/opt/opsware/crypto/
spoke -Dspoke.logdir=/var/log/opsware/spoke
-Djava.util.logging.config.file=/opt/opsware/spoke/
etc/logging.bootstrap
-Dweblogic.security.SSL.ignoreHostnameVerification=true
...... -classpath /opt/opsware/spoke/lib/HTTPClient-
hacked.jar: ...... com.opsware.spoke.Spoke
On Linux, execute the command on the server running the Slice Component bundle:
# ps -ef | grep -v grep | grep spoke
root 29191 1 0 Aug28 ? 01:12:11 /opt/opsware/j2sdk1.4.2_10/bin/
java -server -Xms32m -Xmx256m -Dbea.home=/opt/opsware/
spoke/etc -Dspoke.home=/opt/opsware/spoke
-Dspoke.cryptodir=/var/opt/opsware/crypto/spoke
-Dspoke.logdir=/var/log/opsware/spoke
-Djava.util.logging.config.file=/opt/opsware/spoke/etc/
logg
On Linux, the Spoke component has a single, running Java process.
Spoke Logs
The Spoke logs are in the following files:
/var/log/opsware/spoke/spoke-*.log
/var/log/opsware/spoke/stdout.log
Gateway Monitoring
SA Management and Core Gateways allow an SA Core to manage servers that are behind
one or more NAT devices or firewalls. Connectivity between gateways is maintained by
routing messages over persistent TCP tunnels between the gateway instances.
For information about configuring the Gateways, the SA Planning and Installation Guide.
For information about maintaining Satellite Gateways, see Satellite Administration on
page 117.
213
Gateway Ports
By default, the Gateway uses the following ports:
2001 Management Gateway Listener Port
2001 Slice Component Core Gateway Listener Port)
3001 Agent Gateway Port
3001 Satellite Gateway Port
Monitoring Processes for the Gateway
In all configurations, the Gateway component has two running process the Gateway
process itself and its watchdog process.
On Solaris or Linux, execute the commands on the server running the Gateway
component:
# ps -eaf | grep -v grep | grep opswgw | grep cgw
root 17092 1 0 Sep21 ? 00:00:00 [opswgw-watchdog-2.1.1: cgw0-C43]
--PropertiesFile /etc/opt/opsware/opswgw-cgw0-C43/
root 17094 17092 0 Sep21 ? 02:23:21 [opswgw-gateway-2.1.1: cgw0-
C43] --PropertiesFile /etc/opt/opsware/opswgw-cgw0-C43/
--Child true
# ps -eaf | grep -v grep | grep opswgw | grep agw
root 17207 1 0 Sep21 ? 00:00:00 [opswgw-watchdog-2.1.1: agw0-C43]
--PropertiesFile /etc/opt/opsware/opswgw-agw0-C43/
root 17208 17207 0 Sep21 ? 01:18:54 [opswgw-gateway-2.1.1: agw0-
C43] --PropertiesFile /etc/opt/opsware/opswgw-agw0-C43/
--Child true
In a Satellite facility on Solaris or Linux, execute the command on the server running the
Satellite Gateway component:
# ps -eaf | grep -v grep | grep opswgw | grep <gateway-name>
Where <gateway-name> in this example is Sat1.
root 17092 1 0 Sep21 ? 00:00:00 [opswgw-watchdog-2.1.1: Sat1]
214
--PropertiesFile /etc/opt/opsware/opswgw-Sat1/
root 17094 17092 0 Sep21 ? 02:23:21 [opswgw-gateway-2.1.1: Sat1]
--PropertiesFile /etc/opt/opsware/opswgw-Sat1/
--Child true
Gateway URL
Log into the SAS Web Client UI and select Gateway under Administration in the navigation
panel.
https://occ.<data_center>/com.opsware.occ.gwadmin/index.jsp
Gateway Logs
The Gateway logs are in the following files:
Strings containing ERROR
Strings containing FATAL (indicates that the process will end soon)
OS Build Manager Monitoring
The OS Build Manager component facilitates communications between OS Build Agents
and the Command Engine. It accepts OS provisioning commands from the Command
Engine, and it provides a runtime environment for the platform-specific build scripts to
perform the OS provisioning procedures.
OS Build Manager Ports
The OS Build Manager uses the following ports:
1012 (HTTPS)
1017 (SA Build Agent)
215
Monitoring Processes for the OS Build Manager
In all configurations, the OS Build Manager component has a single running process.
On Solaris or Linux, execute the command on the server running the OS Build Manager
component:
# ps -eaf | grep -v grep | grep buildmgr
root 2174 1 0 Sep27 ? 00:13:54 /opt/opsware/j2sdk1.4.2_10/bin/
java -Xmx256m -Dbuildmgr -Djava.security.properties=/opt/
opsware/buildmgr/etc/java.security -DDEBUG -DDEBUG_
VERBOSE=1 -DLOG_OPTIONS=tTN -DLOG_FILE_THRESHOLD=10485760
-DLOG_FILE_RETAIN_COUNT=7 -DLOG_
CLASSES=com.opsware.buildmgr.OutputStreamLo
OS Build Manager URL
https://buildmgr.<data_center>:1012
The OS Build Manager UI is read-only and port 1012 for the UI is configurable.
OS Build Manager Logs
The OS Build Manager logs are in the following files:
/var/log/opsware/buildmgr/buildmgr.log (Build Agent activities, OS
provisioning activities)
/var/log/opsware/buildmgr/*.request.log (Web Server log; one file per
day; 90 logs maximum)
/var/log/opsware/buildmgr/console.log
/var/log/opsware/buildmgr/servers/<IP_address or machine_ID or
MAC_address> (A per connection log)
Conditions to monitor in the logs: the string Traceback
216
OS Boot Server Monitoring
The OS Boot Server, part of the OS Provisioning feature, supports network booting of Sun
and x86 systems with inetboot and PXE respectively. The processes used to provide this
support include the Internet Software Consortium DHCP server, and Sun Solaris TFTP and
NFS.
These applications are installed by the HP BSA Installer but are not specific to SA. Monitor
them by using standard system administration best practices for these applications.
OS Boot Server Ports
The OS Boot Server uses the following ports:
67 (UDP) (DHCP service)
69 (UDP) (TFTP service)
OS Boot Server Logs
The OS Boot Server does not generate its own logs. The OS Boot Server uses these
services: TFTP with INETD, NFS server, and ISC DHCPD. All of these services log with
syslog. Consult your vendor documentation for more information. See also the
syslog.conf file that was used to configure the OS Boot Server to determine how the
logging has been configured for this component.
OS Media Server Monitoring
The OS Media Server, part of the OS Provisioning feature, is responsible for providing
network access to the vendor-supplied media used during OS provisioning. The
processes used to provide this support include the Samba SMB server and Sun Solaris
NFS.
These applications are installed by the HP BSA Installer but are not specific to SA.
Specifically, SA provides a Samba package for Linux and Solaris that customers can use
to install the OS Media Server. NFS services are provided by the operating system. Using
the HP BSA Installer to install the OS Media Server configures NFS on Linux and Solaris.
Monitor the Samba SMB server and Sun Solaris NFS applications by using standard
system administration best practices for these applications.
217
OS Media Server Ports
The OS Media Server uses the following ports:
The portmapper used by NFS is port 111.
Samba SMB uses ports 137, 138, 139, and 445.
OS Media Server Logs
The OS Media Server logs are in the following files:
/var/log/opsware/samba/log.smbd
/var/log/opsware/samba/log.nmbd
Solaris and Linux OS provisioning use of vendor-provided services such as NFSD. These
services typically log through syslog. Consult your vendor documentation for more
information on these log files.
218
219
Chapter 7: SA Configuration
System Configuration
During the installation of an SA core the HP BSA Installer sets specific system
configuration parameters. In addition to the parameters that are set during installation,
there are also many default values for the various system configuration parameters that
should not be changed unless expressly directed to do so by your technical support
representative or consultant.
For information about how to use this function when you install an SA core, see the
SA Planning and Installation Guide.
Additionally, for the Audit and Remediation feature you can set the system configuration
on an SA core so that audit and snapshot results get deleted after a specified number of
days. This can be useful for those audit and snapshot jobs that run on a recurring
schedule and generate many results.
For more information on the Audit and Remediation feature, see the SA Users Guide:
Application Automation.
The Server Agent reads the system configuration values at installation time only. If any of
the configuration values change, the agent configuration must be updated manually.
Contact Technical Support for help making these changes, or in making any other
changes in the System Configuration area of SA.
The topics covered in this section include:
System Configuration
Ways to Use SA Configuration Parameters
Scheduling Audit Result and Snapshot Removal
220
Ways to Use SA Configuration Parameters
This section documents how to set specific parameters after you install an SA core so that
SA properly sends email alerts and displays the correct support contact information for
your organization.
Where a value for a configuration parameter must be set for an installation of a core, SA
Planning and Installation Guide provides instructions for setting the value. Set
configuration values for those parameters as explicitly directed by the steps in the
installation procedures.
Do not change other configuration values, unless explicitly directed to do so by this guide
or by SA Planning and Installation Guide or by your Support Representative.
After you install a core, you should set several configuration parameter values that SA
uses to send email notifications and alerts, and to display the SA administrator contact
information.
These values are set by selecting Administration System Configuration in the SAS Web
Client.
Configuring Contact Information in the SA Help
To configure the SA administrator contact information that appears on the SA Help page,
perform the following steps:
1 In the SA Core, log on as root to the server running the Command Center
Component.
2 Change directories to the following directory:
/etc/opt/opsware/occ
3 Open the psrvr.properties file in a text editor.
4 In the psrvr.properties, change the values in the following fields to change the
contact information in the SAS Web Client Help:
pref.occ.support.href
pref.occ.support.text
5 Save and exit from the file.
221
6 Restart the Command Center component by entering the following command:
/etc/init.d/opsware-sas restart occ.server
Configuring the Mail Server for a Facility
Perform the following steps in a multimaster mesh to configure the mail server for the core
running in each facility.
1 Log into the SAS Web Client as the admin user with the password you supplied
during the interview. Log in by opening a browser and entering the IP address of the
server running the SAS Web Client.
page appears.
2 From the navigation panel, click System Configuration under Administration. The
3 Under Select a Product, click the link for the facility name. The configuration page for
the facility appears.
SA components use the parameter opsware.mailserver to determine the
address of the mail server to use. If a value is not entered in the field, by default, the
value of opsware.mailserver is smtp. If managed servers are able to contact a
mail server by using this name as the address, then you do not need to modify this
parameter.
4 In the field, opsware.mailserver, enter the host name of the mail server.
5 Click Save to apply the changes. The configuration page refreshes and a message
appears that the update was successful.
7 Under Select a Product, click Command Engine.
8 In the field, way.notification.email.fromAddr, enter the From email address for the
email messages that will be sent by the Command Engine to notify users about
scheduled jobs.
9 Click Save to apply the changes.
10 Restart the Command Engine and SAS Web Client.
222
11 If SA is running in multimaster mode, restart the Model Repository Multimaster
Component.
When restarting multiple SA components, you must restart them in the correct order.
See Chapter 5, Starting an SA Core on page 175 of this guide.
Setting Email Alert Addresses for an SA Core
You should configure these email alert addresses before you install an Server Agent on
the servers in your operational environment because the Agent on a managed server will
only read this email configuration information the first time it contacts SA.
Perform the following steps to configure these email alert addresses. The HP BSA Installer
installs an SA Core with placeholder values (EMAIL_ADDR) for these parameters.
1 Log into the SAS Web Client as the admin user. Log in by opening a browser and
entering the IP address of the server running the SAS Web Client.
If the SAS Web Client is installed and listening, the SAS Web Client home page
appears.
3 Under Select a Product, click the Server Agent link. The configuration page for the
Agent appears.
4 Configure the following required email alert addresses:
In the field, acsbar.ErrorEmailAddr, enter the address that SA should send
email warnings to when any configuration tracking limit is exceeded (for example,
when the configuration tracking feature stopped backing up configuration files and
databases).
In the field, acsbar.emailFromAddr, enter the address that the Agent will use
as the email From address when sending emails. For example,
[email protected].
In the field, CronbotAlertAddress, enter the email address that the Server
Agent will use to alert the recipient about failed scheduled jobs.
223
In the field, CronbotAlertFrom, enter the email address that the Agent will use
as the email From address in the emails about failed scheduled jobs. For example,
[email protected].
Configuring Email Alert Addresses for Multimaster
Perform the following steps to configure email alert addresses for multimaster. The HP
BSA Installer installs an SA Core with placeholder values (EMAIL_ADDR) for these
parameters.
1 Log into as the admin user with the password you supplied during the interview. Log
in by opening a browser and entering the IP address of the server running the SAS
Web Client.
The SAS Web Clientshould be installed and listening. The SAS Web Client home
page appears.
3 Under Select a Product, click the Model Repository, Multimaster Component link. The
configuration page for the Model Repository, Multimaster Component appears.
4 Configure the following email parameters:
In the field, sendMMErrorsTo, enter the email address to which multimaster
conflicts will be sent.
In the field, sendMMErrorsFrom, enter the address that SA will use as the email
From address in the emails when multimaster conflicts are detected.
Restart the Model Repository Multimaster Component in all SA Cores in the
Multimaster Mesh. See Chapter 5, Starting an SA Core Component on page 175 of
this guide.
224
Configuring Email Notification Addresses for Code Deployment and
Rollback (CDR)
You can set up email notification addresses for SA Code Deployment & Rollback (CDR).
When users request that a service operation or synchronization be performed on their
behalf, an email notification is sent to the individuals assigned to perform the requested
service operation or synchronization.
Perform the following steps to configure email notification addresses for CDR. The HP
BSA Installer installs an SA Core with placeholder values (EMAIL_ADDR) for these
parameters.
If the SAS Web Client is installed and listening the SAS Web Client home page
appears.
2 From the Navigation panel, click System Configuration under Administration. The
225
3 Click the link for the SAS Web Client. The configuration page appears, as Figure 7-1
shows.
Figure 7-1: CDR Email Notification Configuration Parameters
4 Customize the following parameters to include the following email notification
information:
In the field, cds.requesttoaddress, enter the email address to include in the To field
of the email message for a request notification.
In the field, cds.requestfromaddress, enter the email address to include in the From
field of the email message for a request notification.
In the field, cds.wayfrom, enter the email address to include in the From field of the
email message sent following completion of a sequence.
In the field, cds.supportaddress, enter the email address to include for a facilities'
support organization or contact person.
In the field, cds.supportorg, enter the display name of a facilities' support
organization.
226
6 Restart the Command Engine and the Model Repository Multimaster Component.
When you restart multiple SA components, you must restart them in the correct
order.
Scheduling Audit Result and Snapshot Removal
Because Audit Results (results of an audit) and snapshots (results of a snapshot
specification) can accumulate over time, especially those that run on a recurring
schedule, you can configure your SA Core so that after a specified number of days Audit
Results and snapshots will be deleted from the core.
Note that this setting only applies to those audit results and snapshots that have not been
archived. Archived results can only be deleted from the SA Client manually.
Additionally, there are two other conditions where an Audit Result or a snapshot will not
be deleted by these settings:
If the snapshot is being used as the target of an audit
If the Audit Result or snapshot is the only result of either an audit or snapshot
specification
To configure audit results and snapshots removal, perform the following steps:
page appears.
3 Click the link for the SAS Web Client. The configuration page appears.
4 Under Select a Product, click the Data Access Engine link. The configuration page for
the Data Access Engine appears.
5 To set the number of days to elapse before an audit results or snapshot are deleted,
modify the following parameters:
227
Scroll down to the spin.cronbot.delete_snapshots.cleanup_day parameter, and in
the Use value field enter the number of days that must elapse before all non-
archived snapshots will be deleted. If you select the Use default value setting, no
snapshots will deleted.
Scroll down to the spin.cronbot.delete_audits.cleanup_days, and in the Use value
field enter the number of days that must elapse before all non-archived Audit
Results will be deleted. If you select the Use default value setting, no snapshots
will deleted.
6 When you are finished, at the bottom of the page, click Save.
228
229
Appendix A: Permissions Reference
Permissions Required for the SAS Web Client
The following table lists the feature permissions according to tasks that can be performed
with the SAS Web Client.
I N T H I S A P P E N D I X
Permissions Required for the SAS Web Client
Permissions Required for the SA Client
Server Property and Reboot Permissions
Predefined User Group Permissions
Private User Groups (PUG) Permissions
Code Deployment User Groups
Table A-1: Permissions Required for SAS Web Client Tasks
TASK FEATURE PERMISSION
OS PROVISIONING
Prepare OS Wizard: Prepare OS
Edit OS nodes Operating Systems
View servers in the server pool Server Pool
CONFIGURATION TRACKING
Create or edit tracking policy Configuration Tracking
Managed Servers and Groups
Reconcile tracking policy Configuration Tracking
230
Perform configuration backup Configuration Tracking
View backup history, restore queue Configuration Tracking
Enable or disable tracking Configuration Tracking
SERVER MANAGEMENT
Edit server properties Managed Servers and Groups
Edit server network properties Managed Servers and Groups
Edit server custom attributes Managed Servers and Groups
Deactivate server Deactivate
Delete server Managed Servers and Groups
Clone server Managed Servers and Groups
Re-assign customer Managed Servers and Groups
View servers (read-only access) Managed Servers and Groups
Run server communications test Managed Servers and Groups
Lock servers Managed Servers and Groups
Set scheduled job to refresh server list Allow Run Refresh Jobs
REPORTS
Create or view reports Data Center Intelligence Reports
MANAGE ENVIRONMENT
Create or edit customer Customers
Create or edit facility Facilities
IP RANGES AND RANGE GROUPS
IP Ranges IP Ranges and Range Groups
Model: Hardware
Model: SA
Table A-1: Permissions Required for SAS Web Client Tasks (continued)
231
Permissions Required for the SA Client
The following tables in this section summarize the permissions required for the SA Client
features.
Application Configuration Management Permissions
Device Group Permissions
SA Discovery and Agent Deployment Permissions
Job Permissions
Patch Management for Windows Permissions
Patch Management for Unix Permissions
Software Management Permissions
Script Execution Permissions
IP Range Groups IP Ranges and Range Groups
Model: Hardware
Model: SA
SYSTEM CONFIGURATION
Manage users and groups (Administrators group only)
Define server attributes Server Attributes
Run system diagnosis tools System Diagnosis
Manage SA System configuration Configure SA
Run SA multimaster tools Multimaster
Gateway management Manage Gateway
OTHER TASKS
Run custom extension Wizard: Custom Extension
Deploy code See Code Deployment User Groups on
page 312.
Table A-1: Permissions Required for SAS Web Client Tasks (continued)
232
Audit and Remediation Permissions
Service Automation Visualizer Permissions
Virtualization Director Permissions
OS Provisioning Permissions
Compliance View Permissions
Server Objects Permission
More Information for Security Administrators
In some organizations, security administrators work with many applications and do not
specialize in SA. To learn about SA quickly, security administrators can refer to Process
Overview for Security Administration on page 58 - This short section lists the overall
tasks for setting up security in SA.
Application Configuration Management Permissions
Table A-2 specifies the Application Configuration Management permissions required by
users to perform specific actions in the SA Client. For security administrators, the table
answers this question: To perform a particular action, what permissions does a user
need?
In addition to the feature permissions listed in Table A-2, every user action also requires
the Managed Servers and Groups feature permission.
In Table A-2, the Server Permission column is for the servers referenced by the
Application Configuration or Application Configuration Template. Server permissions are
specified by the Customer, Facility, and Device Groups permissions in the SAS Web
Client. In Table A-2, the Customer Permission column is for the customers associated with
Application Configurations or Application Configuration Templates.
To perform an action, the user requires several permissions. For example, to attach an
application configuration to a server, the user must have the following permissions:
Manage Application Configurations: Read
Manage Configuration Templates: Read
233
Manage Installed Configuration and Backups on Servers: Read & Write
Read & Write permissions to the facility, device group, and customer of the server
Read permission for the customer of the Application Configuration
Table A-2: Application Configuration Management Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
Application Configuration
Create Application
Configuration
Manage Application Configura-
tions:
Read & Write
and Manage Configuration Tem-
plates:
Read
None Read & Write
View Application Configuration Manage Application
Configurations:
Read & Write
and Manage Configuration
Templates:
Read
None Read
Edit Application Configuration Manage Application Configura-
tions:
Read & Write
plates:
Read
None Read & Write
234
Delete Application
Configuration
tions:
Read & Write
plates:
Read
None Read & Write
Specify Template Order Manage Application Configura-
tions:
Read & Write
plates:
Read
None Read & Write
Attach Application Configura-
tion to Server
tions:
Read
plates:
Read
and Manage Installed Configura-
tion and Backups on Servers:
Read & Write
Read & Write Read
Set Application Configuration
Values on Server
tions:
Read
plates:
Read
Read & Write
Read & Write Read
Table A-2: Application Configuration Management Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
235
Push Application Configuration
to Server
tions:
Read
plates:
Read
Read & Write
Read & Write Read
Schedule Application Configu-
ration Push
tions:
Read
plates:
Read
Read & Write
Read & Write Read
Scan Configuration Compliance Allow Configuration Compliance
Scan: Yes
and Manage Application Configu-
rations:
Read
plates:
Read
Read Read
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
236
ration Audit
Allow Configuration Compliance
Scan: Yes
rations:
Read
plates:
Read
Read Read
Roll Back (Revert) Application
Configuration Push
tions:
Read
plates:
Read
Read & Write
Read & Write Read
Application Configuration Templates
Create Application Configura-
tion Template
Manage Configuration Templates:
Read & Write
None Read & Write
View Application Configuration
Template
Read & Write
None Read
Edit Application Configuration
Template
Read & Write
None Read & Write
Delete Application Configura-
tion Template
Read & Write
None Read & Write
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
237
Table A-3 lists the actions that users can perform for each Application Configuration
Management permission. Table A-3 has the same data as Table A-2, but is sorted by
feature permission. Although not indicated in Table A-3, the Managed Servers and
Groups permission is required for all OS provisioning actions.
For security administrators, Table A-3 answers this question: If a user is granted a
particular feature permission, what actions can the user perform?
Load (Import) Application Con-
figuration Template
tions:
Read & Write
plates:
Read & Write
None Read & Write
Template to Run as Script
Read & Write
None Read & Write
Compare Two Application Con-
figuration Templates
Read
None Read
Compare Application Configu-
ration Template Against Actual
Configuration File (Preview)
tions:
Read
plates:
Read
Read
Read Read
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
238
Table A-3: User Actions Allowed by Application Configuration Management Permissions
FEATURE
PERMISSION
USER ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
Allow Configuration Compliance
Scan: Yes
rations:
Read
plates:
Read
Scan Configuration Compliance Read Read
ration Audit
Read Read
tions:
Read & Write
plates:
Read
Create Application
Configuration
None Read & Write
Delete Application
Configuration
None Read & Write
Edit Application Configuration None Read & Write
Specify Template Order None Read & Write
View Application Configuration None Read
tions:
Read & Write
plates:
Read & Write
Load (Import) Application Con-
figuration Template
None Read & Write
239
tions:
Read
plates:
Read
Read
Compare Application Configu-
ration Template Against Actual
Configuration File (Preview)
Read Read
tions:
Read
plates:
Read
Read & Write
Attach Application Configura-
tion to Server
Read & Write Read
Push Application Configuration
to Server
Read & Write Read
Roll Back (Revert) Application
Configuration Push
Read & Write Read
ration Push
Read & Write Read
Values on Server
Read & Write Read
Read
Compare Two Application Con-
figuration Templates
None Read
Read & Write
tion Template
None Read & Write
Delete Application Configura-
tion Template
None Read & Write
Edit Application Configuration
Template
None Read & Write
Table A-3: User Actions Allowed by Application Configuration Management Permissions (continued)
FEATURE
PERMISSION
USER ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
240
Device Group Permissions
To use the Device Groups feature in the SA Client, you must have the permissions
described in the Table A-4. For a list of tasks that require the Model Public Device Group
permission, see Table A-11.
Read & Write (cont.)
Template to Run as Script
None Read & Write
View Application Configuration
Template
None Read
Table A-3: User Actions Allowed by Application Configuration Management Permissions (continued)
FEATURE
PERMISSION
USER ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
CUSTOMER
PERMISSION
(APP
CONFIG, APP
CONFIG
TEMPLATE)
Table A-4: Device Groups Feature Permissions
USER ACTION FEATURE PERMISSION
Creating a public static device group Manage Public Device Group
Creating a public dynamic device group Manage Public Device Group
Adding a server to a public static device
group
Manage Public Device Group
Adding a server to a public dynamic device
Group
Removing a server from a public static
device group
Removing servers from a public dynamic
device group
Moving a public device group Manage Public Device Group
Duplicating a public device group Manage Public Device Group
Deleting a public device group Manage Public Device Group
241
SA Discovery and Agent Deployment Permissions
To use Discovery and Deployment (ODAD) in the SA Client, you must have the
permissions described in the Table A-5.
In addition to the feature permissions listed in the preceding table, you must have Read
permissions on the following:
Customer named Opsware
Facility that has the servers targeted for Agent deployment.
If you use device groups to limit access to managed servers, you must create a device
group that contains the servers owned by customer Opsware.
To use ODAD on Windows managed servers, you also need Read permissions on the
following:
Customer that owns the server running the Windows Agent Deployment Helper (ADH)
Facility that has the server running the Windows ADH
Read permissions for Manage Software Policies.
Read permissions to the following directory in order to use the Windows ADH
/Opsware/Tools/Agent Deployment Helper
List permissions on the following folders:
/
/Opsware
/Opsware/Tools
Job Permissions
To manage jobs in the SA Client, you must have the permissions described in the
Table A-6. When you select the Edit All Jobs permission, the View All Jobs permission is
automatically selected.
Table A-5: ODAD Feature Permissions
Deploy (Install) Agent with ODAD Allow Deploy Agent: Yes
Scan Network with ODAD Allow Scan Network: Yes
View Servers Running Agents Managed Servers and Groups
242
In order to view any job in the SA Client, you must have permissions to run or execute the
job. For example, if you had the permissions for an action such as Manage Application
Configurations set to Read, but did not have Write permissions for this action, you would
not be able to see any Application Configuration Push jobs in the SA Client.
.
In general, In order to view jobs
Patch Management for Windows Permissions
Table A-7 specifies the Patch Management permissions required by users to perform
specific actions in the SA Client. For security administrators, the table answers this
question: To perform a particular action, what permissions does a user need?
Table A-6: Job Management Permissions
Enable Approval Integration Manage Approval Integration
Set Job Types Requiring Approval Manage Approval Integration
Invoke JobService API Methods to Manage
Blocked (Pending Approval) Jobs
(This action is performed by customized
software on the backend, not by end-users
logged onto the SA Client.)
Edit All Jobs
View All Jobs
End (Cancel) Job Edit All Jobs
View All Jobs
Delete Schedule Edit All Jobs
View All Jobs
243
In Table A-7, most of the entries in the User Action column correspond to menu items in
the SA Client. In addition to feature permissions, server permissions are required on the
managed servers affected by the patching operation.
If the Allow Install Patch permission is set to Yes, then the Manage Patch and the Manage
Patch Policies permissions are automatically set to Read.
Table A-7: Windows Patch Management Permissions Required for User Actions
USER
ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Patches
Install Patch (Available) Allow Install Patch: Yes
Manage Patch: Read
Read & Write
Uninstall Patch (Available) Allow Uninstall Patch: Yes
and Manage Patch: Read
Read & Write
Install Patch (Limited Availability) Allow Install Patch: Yes
Manage Patch: Read & Write
Read & Write
Uninstall Patch (Limited
Availability)
Allow Uninstall Patch: Yes
and Manage Patch: Read & Write
Read & Write
Open Patch (View Patch) Manage Patch: Read N/A
Change Patch Properties Manage Patch: Read & Write N/A
Import Patch Manage Patch: Read & Write
and Package
N/A
Import Patch Database Manage Patch: Read & Write N/A
Export Patch Manage Patch: Read
and Package
N/A
Export Patch or Allow Install Patch: Yes
and Package: Yes
N/A
244
Export Patch or Allow Uninstall Patch: Yes
and Package
N/A
Export Patch or Manage Policy: Read
and Package
N/A
Delete Patch Manage Patch: Read & Write N/A
Patch Policies and Exceptions
Remediate Policy Allow Install Patch: Yes Read & Write
Open Patch Policy (View) Manage Patch Policy: Read N/A
Add Patch to Patch Policy Manage Patch: Read
and Manage Patch Policy: Read &
Write
N/A
Remove Patch from Patch Policy Manage Patch Policy: Read & Write N/A
Set Exception Allow Install Patch: Yes Read & Write
Set Exception or Allow Uninstall Patch: Yes Read & Write
Copy Exception Allow Install Patch: Yes Read & Write
Copy Exception or Allow Uninstall Patch: Yes Read & Write
Attach Patch Policy to Server (or
Device Group)
Manage Patch Policy: Read Read & Write
Detach Patch Policy from Server
(or Device Group)
Manage Patch Policy: Read Read & Write
Create Patch Policy Manage Patch Policy: Read & Write N/A
Delete Patch Policy Manage Patch Policy: Read & Write N/A
Change Patch Policy Properties Manage Patch Policy: Read & Write N/A
Patch Compliance Rules
Table A-7: Windows Patch Management Permissions Required for User Actions (continued)
USER
ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
245
Table A-8 lists the actions that users can perform for each Patch Management
permission. Table A-8 has the same data as Table A-7, but is sorted by feature
permission. Although it is not indicated in Table A-8, the Managed Servers and Groups
permission is required for all Patch Management actions.
Edit Patch Products (Patch Con-
figuration window)
Manage Patch Compliance Rules: Yes N/A
Scan Patch Compliance Manage Patch Policy: Read N/A
Schedule a Patch Policy Scan Manage Patch Compliance Rules: Yes N/A
Change Default Patch Availability Manage Patch Compliance Rules: Yes N/A
Change Patch Policy Compli-
ance Rules
Manage Patch Compliance Rules: Yes N/A
View Patch Policy Compliance
Rules
Manage Patch Policy: Yes N/A
Table A-8: User Actions Allowed by Windows Patch Management Permissions
FEATURE
PERMISSION
USER
ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Allow Install Patch: Yes Copy Exception Read & Write
Remediate Policy Read & Write
Set Exception Read & Write
Table A-7: Windows Patch Management Permissions Required for User Actions (continued)
USER
ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
246
Allow Install Patch: Yes
Install Patch (Available) Read & Write
Uninstall Patch (Available) Read & Write
Install Patch (Limited Availability) Read & Write
Availability)
Read & Write
and Package: Yes
Export Patch N/A
Allow Uninstall Patch: Yes Copy Exception Read & Write
and Package
Export Patch N/A
Uninstall Patch Read & Write
Manage Patch Compliance Rules: Yes Change Default Patch Availability N/A
Change Patch Policy Compli-
ance Rules
N/A
Edit Patch Products (Patch Con-
figuration window)
N/A
Schedule a Patch Policy Scan N/A
Manage Patch Policy: Read Attach Patch Policy to Server (or
Device Group)
Read & Write
Detach Patch Policy from Server
(or Device Group)
Read & Write
Open Patch Policy (View) N/A
Table A-8: User Actions Allowed by Windows Patch Management Permissions (continued)
FEATURE
PERMISSION
USER
ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
247
Patch Management for Unix Permissions
Table A-9 specifies the Patch Management permissions required by users to perform
Manage Patch Policy: Read & Write Change Patch Policy Properties N/A
Create Patch Policy N/A
Delete Patch Policy N/A
Remove Patch from Patch Policy N/A
Manage Patch Policy: Yes View Patch Policy Compliance
Rules
N/A
Manage Patch: Read Open Patch (View Patch)
Scan Patch Compliance
N/A
Manage Patch: Read & Write Change Patch Properties N/A
Delete Patch N/A
Import Patch Database N/A
and Package
Import Patch N/A
Manage Patch: Read
and Manage Patch Policy: Read &
Write
Add Patch to Patch Policy N/A
Manage Patch: Read
and Package
Export Patch N/A
Manage Policy: Read
and Package
Export Patch N/A
Table A-8: User Actions Allowed by Windows Patch Management Permissions (continued)
FEATURE
PERMISSION
USER
ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
248
the SA Client. In addition to feature permissions, server permissions are required on the
managed servers affected by the patching operation.
If the Allow Install Patch permission is set to Yes, then the Manage Patch and the Manage
Patch Policies permissions are automatically set to Read.
Table A-9: Unix Patch Management Permissions Required for User Actions
USER
ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Patches
Install Patch (Available) Allow Install Patch: Yes
Manage Patch: Read
Read & Write
Uninstall Patch (Available) Allow Uninstall Patch: Yes
Read & Write
Install Patch (Limited Availability) Allow Install Patch: Yes
Read & Write
Availability)
Read & Write
Open Patch (View Patch) Manage Patch: Read N/A
Change Patch Properties Manage Patch: Read & Write N/A
Export Patch Manage Patch: Read
and Package
N/A
Export Patch or Allow Install Patch: Yes
and Package: Yes
N/A
249
Table A-10 lists the actions that users can perform for each Patch Management
permission is required for all Patch Management actions.
Export Patch or Allow Uninstall Patch: Yes
and Package
N/A
Export Patch or Manage Policy: Read
and Package
N/A
Delete Patch Manage Patch: Read & Write N/A
Table A-10: User Actions Allowed by Unix Patch Management Permissions
FEATURE
PERMISSION
USER
ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Allow Install Patch: Yes Copy Exception Read & Write
Remediate Policy Read & Write
Install Patch (Available) Read & Write
Uninstall Patch (Available) Read & Write
Install Patch (Limited Availability) Read & Write
Availability)
Read & Write
Table A-9: Unix Patch Management Permissions Required for User Actions (continued)
USER
ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
250
Software Management Permissions
Table A-11 specifies the Software Management permissions required by users to perform
and Package: Yes
Export Patch N/A
Allow Uninstall Patch: Yes Copy Exception Read & Write
and Package
Export Patch N/A
Manage Patch: Read Open Patch (View Patch) N/A
Manage Patch: Read & Write Change Patch Properties N/A
Delete Patch N/A
Import Patch Database N/A
and Package
Import Patch N/A
Manage Patch: Read
and Manage Policy: Read & Write
Add Patch to Policy N/A
Manage Patch: Read
and Package
Export Patch N/A
Manage Policy: Read
and Package
Export Patch N/A
Table A-10: User Actions Allowed by Unix Patch Management Permissions (continued)
FEATURE
PERMISSION
USER
ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
251
If a customer is assigned to a folder, then customer constraints might limit the objects that
can be associated with a software policy contained in the folder. For a list of tasks
affected by these constraints, see Customer Constraints, Folders, and Software Policies
on page 51.
Table A-11: Software Management Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Software Policy
Create Software Policy Manage Software Policy: Read
& Write
N/A Write
Delete Software Policy Manage Software Policy: Read
& Write
N/A Write
Open Software Policy
(View)
Manage Software Policy: Read N/A Read
Edit Software Policy
Properties
Manage Software Policy: Read
& Write
N/A Write
Add Packages Manage Software Policy: Read
& Write
Manage Packages: Read
N/A Folder containing the
software policy: Write
Add RPM Packages Manage Software Policy: Read
& Write
Add Patches Manage Software Policy: Read
& Write
Manage Patches: Read
252
Add Application
Configurations
& Write
Manage Application
Configuration: Read
Add Scripts Manage Software Policy: Read
& Write
Manage Server Scripts: Read
Add Server Objects Manage Software Policy: Read
& Write
Add Software Policies Manage Software Policy: Read
& Write
Remove Packages Manage Software Policy: Read
& Write
N/A Write
Remove RPM
Packages
& Write
N/A Write
Remove Patches Manage Software Policy: Read
& Write
N/A Write
Remove Application
Configurations
& Write
N/A Write
Remove Software
Policies
& Write
N/A Write
Remove Scripts Manage Software Policy: Read
& Write
N/A Write
Table A-11: Software Management Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
253
Remove Server Objects Manage Software Policy: Read
& Write
N/A Write
Install/ Uninstall
Software
Allow Attach/Detach Software
Policy: Yes
Allow Install/Uninstall Software:
Yes
Model Public Device Groups:
Yes (Required if you remediate a
public device group)
Read & Write Read
Attach Software Policy Manage Software Policy: Read
Policy: Yes
Yes (This permission is required
if you are attaching the software
policy to a public device group)
Read & Write Read
Detach Software Policy Manage Software Policy: Read
Policy: Yes
Yes (This permission is required
if you are attaching the software
policy to a public device group)
Read & Write Read
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
254
Remediate Manage Software Policy: Read
Allow Remediate Servers: Yes
Yes (Required if you remediate a
Read & Write Read
Run ISM Control Manage Software Policy: Read
Allow Run ISM Control: Yes
Yes (Required if you run ISM
Control on a public device
group)
Read & Write Read
Duplicate Zip Package Manage Software Policy: Read
& Write
N/A Write
Edit ZIP Installation
Directory
& Write
N/A Write
Scan Software
Compliance
N/A Read N/A
Rename Software
Policy
& Write
N/A Write
Cut Software Policy Manage Software Policy: Read
& Write
N/A Write
Copy Software Policy Manage Software Policy: Read N/A Read
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
255
Paste Software Policy Manage Software Policy: Read
& Write
N/A Source Folder: Read
(for copy and paste)
Source Folder: Write
(for cut and paste)
Destination Folder:
Write
Move Software Policy Manage Software Policy: Read
& Write
N/A Source Folder: Write
Destination Folder:
Write
Folder
Create Folder N/A N/A Write
Delete Folder N/A N/A Write
Open Folder N/A N/A Read
View Folder Properties N/A N/A Read
Edit Folder Properties N/A N/A Write
Manage Folder
Permissions
N/A N/A Edit Folder Permissions
Cut Folder N/A N/A Write
Copy Folder N/A N/A Read
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
256
Paste Folder N/A N/A Source Folder: Read
(for cut and paste)
Destination Folder:
Write
Move Folder N/A N/A Source Folder: Write
Destination Folder:
Write
Rename Folder N/A N/A Write
Package
Import Package Manage Package: Read & Write N/A Write
Export Package Manage Package: Read N/A Read
Open Package (View) Manage Package: Read N/A Read
Edit Package Properties Manage Package: Read & Write N/A Read
Delete Package Manage Package: Read & Write N/A Write
Rename Package Manage Package: Read & Write N/A Write
Cut Package Manage Package: Read & Write N/A Write
Paste Package Manage Package: Read & Write N/A Source Folder: Read
(for cut and paste)
Destination Folder:
Write
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
257
Table A-12 lists the actions that users can perform for each Software Management
permission. For security administrators, Table A-12 answers this question: If a user is
granted a particular feature permission, what actions can the user perform?
Move Package Manage Package: Read & Write N/A Source Folder: Write
Destination Folder:
Write
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
258
Table A-12: User Actions Allowed by Software Management Permissions
FEATURE PERMISSION USER ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Manage Software
Policy: Read & Write
Create Software Policy N/A Write
Delete Software Policy N/A Write
Edit Software Policy N/A Write
Rename Software Policy N/A Write
Cut Software Policy N/A Write
Paste Software Policy N/A Write
Move Software Policy N/A Write
Remove Packages N/A Write
Remove Patches N/A Write
Remove Application
Configurations
N/A Write
Remove Scripts N/A Write
Remove Server Objects N/A Write
Remove Software Policy N/A Write
Duplicate ZIP packages N/A Write
Manage Software
Policy: Read
Open Software Policy (View) N/A Read
Copy Software Policy Properties N/A Read
Manage Software
And
Manage Package:
Read
Add Packages
Add RPM Packages
Folder containing the
package: Read
259
Manage Software
And
Manage Patches: Read
Add Patches N/A Folder containing the
patch: Read
Manage Software
And
Manage Application
Configuration: Read
Add Application Configurations N/A Folder containing the
application
configuration: Read
Manage Software
Add Software Policies N/A Folder containing the
software policy to be
added to another
software policy: Read
Manage Software
And
Manage Server Scripts:
Read
Add Scripts N/A Folder containing the
scripts: Read
Manage Software
And
Manage Packages:
Read
Add Server Objects N/A Folder containing the
server objects: Read
Table A-12: User Actions Allowed by Software Management Permissions (continued)
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
260
Manage Software
Remove Packages N/A Write
Remove RPM Packages N/A Write
Remove Patches N/A Write
Remove Application
Configurations
N/A Write
Remove Scripts N/A Write
Remove Server Objects N/A Write
Remove Software Policies N/A Write
Manage Software
Policy: Read
And
Allow Attach/Detach
Software Policy: Yes
And
Model Public Device
Groups: Yes (Required
if you are attaching the
software policy to a
Attach Software Policy Read & Write Read
Detach Software Policy Read & Write Read
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
261
Manage Software
Policy: Read
And
Allow Remediate
Servers: Yes
And
Model Public Device
if you remediate a
Remediate Read & Write Read
Manage Software
Policy: Read
And
Allow Attach/Detach
Software Policy: Yes
And
Allow Install/Uninstall
Software: Yes
And
Model Public Device
if you remediate a
Install/ Uninstall Software Read & Write Read
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
262
Manage Software
Policy: Read
And
Allow Run ISM Control:
Yes
And
Model Public Device
if you run ISM Control
on a public device
group)
Run ISM Control Read & Write Read
Manage Package:
Read & Write
Import Package N/A Write
Delete Package N/A Write
Rename Package N/A Write
Cut Package N/A Write
Paste Package N/A Write
Move Package N/A Write
Manage Package:
Read & Write
Edit Package Properties N/A Read
Manage Package:
Read
Export Package N/A Read
Open Package (View) N/A Read
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
263
Script Execution Permissions
Table A-13 specifies the Script Execution permissions required by users to perform
If a customer is assigned to a folder, then customer constraints might limit the objects that
can be associated with a software policy contained in the folder. For a list of tasks
affected by these constraints, see Customer Constraints, Folders, and Software Policies
on page 51.
Table A-13: Script Execution Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Creating a Non Super
User Server Script
Manage Server Script: Read &
Write
N/A Write
Creating a Super User
Server Script
Write
Allow Control of Super User
Server Scripts: Yes
N/A Write
Creating an OGFS
Script
Manage OGFS Script: Read &
Write
N/A Write
Opening (Viewing all
script properties except
script contents) a Non
Super User Server
Script
Manage Server Script: Read N/A Execute
script properties
including script
contents) a Non Super
User Server Script
Manage Server Script: Read N/A Read
264
script contents) a Super
User Server Script
Manage Server Script: Read
Server Scripts: Yes
N/A Execute
script properties
including script
contents) a Super User
Server Script
Server Scripts: Yes
N/A Read
script contents) an
OGFS Script
Manage OGFS Script: Read N/A Execute
script properties
including script
contents) an OGFS
Script
Manage OGFS Script: Read N/A Read
Editing Non Super User
Server Script Properties
Write
Note: The Allow Control of
Super User Server Scripts: Yes
permission is required to edit
the script property, Can Run as
Super User.
N/A Write
Table A-13: Script Execution Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
265
Editing a Super User
Server Script
and Write
Server Scripts: Yes
N/A Write
Editing OGFS Script
Properties
Manage OGFSr Script: Read &
Write
N/A Write
Locating Server Script
in Folders
Locating OGFS Script in
Folders
Exporting a Server
Script
Exporting an OGFS
Script
Renaming a Server
Script
Write
N/A Write
Renaming a Super User
Server Script
Write
Server Scripts: Yes
N/A Write
Renaming an OGFS
Script
Write
N/A Write
Deleting a Server Script Manage Server Script: Read &
Write
N/A Write
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
266
Deleting a Super User
Server Script
Write
Server Scripts: Yes
N/A Write
Deleting an OGFS
Script
Write
N/A Write
Running Server Script
as Super User
Managed Servers and Groups:
Yes
Read and Write Execute
as a Super User (by
copying the script
contents from another
script)
Run Ad-Hoc Scripts: Yes
Run Ad-Hoc Scripts and Source
Visible Server Scripts as Super
User: Yes
Yes
Read and Write Read
as a specified user
Yes
as a specified user (by
copying the script
contents from another
script)
Yes
Read and Write Read
Running Ad-Hoc
Scripts
Yes
Read and Write N/A
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
267
Table A-14 lists the actions that users can perform for each Script Execution permission.
Table A-14 has the same data as Table A-13, but is sorted by feature permission. For
security administrators, Table A-14 answers this question: If a user is granted a particular
feature permission, what actions can the user perform?
Running Ad-Hoc
Scripts
as super user
User: Yes
Yes
Read and Write N/A
Running OGFS Scripts N/A N/A Execute
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Table A-14: User Actions Allowed by Script Execution Permissions
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Manage Server Script:
Read & Write
Creating a Non Super User
Server Script
N/A Write
Editing Non Super User Server
Script Properties
N/A Write
Deleting a Non Super User
Server Script
N/A Write
Renaming a Non Super User
Server Script
N/A Write
268
Read
Opening (Viewing all script
properties including script
contents) a Non Super User
Server Script
properties including script
contents) a Super User Server
Script
N/A Read
Locating Server Script in Folders N/A Read
Exporting Server Scripts N/A Read
Read
properties excluding script
contents) a Non Super User
Server Script
properties excluding script
contents) a Super User Server
Script
Execute
Read & Write
And
Allow Control of Super
User Server Scripts: Yes
Creating a Super User Server
Script
N/A Write
Table A-14: User Actions Allowed by Script Execution Permissions (continued)
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
269
Editing Super User Server Script
Properties
Editing Non Super User Server
Script Properties
N/A Write
Renaming a Super User Server
Script
Renaming a Non Super User
Server Script
N/A Write
Deleting a Super User Server
Script
Deleting a Non Super User
Server Script
N/A Write
Manage OGFS: Read &
Write
Creating an OGFS Script N/A Write
Editing OGFS Script Properties N/A Write
Deleting an OGFS Script N/A Write
Renaming an OGFS Script N/A Write
Manage OGFS Script:
Read
Opening (Viewing all the OGFS
Script Properties, including
script contents) an OGFS Script
N/A Read
Locating OGFS in Folders N/A Read
Exporting OGFS Scripts N/A Read
Manage OGFS Script:
Read
Opening (Viewing all the OGFS
Script Properties, excluding
script contents) an OGFS Script
N/A Execute
Run Ad-Hoc Scripts Running Ad-Hoc scripts Read and Write N/A
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
270
The following table lists the script execution permissions required for running scripts using
a software policy
Run Ad-Hoc Scripts
and Source Visible
Server Scripts as Super
User
Running Ad-Hoc scripts as
super User
Read and Write N/A
N/A Running Non Super User Server
Script
N/A Running Private Scripts Read and Write Execute (on Home
folder)
N/A Running OGFS Scripts N/A Execute
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Table A-15: Script Execution Permissions Required for Software Management
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
Adding a Server Script
to a software policy
Manage Server Scripts: Read N/A Read
to the Options step in
the Remediate window
N/A N/A Execute
271
the Remediate window
(Copying the script
contents)
N/A Read
Adding a Super User
Server Script to the
Options step in the
Remediate window
User: Yes
N/A Read
Specifying an Ad-Hoc
Script to the Options
step in the Remediate
window
Run Ad-Hoc Scripts: Yes N/A N/A
Specifying an Super
User Ad-Hoc Script to
the Options step in the
Remediate window
User: Yes
N/A N/A
the Install Software
window
N/A N/A Execute
the Install Software
window (Copying the
script contents)
N/A Read
Table A-15: Script Execution Permissions Required for Software Management (continued)
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
272
Audit and Remediation Permissions
Table A-16 specifies the Audit and Remediation permissions required by users to perform
Adding a Super User
Server Script to the
Options step in the
Install Software window
User: Yes
N/A Read
Specifying an Ad-Hoc
Script to the Options
step in the Install
Software window
Run Ad-Hoc Scripts: Yes N/A N/A
Specifying an Super
User Ad-Hoc Script to
the Options step in the
Install Software window
User: Yes
N/A N/A
Table A-15: Script Execution Permissions Required for Software Management (continued)
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
PERMISSIONS
273
Server Permissions for Audit and Remediation
Audit and Remediation actions require both feature and server feature permissions. For
example, the Create Audit action requires the feature permission Manage Audit: Read &
Write and the Managed Servers and Groups feature permission. This action also needs
Read permission on the server referenced by the Audit. In Table A-16, the Server
Permission column is for the servers referenced by the Audit or Snapshot Specification
depending on the action. Server permissions are specified by the customer, facility, and
device groups permissions in the SAS Web Client.
If an Audit and Remediation object (such as a Snapshot Specification) references multiple
servers, at least Read permission is required for all servers referenced. Otherwise, the
object cannot be viewed or modified.
Audit and Remediation objects are not directly associated with customers and facilities.
but customer and facility permissions do control access to servers which are referenced
by Audit and Remediation objects, such as Snapshot Specifications and Audits.
OGFS Permissions for Audit and Remediation
For the actions that access a managed servers file system, the OGFS Read Server File
System permission is required. For example, the Read Server File System permission is
required to create a Snapshot Specification with rules that include the files of a managed
server. Such Rules include and Application Configurations, Custom Scripts, COM+
objects, File System, IIS Metabase entries, and Windows Registry.
Other types of selection criteria require the corresponding OGFS permissions:
Read Server Registry
Read COM+ Database
Read IIS Metabase
274
Audit and Remediation User Action Permissions
The following table lists typical Audit and Remediation user actions and the permissions
required to perform them.
Table A-16: Audit and Remediation Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Snapshot Specification
View contents of Snapshot
Specification
Manage Snapshot
Specification: Read
N/A Read
Schedule and run a Snapshot
Specification
Manage Snapshot
Specification: Read
N/A Read
Create Snapshot Specification Manage Snapshot
Specification: Read & Write
N/A Read & Write
Create Application
Configuration Rule
Manage Snapshot
Allow Create Task Specific
Policy: Yes
Write Server File
System
Read & Write
Create COM+ Rule Manage Snapshot
Policy: Yes
Read COM+
Database
Read & Write
Create Custom Script Rule Manage Snapshot
Policy: Yes
Allow Create Custom Script
Policy Rules: Yes.
Write Server File
System
Read & Write
275
Create Files Manage Snapshot
Policy: Yes
Write Server File
System
Read & Write
Create IIS Metabase Rule Manage Snapshot
Policy: Yes
Read IIS
Metabase
Read & Write
Create Registry Rule Manage Snapshot
Policy: Yes
Read Server
Registry
Read & Write
Link Audit Policy into Snapshot
Specification
Manage Snapshot
Manage Audit Policy: Read
LIbrary Folder: Read
N/A Read & Write
Import Audit Policy into
Snapshot Specification
Manage Snapshot
Library Folder: Read
N/A Read & Write
Save As Audit Policy Manage Snapshot
Manage Audit Policy: Read &
Write
Library Folder: Read & Write
N/A Read & Write
Table A-16: Audit and Remediation Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
276
Snapshots
View, list contents of a
Snapshot
Manage Snapshot: Read
Manage Snapshot
Specification: Read
N/A Read
Create Audit from Snapshot Manage Snapshot: Read
Manage Snapshot
Specification: Read
Manage Audit: Read
N/A Read
View Archived Snapshot Manage Snapshot: Read N/A Read
Create Audit from archived
Snapshot
Manage Audit: Read
N/A Read
Delete Snapshot results Manage Snapshot:
Read & Write
N/A Read & Write
Detach Snapshot from a server Allow General Snapshot
Management: Yes
Manage Snapshot: Read &
Write
Manage Snapshot
Specification: Read
N/A Read
Remediate Snapshot results Manage Snapshot: Read
Manage Snapshot
Specification: Read
Allow Remediate Audit/
Snapshot Results: Yes
N/A Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
277
Remediate Snapshot Results:
Manage Snapshot
Specification: Read
Write Server File
System
Read & Write
COM+
Manage Snapshot
Specification: Read
Read COM+
Database
Read & Write
Custom Scripts
Manage Snapshot
Specification: Read
Write Server File
System
Read & Write
File System
Manage Snapshot
Specification: Read
Write Server File
System
Read & Write
Metabase
Manage Snapshot
Specification: Read
Read IIS
Metabase
Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
278
Registry
Manage Snapshot
Specification: Read
Read Server
Registry
Read & Write
Audits
View an Audit Manage Audit: Read N/A Read
Schedule and run an Audit Manage Audit: Read
Manage Audit Result: Read &
Write
N/A Read
Create an Audit Manage Audit: Read & Write N/A Read & Write
Create Application
Configuration Rule
Manage Audit: Read & Write
Policy: Yes
Write Server File
System
Read & Write
Create COM+ Rule Manage Audit: Read & Write
Policy: Yes
Read COM+
Database
Read & Write
Create Custom Script Rule Manage Audit: Read & Write
Policy Rules: Yes
Policy: Yes
Write Server File
System
Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
279
Create Discovered Software
Rule
Manage Server Modules: Read
Policy: Yes
N/A Read & Write
Create Files Rule Manage Audit: Read & Write
Policy: Yes
Write Server File
System
Read & Write
Create Hardware Rule Manage Audit: Read & Write
Policy: Yes
N/A Read & Write
Create IIS Metabase Rule Manage Audit: Read & Write
Policy: Yes
Read IIS
Metabase
Read & Write
Create Internet Information
Server Rule
Policy: Yes
N/A Read & Write
Create Registered Software
Rule
Policy: Yes
N/A Read & Write
Create Runtime State Rule Manage Audit: Read & Write
Policy: Yes
N/A Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
280
Create Software Rule Manage Audit: Read & Write
Policy: Yes
N/A Read & Write
Create Storage Rule Manage Audit: Read & Write
Policy: Yes
N/A Read & Write
Create Weblogic Rule Manage Audit: Read & Write
Policy: Yes
N/A Read & Write
Create .NET Framework
Configurations Rule
Policy: Yes
N/A Read & Write
Create Windows Registry Rule Manage Audit: Read & Write
Policy: Yes
Read Server
Registry
Read & Write
Create Windows Services Rule Manage Audit: Read & Write
Policy: Yes
N/A Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
281
Create Windows/Unix Users
and Groups Rule
Policy: Yes
N/A Read & Write
Link an Audit Policy into an
Audit
Policy: Yes
SA Client Library Folder: Read
N/A Read & Write
Import an Audit Policy into an
Audit
Library Folder: Read
N/A Read & Write
Save as Audit Policy Manage Audit: Read & Write
write
Library Folder: Read & Write
N/A Read & Write
Audit Results
View Audit Results Manage Audit Results:
Read
Manage Audit: Read
N/A Read
View Archived Audit Results Manage Audit: Read N/A Read
Delete Audit Results Manage Audit Results:
Read & Write
N/A Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
282
Remediate Audit Results Manage Audit: Read
Manage Audit Results: Read &
Write
N/A Read & Write
Remediate Audit Results:
Manage Audit: Read
Write
Write Server File
System
Read & Write
COM+
Manage Audit: Read
Write
Read COM+
Database
Read & Write
Custom Script Rule
Manage Audit: Read
Write
Write Server File
System
Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
283
Discovered Software
Manage Audit: Read
Write
Manage Server Module: Read
Allow Execute Server Modules:
Yes
N/A Read & Write
Remediate Audit Results: Files Manage Audit: Read
Write
Write Server File
System
Read & Write
Remediate Audit Results: IIS
Metabase
Manage Audit: Read
Write
Read IIS
Metabase
Read & Write
Remediate Internet Information
Server
Manage Audit: Read
Write
Read IIS
Metabase
Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
284
Remediate Discovered
Software
Manage Audit: Read
Write
Yes
N/A Read & Write
Remediate Software
Manage Audit: Read
Write
N/A Read & Write
Remediate Storage
Manage Audit: Read
Write
Yes
N/A Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
285
Remediate Weblogic
Manage Audit: Read
Write
Yes
N/A Read & Write
Remediate Windows .NET
Framework Configurations
Manage Audit: Read
Write
Yes
N/A Read & Write
Windows Registry
Manage Audit: Read
Write
Read Server
Registry
Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
286
Table A-17 lists the actions that users can perform for each Audit and Remediation
permission is required for all Audit and Remediation actions.
Windows Services
Manage Audit: Read
Write
N/A Read & Write
Remediate Windows/Unix
Users and Groups
Manage Audit: Read
Write
Yes
N/A Read & Write
USER ACTION
FEATURE
PERMISSION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
287
For security administrators, Table A-17 answers this question: If a user is granted a partic-
ular feature Audit and Remediation permission, what actions can the user perform?
Table A-17: User Actions Allowed by Audit and Remediation Permissions
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Rule Policy: No
and
Manage Audit: Read
View Custom Script Rule: Audit N/A Read
Rule Policy: Yes
and
Create Custom Script Rule:
Audit
Write Server File
System
Read & Write
Rule Policy: No
and
Write
View Custom Script Rule:
Snapshot
N/A Read
Rule Policy: Yes
and
Write
Create Custom Script Rule:
Snapshot
Write Server File
System
Read & Write
Allow General
Snapshot Management: Yes
Detach Snapshot from a server N/A Read
288
Manage Snapshot Specifica-
tion: Read
and
Allow Remediate Audit/Snap-
shot Results: No
and
Manage Audit or Manage
Snapshot: Read
View Audit or Snapshot, No
Remediation
N/A Read
tion: Read
and
shot Results: Yes
and
Snapshot: Read & Write
Remediate Audit/Snapshot
Results
N/A Read & Write
Table A-17: User Actions Allowed by Audit and Remediation Permissions (continued)
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
289
tion: Read
and
shot Results: Yes
and
Snapshot Results: Read &
Write
Remediate Application Configu-
ration Rule
Write Server File
System
Read & Write
Remediate COM+ Rule Read COM+
Database
Read & Write
Remediate Custom Script Rule
Registry Rule
Write Server File
System
Read & Write
Remediate File System Rule Read IIS
Metabase
Read & Write
Remediate IIS Metabase Rule Read Server
Registry
Read & Write
Remediate Windows Registry
Rule
Write Server File
System
Read & Write
Manage Audit: Read View, schedule, run Audit N/A Read
and
Allow Create Task Specific Pol-
icy: Yes
Create, edit, delete Audit N/A Read & Write
Save Audit as Audit Policy N/A Read & Write
Link Audit Policy into Audit N/A Read & Write
tion Rule
Write Server File
System
Read & Write
Create COM+ Rule Read COM+
Database
Read & Write
Create File System Rule Write Server File
System
Read & Write
Create IIS Metabase Rule Read IIS
Metabase
Read & Write
Create Window Registry Rule Read Server
Registry
Read & Write
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
290
and
Policy Rules: Yes
and
Allow Create Task Specific Pol-
icy: Yes
Create Custom Scripts Rule Write Server File
System
Read & Write
and
and
Policy
Create the following Audit
Rules:
Discovered Software
Registered Software
Runtime State
Storage
Weblogic
Windows .NET Framework
Configurations
Windows Users and Groups
N/A Read & Write
Manage Audit Results: Read View Audit Results N/A Read
Write
Delete Audit Results N/A Read & Write
tion: Read & Write
View, schedule, run Snapshot
Specification
N/A Read
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
291
tion: Read & Write
and
Policy
Create, edit, and delete Snap-
shot Specification
N/A
Save Snapshot Specification as
Audit Policy
(This action requires REad &
Write for the library folder where
policy lives.)
N/A
Link Audit Policy Into Audit N/A Read & Write
tion Rule
Write Server File
System
Read & Write
Database
Read & Write
Create Discovered Software
System
Read & Write
Metabase
Read & Write
Create Windows Registry Rule Read Server
Registry
Read & Write
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
292
tion: Read & Write
and
and
Policy
Create the following Snapshot
Rules:
Discovered Software
Registered Software
Runtime State
Storage
Weblogic
Configurations
N/A Read & Write
tion: Read & Write
and
Create Custom Script Policy
Rule
and
Policy
Create Custom Rule for Snap-
shot Specification
Write Server File
System
Read & Write
Manage Snapshot: Read View contents of Snapshot N/A Read
Manage Snapshot:
Read & Write
Delete Snapshot results N/A Read & Write
Manage Audit Policy: Read View contents of Audits and
Snapshot Specifications
N/A Read
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
293
Manage Audit Policy:
Read & Write
Create, edit Audit Policy. N/A Read & Write
tion Rule
Write Server File
System
Read & Write
Database
Read & Write
System
Read & Write
Metabase
Read & Write
Create Windows Registry Rule Read Server
Registry
Read & Write
Write
Create the following Snapshot
Rules:
Discovered Software
Registered Software
Runtime State
Storage
Weblogic
Configurations
N/A Read & Write
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
294
Service Automation Visualizer Permissions
Table A-18 specifies the Service Automation Visualizer (SAV) permissions required to
perform specific actions in the SA Client. For security administrators, the table answers
this question: To perform a particular action, what permissions does a user need?
the SA Client. In addition to feature permissions, server read permissions are required on
the managed servers affected by the analyze operation, such as permissions to open a
Remote Terminal or a Remote Desktop Client, open the Device Explorer, and open a
Global Shell session from the Service Automation Visualizer.
SAV permissions required to scan a server are the same for both physical servers and
virtual servers.
Manage Audit Policy:
Read & Write
and
Policy Rule
Create Custom Script Rule Write Server File
System
Read & Write
FEATURE
PERMISSION
USER ACTION
OGFS
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
295
For details on this feature, see the Service Automation Visualizer chapter in the SA
Users Guide: Application Automation.
Table A-18: SAV Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
SOURCE SERVER
PERMISSION
(CUSTOMER,
FACILITY)
FOLDER
PERMISSION
SAV-Only Operations
Launch the Service Automation
Visualizer
Allow Analyze: Yes Read N/A
Generate a scan or refresh Snap-
shot regular or virtual servers
Allow Analyze: Yes Read N/A
Create a Snapshot or edit a sched-
uled Snapshot
Allow Analyze: Yes
Manage Business
Applications: Read &
Write
Read N/A
Start, stop, pause, restart virtual
server inside of SAV (pause VM for
VMware only cannot pause a
Solaris local zone)
Administer Virtual
Server: Yes
Read N/A
SA Client Operations
Run script (as a non-Super User) Run Ad-hoc Scripts:
Yes
Read and Write N/A
Run script (as a Super User) Run Ad Hoc & Source
Visible Server Scripts
As Super User: Yes
Read and Write N/A
Execute OGFS script Manage OGFS
Scripts: Yes
Read and Write N/A
ASAS Operations
Viewing SAN arrays or NAS filer data,
including relationships.
View Storage
Systems: Yes
Read N/A
296
In order to save a Business Application to a users own home directory in the Library, for
example, /home/username, this users private user group will also need to have the
Manage Business Applications permission set to Yes. For more information, see the User
Group and Setup chapter in the Administration Guide.
Viewing Storage in SAV and SA Permissions.
Your user may be able to view some types of storage information in a SAV snapshot even
if your user belongs to any groups that do not have permission to see storage devices
such as SAN fabrics, arrays, and so on.
Specifically, If your user belongs to one or more groups that have the permission Manage
Business Applications: Read & Write, then your user will be able to view such devices in
a SAV snapshot and objects as fabrics (switches), storage arrays, network devices, and
VM info in the SAV snapshot, even if the group does not have individual permissions
granted to see those devices and objects.
Viewing any SAN switch data,
including relationships
View Storage Sys-
tems: Yes
Read N/A
SA Client Folder Operations
Open a Business Application from a
folder
N/A N/A Read Objects
Within Folder
Create a Business Application and
save to a folder
Manage Business
Applications: Yes
N/A Write Objects
Within Folder
Rename a Business Application
inside a folder
N/A N/A Write Objects
Within Folder
Delete a Business Application from a
folder
Within Folder
Cut, copy, or paste a Business
Application from a folder
Within Folder
Table A-18: SAV Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
SOURCE SERVER
PERMISSION
(CUSTOMER,
FACILITY)
FOLDER
PERMISSION
297
If your user belongs to one or more groups that do not have Manage Business
Applications: Read & Write, your user will be able to view SAN fabrics (switches), storage
arrays, network devices, and VM info in a SAV snapshot only if the group has those
individual permissions granted.
For example, if your user belonged to one or more groups that have the following
permission: Manage Business Applications: Read & Write but had Manage Fabrics:
None, your user would still be able to see fabrics (and SAN switches) in the SAV
snapshot.
Virtualization Director Permissions
Table A-19 specifies the Virtualization Director permission required to perform specific
actions in the SA Client. For security administrators, the table answers this question: To
perform a particular action, what permissions does a user need?
the SA Client.
In addition to feature permissions, server read permissions are required on hypervisor
servers. Once you have created a new virtual server, then its permissions are treated just
like a regular physical server, including OS Provisioning.
For details on this feature, see the Virtualization Director chapter in the SA Users Guide:
Server Automation.
Table A-19: Virtualization Director Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
HYPERVISOR
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
View the Virtual Servers feature in the SA
Client navigation panel
View virtualization object in a virtual
servers device explorer
View Virtual Servers: Yes
(Note: If this permission is
set to No, you will still be
able to see virtual servers in
the All Managed Servers
list.)
Read on the
hypervisor
server
298
Table A-20 lists the actions that users can perform for each Virtualization Director
permission. For security administrators, Table A-20 answers this question: If a user is
granted a particular feature Virtualization Director permission, what actions can the user
perform?
Refresh a hypervisor server View Virtual Servers: Yes Read on the
hypervisor
server
Create, modify, or remove a virtual server View Virtual Servers: Yes
Manage Virtual Servers: Yes
Read on the
hypervisor
server
Start and stop a Solaris zone View Virtual Servers: Yes
Administer Virtual Servers:
Yes
Read on the
hypervisor
server
Power on, power off, suspend, or reset a
VMware virtual machine
Yes
Read on the
hypervisor
server
Use the ESX VM Creation wizard Allow Configuration of
Network Booting Server
Read/Write to
the Facility and
Customer
Folder
Table A-19: Virtualization Director Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
HYPERVISOR
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
299
OS Provisioning Permissions
The following section describes the OS Provisioning permissions required by users to
perform specific actions in the SA. For security administrators, the following table answers
this question: To perform a particular action, what permissions does a user need?
In Table A-21, the Server Permission column is for the servers referenced by the OS
sequence or installation profile. Server permissions are specified by the Customer, Facility,
and Device Groups permissions in the SAS Web Client.
With the OS Provisioning feature in the SAS Web Client, in order to create and save an OS
sequence you must save it in a folder, so you will need write permissions to the folder.
Table A-20: User Actions Allowed by Virtualization Director Permissions
FEATURE
PERMISSION
USER
ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Manage Virtual Servers: No
View the Virtual Servers feature in the SA
Client navigation panel and virtual servers
in the Contents pane.
View virtualization object in a virtual
servers device explorer
Refresh a hypervisor server
Read on the
hypervisor
server
Create, modify, or remove a virtual server Read on the
hypervisor
server
Yes
Start and stop a Solaris zone
Power on, power off, suspend, or reset a
VMware virtual machine
Read on the
hypervisor
server
300
See Customer Permissions and Folders on page 73 in this chapter for more information.
Table A-21: OS Provisioning Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER PERMISSION
OS Sequence
Create OS
Sequence
Manage OS
Sequence:
Read & Write
None Write
View OS
Sequence
Manage OS
Sequence:
Read
None Read
Edit OS Sequence Manage OS
Sequence:
Read & Write
None Write
Delete OS
Sequence
Manage OS
Sequence:
Read & Write
None Write
Run OS Sequence
(From server or
from OS
sequences)
Manage OS
Sequence:
Read
and
Allow Execute
OS Sequence:
Yes
Read & Write Read
View
unprovisioned
servers
SA Web Client
permission:
Server Pool
Read N/A
301
OS Installation Profile
Create, edit, delete
OS installation
profile
Wizard: Prepare
OS
Read N/A
Unprovisioned Server List
View servers in the
unprovisioned
server list
Server Pool N/A N/A
Manage Boot Clients
Execute Managed
Boot Clients Web
Application
Allow
Configuration of
Network
Booting
Read/Write to
the Facility and
Customer
List and Execute on the
/Opsware/Tools
/OS Provisioning
/Manage Boot Clients
folder
Table A-21: OS Provisioning Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER PERMISSION
302
Table A-22 lists the actions that users can perform for each OS Provisioning permission.
Table A-22 has the same data as Table A-21, but is sorted by feature permission.
Table A-22: User Actions Allowed in the SA Client by OS Provisioning Permissions
FEATURE
PERMISSION
USER ACTION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
FOLDER
Manage OS Sequence: Read View OS sequence Read Read
Manage OS Sequence: Read &
Write
Manage OS Sequence: Read &
Write
Run OS sequence Write Write
Create OS sequence Read Write
Allow Execute OS Sequence: Yes Run OS sequence Write Read
Allow Execute OS Sequence: No View OS sequence N/A Read
Manage OS Sequence: Read
Allow execute OS Sequence: Yes
Run OS sequence Write Read
Manage OS Sequence: Read
Allow Execute OS Sequence: No
View OS sequence Read Read
Manage OS Sequence: Write
Allow Execute OS Sequence: Yes
Run OS sequence
Edit OS sequence
Write Write
Manage OS Sequence: Write
Allow Execute OS Sequence: No
Edit OS sequence Read Write
Wizard: Prepare OS Create, edit, delete OS
installation profile
Read & Write,
N/A,
N/A
N/A
Server Pool View servers in the
unprovisioned server list
Read N/A
303
Compliance View Permissions
The following section describes the Compliance View permissions required by users to
perform specific actions in the SA Client. For security administrators, the following table
answers this question: To perform a particular action, what permissions does a user
need?
Table A-23: Compliance View Permissions Required for User Actions
USER ACTION
FEATURE
PERMISSION
SERVER PERMISSION
(CUSTOMER,
FACILITY, DEVICE
GROUP)
Audit
View Details Manage Audit Result: Read Read
Run Audit Manage Audit: Read
Manage Audit Result: Read & Write
Read & Write
Remediate Allow Remediate Audit/Snapshot Result:
Yes
For other permissions needed to
remediate for specific audit rules, see
Audit and Remediation User Action
Permissions on page 274, Table A-17.
Read & Write
Software
Remediate Manage Software Policy: Read
Read & Write
Scan Device Manage Software Policy: Read
Or
Allow Attach/Detach Software Policy: Yes
Or
Allow Install/Uninstall Software: Yes
Or
Read & Write
304
Patch
Remediate Manage Patch Policy: Read
Install Patch: Yes
Read & Write
Scan Device Manager Patch: Read
Or
Manage Patch Policy: Read
Or
Or
Or
Allow Install/Uninstall Software
Or
Allow Remediate Servers
Read & Write
App Config
Viewing Details Manage Application Configurations: Read Read
Scan Device Allow Configuration Compliance Scan: Yes Read
Specific App
Config
Remediation
See Application Configuration
Management Permissions on page 232
for permissions required for remediating
Application Configurations.
Read & Write
Table A-23: Compliance View Permissions Required for User Actions (continued)
USER ACTION
FEATURE
PERMISSION
SERVER PERMISSION
(CUSTOMER,
FACILITY, DEVICE
GROUP)
305
Table A-7 specifies the permissions required by users to modify server properties, reboot
servers, and deactivate servers. For security administrators, the table answers this
Server Objects Permission
Table A-25 specifies the permissions required for server objects such as Registered
Software, Internet Information Server, Local Security Settings, Runtime State, Users and
Groups, and .Net Framework Configuration.
Table A-24: Server Property and Reboot Permissions Required for User Actions
USER
ACTION
FEATURE
PERMISSION
SERVER
PERMISSION
(CUSTOMER,
FACILITY,
DEVICE
GROUP)
Deactivate Server Deactivate Read & Write
Modify Property: Server Name or
Description
N/A Read & Write
Reboot Server Reboot Server: Yes Read & Write
Table A-25: Server Object Permissions
SERVER PERMISSION
(CUSTOMER, FACILITY,
DEVICE GROUP)
FOLDER
PERMISSIONS
Browse Server Objects Manage Server
Modules: Read & Write
Allow Execute Server
Modules: Yes
N/A N/A
306
Predefined User Group Permissions
The following table lists the permissions of the predefined user groups for the features in
the SAS Web Client. An X in a table cell indicates that the group has permission to use
the feature. The headings in the table columns abbreviate the names of the user groups
as follows:
Basic: Basic Users
Inter: Intermediate Users
Adv: Advanced Users
OSA: SA System Administrators
Add to Library (From
the Server Browser)
Manage Server
Modules: Read & Write
Modules: Yes
Manage Package:
Read and Write
Write
Add to Software Policy Manage Server
Modules: Read and
Write
Modules: Yes
Manage Package:
Read and Write
Manage Software
N/A Write
Table A-25: Server Object Permissions (continued)
SERVER PERMISSION
(CUSTOMER, FACILITY,
DEVICE GROUP)
FOLDER
PERMISSIONS
307
Admin: Administrators
Table A-26: SAS Web Client Permissions of the Predefined User Groups
FEATURE NAME BASIC INTER ADV OSA ADMIN
FEATURE TAB
Configuration Tracking X X X
Configure SA X
Customers X X X X
DNS X X X
Data Center Intelligence Reports X X
Facilities X X X X
IP Ranges and Range Groups X X X
ISM Controls X X X
Manage Gateway X
Managed Servers and Groups X X X X
Model: Hardware X X X
Model: Opsware X
Model: Service Levels X X X
Multimaster X
Operating Systems X X
Server Attributes X X
Server Pool X X
System Diagnosis X X
Wizard: Custom Extension X X
Wizard: Prepare OS X X X
OTHER TAB
Deactivate X X
Allow Run Refresh Jobs
Manage Public Device Groups X
308
Only the Administrator group also has permission to manage SA users and user groups, a
feature not listed on the SAS Web Client tabs.
The following table lists the permissions of the predefined user groups for the SA Client
features.
The table cells contain the following abbreviations:
R: Read (only)
RW: Read & Write
Y: Yes
N: No or None
Model Public Device Groups
View All Jobs
Edit All Jobs
Table A-27: SA Client Permissions of the Predefined User Groups
APPLICATION CONFIGURATION
Configuration N R RW N N
Configuration Files N R RW N N
Configuration on Servers N R RW N N
Allow Check Consistency on Servers N N Y N N
COMPLIANCE
Audit Templates N R RW N N
Audit Results N R RW N N
Snapshot Templates N R RW N N
Snapshots (specific to servers) N R RW N N
Selection Criteria N R RW N N
Table A-26: SAS Web Client Permissions of the Predefined User Groups (continued)
309
When SA is first installed, default permissions are assigned to the top-level folders of the
SAS Web Client. The following table lists these default permissions. The table uses the
following abbreviations for permissions:
L: List Contents of Folder
R: Read Objects Within Folder
W: Write Objects Within Folder
Allow General Snapshot
Management
N Y Y N N
AGENT DEPLOYMENT
Allow Deploy Agent N N Y N N
Allow Scan Network N N Y N N
PATCH MANAGEMENT
Manage Patch N N RW N N
Manage Patch Policy N N RW N N
Allow Install Patch N N Y N N
Allow Uninstall Patch N N Y N N
Manage Patch Compliance Rules N N N N N
SCRIPT MANAGEMENT
(FRESH INSTALL - 7.0/7.5)
Manage Server Scripts RW RW RW RW N
Server Scripts
N N Y Y N
Run Ad Hoc Scripts Y Y Y Y N
Run Ad Hoc & Source Visible Server
Scripts As Super User
N Y Y Y N
Manage OGFS Script RW RW RW RW N
Table A-27: SA Client Permissions of the Predefined User Groups (continued)
310
P: Edit Folder Permissions
Table A-28: Default Top-Level Folder Permissions of the Predefined User Groups
FOLDER BASIC INTER ADV OSA ADMIN
/ L L W L P
/Opsware L L L P
/Opsware/Tools L L L P
Opsware/Tools/Agent Deployment
Helper
R W P
/Opsware/Tools/ISMTOOL R W P
/Package Repository R W P
/Package Repository/All AIX R W P
/Package Repository/All AIX/AIX
<version>
R W P
/Package Repository/All HP-UX R W P
/Package Repository/All HP-UX/HP-
UX <version>
R W P
/Package Repository/All Red Hat
Linux
R W P
Package Repository/All Red Hat
Linux/Red Hat Linux <version>
R W P
/Package Repository/All SunOS R W P
/Package Repository/All SunOS/
SunOS <version>
R W P
/Package Repository/All SuSE Linux R W P
/Package Repository/All SuSE Linux/
SuSE Linux <version>
R W P
/Package Repository/All Windows R W P
/Package Repository/All Windows/
Windows <version>
R W P
311
Private User Groups (PUG) Permissions
Private user groups are new as of SA 7.0. Private user groups are created for each
pre-existing user during a pre-SA 7.0 core upgrade to SA 7.50 or later.
The following table lists the script management and folder permissions of the private user
groups who were a member of the following pre-defined group(s) before the core was
upgraded from a pre-SA 7.0 release to SA 7.50. The headings in the table columns
abbreviate the names of the user groups as follows:
Basic: Basic Users
Inter: Intermediate Users
Adv: Advanced Users
OSA: SA System Administrators
Admin: Administrators
Table A-29: Script Management and folder permissions of Private User Groups
SCRIPT MANAGEMENT
(Upgrade from pre-7.0 to 7.5)
Server Scripts
N N Y Y N
Run Ad-hoc Scripts Y Y Y Y N
Run Ad Hoc & Source Visible Server
Scripts As Super User
N Y Y Y N
Manage OGFS Script N N N N N
Folder permission on
/Migrated/Scripts/Shared
Scripts folder
LRX LRX LRXW LRXW LE
312
Code Deployment User Groups
The following tables describe the capabilities of the Code Deployment user groups. For
more information, see the Accessing Code Deployment & Rollback section of the SA
Users Guide: Server Automation.
Table A-30: Special Code Deployment User Groups
CODE DEPLOYMENT USER
GROUP
DESCRIPTION
Super User Can define, request, or perform any code deployment
operation on hosts designated for either staging or
production. Because a Super User can perform
operations on hosts associated with any customer, only
a few users should belong to this group.
History Viewer Can view a log of operations (service operations,
synchronizations and sequences) that have been
previously executed from the Code Deployment feature.
Viewing this information can help you determine the
status of particular deployment operations, and whether
they completed successfully.
Table A-31: Service User Groups
GROUP
DESCRIPTION
Service Editor Can define a service, and modify or delete service
definitions.
Production Service Performer Can directly perform or request performance of service
operations on hosts designated for use in production.
Staging Service Performer Can directly perform or request performance of service
operations on hosts designated for use in staging.
Production Service Requester Can request performance of service operations on hosts
designated for use in production.
Staging Service Requester Can request performance of service operations on hosts
designated for use in staging.
313
Table A-32: Synchronization User Groups
GROUP
DESCRIPTION
Synchronization Editor Can define a synchronization, and modify or delete the
synchronization definition.
Synchronization Performer Can directly perform or request performance of a
synchronization action.
Synchronization Requester Can request performance of a synchronization action.
Table A-33: Sequence User Groups
GROUP
DESCRIPTION
Sequence Editor Can define a sequence, and modify or delete the
sequence definition.
Production Sequence
Performer
Can directly perform or request performance of a
sequence of actions on hosts designated for use in
production.
Staging Sequence Performer Can directly perform or request performance of a
sequence of actions on hosts designated for use in
staging.
Production Sequence
Requester
Can request performance of a sequence of actions on
hosts designated for use in production.
Staging Sequence Requester Can request performance of a sequence of actions on
hosts designated for use in staging.
314
315
Index
A
AAA utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
ACCESS.LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Accessing, realm information . . . . . . . . . . . . . . . . . 123
Activating users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Adding
users to a user group . . . . . . . . . . . . . . . . . . . . . . 64
users to CDR user groups . . . . . . . . . . . . . . . . . . 87
admin user . . . . . . . . . . . . . . . 56, 58, 61, 62, 64, 72, 75
admin. See also super administrator
Administrator. See also super administrator
Agent
Cache Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Cache monitoring . . . . . . . . . . . . . . . . . . . . . . . . 192
Cache Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
monitoring processes . . . . . . . . . . . . . . . . . . . . . 190
AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Reachability Communication Tests . . . . . . . . . . 189
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Agent cache
monotoring processes . . . . . . . . . . . . . . . . . . . . 192
Agent Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Agent Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Application Configuration Management,
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Approval dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Auditverify tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Authentication
Credential Store . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
external LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
HP Network Automation . . . . . . . . . . . . . . . . . . . . 62
B
Backup, deleting files . . . . . . . . . . . . . . . . . . . . . . . . 178
Banner message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Boot Server
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Build Agent
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Build Manager
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
C
CDR. See Code Deployment & Rollback.
Code deployment
configuring, email alert addresses . . . . . . . . . . . 224
user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Code deployment user groups
adding users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Command Center
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Command Engine
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
system diagnostic tests . . . . . . . . . . . . . . . . . . . 146
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Components
system diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . 188
configuration
316
SA configuration parameters . . . . . . . . . . . . . . . 220
Configuring
contact information . . . . . . . . . . . . . . . . . . . . . . . 220
email alert addresses for multimaster . . . . . . . . 223
email alert addresses for SA core . . . . . . . . . . . 222
email notification addresses for CDR . . . . . . . . 224
JAAS login module . . . . . . . . . . . . . . . . . . . . . . . . 85
mail server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Conflicts
alert emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
error messages . . . . . . . . . . . . . . . . . . . . . . . . . . 113
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
resolving . . . . . . . . . . . . . . . . . . . . . . . . . . . .103, 108
Constraints
customer and folder . . . . . . . . . . . . . . . . . . . . . . . 51
Content management, tools . . . . . . . . . . . . . . . . . . . 39
Core Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Creating
user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Creating, Manual updates . . . . . . . . . . . . . . . . . . . . 135
Credential Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Customer administrator . . . . . . . . . . . . . . 57, 64, 73, 74
Customer group . . . . . . . . . . . . . . . . . . . . . . . 57, 73, 74
D
Data Access Engine
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
reassigning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
See also Multimaster Central Data
Access Engine.
URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Data Center Intelligence reporting
required permissions . . . . . . . . . . . . . . . . . . . . . . 230
Delegated security . . . . . . . . . . . . . . . . . . . . . 59, 70, 74
Deleting
users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Deleting, backup files . . . . . . . . . . . . . . . . . . . . . . . . 178
Diagnosing, problems . . . . . . . . . . . . . . . . . . . . . . . 143
Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
permissions required . . . . . . . . . . . . . . . . . .240, 241
Discovery and Agent Deployment, overview . . . . . . 42
E
Editing
user information . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Email alert addresses
CDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
multimaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
SA core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Enabling, realm information . . . . . . . . . . . . . . . . . . . 121
F
Facilities
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
viewing, information . . . . . . . . . . . . . . . . . . . . . . 121
Facilities
definition of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
File system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Folder permissions . . . . . . . . . . . . . . . . . . . . . . . . 50, 69
G
Gateway
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Global File System
Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Agent Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Spoke
ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Global Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Grace login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
H
HP SA
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Index
317
I
IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Importing, external LDAP users . . . . . . . . . . . . . . . . . 85
Importing, server certificate from external
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Inactive
account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Inbound, Model Repository Multimaster
Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Installations
multiple Data Access Engine . . . . . . . . . . . . . . . 181
types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Integrating, SA with AIX and HP-UX . . . . . . . . . . . . . 41
IP range groups
IP ranges
J
JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
L
LDAP directory
Credential Store field . . . . . . . . . . . . . . . . . . . . . . . 62
external authentication . . . . . . . . . . . . . . . . . . . . . 78
importing, external users . . . . . . . . . . . . . . . . . . . . 85
importing, server certificate . . . . . . . . . . . . . . . . . 84
passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
process for using external LDAP . . . . . . . . . . . . . 79
supported external directory servers . . . . . . . . . . 79
Load Balancing Gateway
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Log
digital signatures . . . . . . . . . . . . . . . . . . . . . . . . . 169
Login approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Login failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Logs
about . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Boot Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Build Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Command Engine . . . . . . . . . . . . . . . . . . . . . . . . 162
configuring . . . . . . . . . . . . . . . . . . . . . . . . . .163, 171
Data Access Engine . . . . . . . . . . . . . . . . . . . . . . 162
Global Shell Audit . . . . . . . . . . . . . . . . . . . . . . . . 166
JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
managed servers
Global Shell logs . . . . . . . . . . . . . . . . . . . . . . 166
Media Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Model Repository . . . . . . . . . . . . . . . . . . . . . . . . . 163
Model Repository Multimaster Component . . . 163
SA Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Software Repository . . . . . . . . . . . . . . . . . . . . . . 164
Software Repository Replicator . . . . . . . . . . . . . 164
Web Services Data Access Engine . . . . . . . . . . 164
M
Manage environment, required permissions . . . . . 230
Management Gateway . . . . . . . . . . . . . . . . . . . . . . 119
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Manual updates
creating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Software Repository Cache, applying to . . . . . . 137
uploading, Microsoft utilities . . . . . . . . . . . . . . . . 137
Media Server
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Metabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Model Repository
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Inbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Outbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Model-based control . . . . . . . . . . . . . . . . . . . . . . . . . 24
Monitoring remote server access . . . . . . . . . . . . . . 168
Multimaster
alert emails during conflicts . . . . . . . . . . . . . . . . 112
configuring, mail server . . . . . . . . . . . . . . . . . . . . 221
conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
318
designating the Central Data Access Engine . . 183
error messages in multimaster conflicts . . . . . . 113
installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
network administration . . . . . . . . . . . . . . . . . . . . 112
preventing conflicts . . . . . . . . . . . . . . . . . . . . . . . . 96
tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Multimaster Central Data Access Engine . . . . . . . 183
Multimaster Central Data Access Engine Port
Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Multimaster Conflicts . . . . . . . . . . . . . . . . . . . . . . . . 204
multimaster, tools . . . . . . . . . . . . . . . . . . . . . . . . 97, 102
Multiple facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
N
Network administration . . . . . . . . . . . . . . . . . . . . . . 112
Network Automation (NA) . . . . . . . . . . . . . . . . . . . . . 62
O
OGFS
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
OGFS permissions . . . . . . . . . . . . . . . . . . . . . . . . 52, 70
On-demand updates
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Opsware guides
contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Oracle
monitoring
model repository . . . . . . . . . . . . . . . . . . . . . . 202
OS provisioning
Outbound, Model Repository Multimaster Component
29
P
Password
changing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
initial log on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
min and max characters . . . . . . . . . . . . . . . . . . . . 76
non-modifiable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
policy parameters . . . . . . . . . . . . . . . . . . . . . . . . . 75
reseting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
retention and re-use . . . . . . . . . . . . . . . . . . . . . . . 77
wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Patch management
uninstalling, patches . . . . . . . . . . . . . . . . . . . . . . . 36
updating, Microsoft patch . . . . . . . . . . . . . . . . . . . 37
uploading, patches . . . . . . . . . . . . . . . . . . . . . . . . 35
Permissions
customer and server . . . . . . . . . . . . . . . . . . . . . . . 49
delegated . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 70, 74
folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
folder and customer . . . . . . . . . . . . . . . . . . . . . . . 64
IP ranges and IP range groups, required for . . . 230
manage environment, required for . . . . . . . . . . 230
ODAD, required . . . . . . . . . . . . . . . . . . . . . . 240, 241
OGFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
OS Provisioning, required for . . . . . . . . . . . . . . . 229
other tasks, required . . . . . . . . . . . . . . . . . . . . . . 231
reports, required for . . . . . . . . . . . . . . . . . . . . . . . 230
SA Client permissions for user groups . . . . . . . 306
SA Web Client permissions for user groups . . 306
script management and execution,
required . . . . . . . . . . . . . . . . . . . . . . . . .50, 305
server management, required for . . . . . . . . . . . 230
setting
customer permissions . . . . . . . . . . . . . . . . . . 64
device group permissions . . . . . . . . . . . . . . . 66
facility permissions . . . . . . . . . . . . . . . . . . . . . 65
feature permissions . . . . . . . . . . . . . . . . . . . . 67
folder permissions . . . . . . . . . . . . . . . . . . . . . . 69
OGFS permissions . . . . . . . . . . . . . . . . . . . . . 70
other feature permissions . . . . . . . . . . . . . . . 69
SA Client feature permissions . . . . . . . . . . . . . . . 68
system configuration, required for . . . . . . . . . . . 231
viewing, users permissions . . . . . . . . . . . . . . . . . 62
Virtualization Director, required . . . . . . . . . . . . . 294
virtualization director, required . . . . . . . . . . . . . . 297
Preventing, conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Preview reconcile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Primary Data Access Engine . . . . . . . . . . . . . . . . . . 182
Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
R
RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Realms
enabling realm information . . . . . . . . . . . . . . . . . 121
viewing realm information . . . . . . . . . . . . . . . . . . 123
Realms
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Reassigning, Data Access Engine . . . . . . . . . . . . . 182
Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Remediate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Resolving
conflicts by object . . . . . . . . . . . . . . . . . . . . . . . . 103
conflicts by transaction . . . . . . . . . . . . . . . . . . . . 108
319
ROSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Running, system diagnosis . . . . . . . . . . . . . . . . . . . 147
S
SA
configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
configuration parameters . . . . . . . . . . . . . . . . . . 220
configuring, contact information . . . . . . . . . . . . . 220
core technology . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
integrating with AIX and HP-UX . . . . . . . . . . . . . . 41
model-based control . . . . . . . . . . . . . . . . . . . . . . . 24
related documentation . . . . . . . . . . . . . . . . . . . . . 19
security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
software provisioning . . . . . . . . . . . . . . . . . . . . . . 38
system diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . 143
tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . 143
types of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SA components
internal and external names . . . . . . . . . . . . . . . . 177
running, system diagnosis . . . . . . . . . . . . . . . . . 147
SA Web Client
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Satellite
accessing, realm information . . . . . . . . . . . . . . . 123
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
linked to cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
manual update . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
on-demand updates . . . . . . . . . . . . . . . . . . . . . . 130
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
permissions, required . . . . . . . . . . . . . . . . . . . . . 120
Software Repository Cache, overview . . . . . . . . 129
Satellite. See Satellite.
Scripts
Distributed Scripts
permissions required . . . . . . . . . . . . . . . . . . 305
Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Command Engine . . . . . . . . . . . . . . . . . . . . . . . . . 29
deleting backup files . . . . . . . . . . . . . . . . . . . . . . 178
Secondary Data Access Engine . . . . . . . . . . . . . . . 182
Security administrator overview . . . . . . . . . . . . . . . . 58
Server Agent
defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Server certificate
extracting
Microsoft Active directory from . . . . . . . . . . . 84
Novell eDirectory from . . . . . . . . . . . . . . . . . . 84
SunDS from . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
importing, external LDAP from . . . . . . . . . . . . . . . 84
Server management
required permissions . . . . . . . . . . . . . . . . . . . . . 230
Session timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Setting
customer permissions . . . . . . . . . . . . . . . . . . . . . . 64
device group permissions . . . . . . . . . . . . . . . . . . 66
facility permissions . . . . . . . . . . . . . . . . . . . . . . . . 65
feature permissions . . . . . . . . . . . . . . . . . . . . . . . . 67
folder permissions . . . . . . . . . . . . . . . . . . . . . . . . . 69
OGFS permissions . . . . . . . . . . . . . . . . . . . . . . . . 70
other feature permissions . . . . . . . . . . . . . . . . . . . 69
SA Client feature permissions . . . . . . . . . . . . . . . 68
Single-node installation . . . . . . . . . . . . . . . . . . . . . . . 25
Software provisioning
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
preview reconcile . . . . . . . . . . . . . . . . . . . . . . . . . . 38
remediate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Software Repository
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Software Repository Cache
applying, Manual updates . . . . . . . . . . . . . . . . . 137
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
managing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
packages, availability of . . . . . . . . . . . . . . . . . . . 130
staging files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Software Repository Multimaster Component
conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Software Repository Replicator
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Spoke
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Super administrator . 56, 57, 58, 61, 62, 64, 72, 73, 75
Suspending users . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
System configuration
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
320
setting configuration parameters . . . . . . . . . . . . 220
System diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Command Engine tests . . . . . . . . . . . . . . . . . . . 146
Data Access Engine tests . . . . . . . . . . . . . . . . . . 144
diagnosing, problems . . . . . . . . . . . . . . . . . . . . . 143
tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
running, system diagnosis . . . . . . . . . . . . . . . . . 147
Software Repository tests . . . . . . . . . . . . . . . . . . 145
testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143, 147
troubleshooting, problems . . . . . . . . . . . . . . . . . 143
Web Services Data Access tests . . . . . . . . . . . . 146
T
Table Space Usage . . . . . . . . . . . . . . . . . . . . . . . . . 203
TIBCO
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Timeout
session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
TNSNAMES.ORA . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Tools
content management tools . . . . . . . . . . . . . . . . . 39
multimaster tools . . . . . . . . . . . . . . . . . . . . . . 97, 102
system diagnosis . . . . . . . . . . . . . . . . . . . . .143, 147
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
TWIST.LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
TWISTOVERRIDES.CONF . . . . . . . . . . . . . . . . . . . . . 80
U
Uninstalling, patch . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Updating, Microsoft patch . . . . . . . . . . . . . . . . . . . . . 37
Uploading, patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
User agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
User groups
adding a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
adding users to CDR . . . . . . . . . . . . . . . . . . . . . . . 87
code deployment . . . . . . . . . . . . . . . . . . . . . . . . . 312
creating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
predefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
SA Client permissions . . . . . . . . . . . . . . . . . . . . . 306
SA Web Client permissions . . . . . . . . . . . . . . . . 306
setting
customer permissions . . . . . . . . . . . . . . . . . . 64
device group permissions . . . . . . . . . . . . . . . 66
facility permissions . . . . . . . . . . . . . . . . . . . . . 65
feature permissions . . . . . . . . . . . . . . . . . . . . 67
OGFS permissions . . . . . . . . . . . . . . . . . . . . . 70
other feature permissions . . . . . . . . . . . . . . . 69
SA Client feature permissions . . . . . . . . . 68, 69
Users
activating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
creating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
deleting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
editing, user information . . . . . . . . . . . . . . . . . . . . 62
importing, external LDAP users . . . . . . . . . . . . . . 85
overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
suspending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
viewing permissions . . . . . . . . . . . . . . . . . . . . . . . 62
V
Vewing
facilities information . . . . . . . . . . . . . . . . . . . . . . . 121
permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
realm information . . . . . . . . . . . . . . . . . . . . . . . . . 123
Virtualization Director
permissions required . . . . . . . . . . . . . . . . . . . . . 297
Visual Application Manager
permissions required . . . . . . . . . . . . . . . . . . . . . 294
W
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
configuration file . . . . . . . . . . . . . . . . . . . . . . . . . 80
WebLogic
messages and exceptions . . . . . . . . . . . . . . . . . 198

SA 7.50 Administration Guide

Uploaded by

Copyright:

Available Formats

SA 7.50 Administration Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SA 7.50 Administration Guide

Uploaded by

Copyright:

Available Formats

HP Server Automation

for the HP-UX, Solaris, Red Hat Enterprise Linux,

You might also like