Vignette Administartion

Administration Guide
Version 4.2
Version
StoryServer 4.2 Administration Guide, Version 4.2 (March 1999)
Stock Number
SSG-0420-308
Copyrights
Copyright 1997-1999 Vignette Corporation. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher. Copyright 1998 Net Perceptions, Inc. All rights reserved.
Disclaimer
Vignette does not warranty, guarantee, or make representations concerning the contents or applicability of the contents of this manual. Products described in this manual may be improved or changed at any time. Vignette reserves the right to update the contents of this manual at any time without obligation to notify anyone of such updates.
Trademarks
StoryServer, Vignette Syndication Server, Vignette Syndication Agent, VSS, and Vignette Development Center are trademarks of Vignette Corporation. Net Perceptions and GroupLens are trademarks of Net Perceptions, Inc. Other product or brand names are trademarks or registered trademarks of their respective companies.
Send Us Your Comments

If you have comments or suggestions about this manual, please send them to publications@vignette.com. A member of the Publications team will acknowledge your mail as soon as possible. You can also reach us at the following address: Vignette Corporation 901 South Mo Pac Expressway Building III Austin, TX 78746-5776
ii
03/01/99
Contents
1 Basic Concepts
Using This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 Concepts and Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 Content Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Common Path Name Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
2 Roadmaps for Getting Started

Roadmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
3 Understanding the Admin Center Tools

Starting StoryServer Admin Center Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 Using the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 Sorting Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 Expanding Server Entries in Configuration View . . . . . . . . . . . . . . . . . . . . . .3-5 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
4 Monitoring StoryServer Servers and Processes

Viewing CMS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 Viewing CAS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 CAS Information in the Primary Window . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 CAS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 Viewing CAS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 CAS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . . .4-6 CAS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . . .4-7
5 Managing StoryServer Users and Groups

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 Understanding Reserved User IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 Monitoring Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 Viewing User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4 Viewing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 Rules for User Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5
03/01/99
iii
Contents
Enabling Self-registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 Adding a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 Editing a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 Cloning a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 Deleting a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10 Setting E-mail Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13 Rules for Group Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13 Adding a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13 Editing a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14 Cloning a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16 Deleting a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16 Authorizing Business Center Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17 Authorizing Development Center Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18
6 Managing StoryServer Files on Windows NT or Solaris

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 Overview of Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3 CMS Configuration File (pm.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3 Other CMS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4 CAS Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6 Other CAS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8 Understanding Configuration File Interaction . . . . . . . . . . . . . . . . . . . . . . . .6-10 Viewing StoryServer Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14 Viewing the EventLog Event Viewer on Windows NT . . . . . . . . . . . . . . . . .6-16 Archiving the StoryServer.errors file on Solaris . . . . . . . . . . . . . . . . . . . . . .6-16 Understanding Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17 Windows Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17 Solaris Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18 Macintosh Tool Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18 Understanding Preference Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19 macrodata File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19 Preferences File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20 File Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-21
iv
03/01/99
Contents
7 Working with the Database on Windows NT or Solaris

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 Database Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Database Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Understanding StoryServer Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Database Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6 Encryption in Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
8 Managing StoryServer Processes on Windows NT or Solaris

Resetting CAS Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 Locating admin Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 CMS admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 CAS admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 Stopping and Starting the CMS with the admin Command . . . . . . . . . . . . . . . . .8-4 Stopping and Starting the CAS with the admin Command . . . . . . . . . . . . . . . . . .8-6 Stopping and Starting with the Start Menu OptionsWindows NT only . . . . . .8-8 Stopping and Starting a CMS from the Start Menu . . . . . . . . . . . . . . . . . . . . .8-8 Stopping and Starting a CAS from the Start Menu . . . . . . . . . . . . . . . . . . . . .8-9 Updating a Remotely Installed CASWindows NT only . . . . . . . . . . . . . . . . . .8-9 Updating a Remotely Installed CASSolaris only . . . . . . . . . . . . . . . . . . . . . .8-11 Notifying the CMS of changes to StoryServer.cfgSolaris only . . . . . . . . . . . .8-12 Verifying CAS ProcessesSolaris only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13 Managing Page Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13 Disabling StoryServer Page Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14 Enabling StoryServer Page Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
9 Managing StoryServer on Windows NT and Solaris

Establishing Service Dependencies for CMS/CASWindows NT only . . . . . . .9-2 Setting Up StoryServer-wide Variables and Procedures . . . . . . . . . . . . . . . . . . . .9-5 Accessing the Platform Configuration ProgramWindows NT only . . . . . . . . .9-6 From the Start Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 From the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 Adding a CAS and Copying Static Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8 Adding a CAS and Copying Static Files on Windows NT . . . . . . . . . . . . . . .9-8
03/01/99
Contents
Adding a CAS and Copying Static Files on Solaris . . . . . . . . . . . . . . . . . . . .9-10 Removing an Observation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11 Removing an Observation Manager on Windows NT . . . . . . . . . . . . . . . . . .9-12 Removing an Observation Manager on Solaris . . . . . . . . . . . . . . . . . . . . . . .9-12 Removing a CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13 Removing a CAS on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14 Removing a CAS on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15 Managing the Demonstration Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15 Deleting the Vignette Demonstration Project on Windows NT . . . . . . . . . . .9-16 Restoring the Vignette Demonstration Project on Windows NT . . . . . . . . . .9-17 Deleting the Vignette Demonstration Project on Solaris . . . . . . . . . . . . . . . .9-18 Restoring the Vignette Demonstration Project on Solaris . . . . . . . . . . . . . . .9-19
10
Working with Web Servers on Windows NT or Solaris

Mapping the Root Path (/) to a Front Door CURL . . . . . . . . . . . . . . . . . . . . . . .10-2 Working with Web Server Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2 StoryServer Changes to obj.conf File on Netscape . . . . . . . . . . . . . . . . . . . .10-3 Disabling Parsing on Netscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 Optimizing parse-html on Netscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 Parsing on IIS 4Windows NT only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6 Parsing on ApacheSolaris only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8 Clearing Pages from a Root Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8 Using .asp Scripts in TemplatesWindows NT only. . . . . . . . . . . . . . . . . . . .10-10
11
Tuning StoryServer on Windows NT

Editing the Configuration Files on Windows NT . . . . . . . . . . . . . . . . . . . . . . . .11-2 Editing the pm.cfg File on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 Editing the StoryServer.cfg File on Windows NT . . . . . . . . . . . . . . . . . . . . .11-3 Increasing Page Generator Requests on Windows NT . . . . . . . . . . . . . . . . . . . .11-5 Adjusting Page Generator Timeouts on Windows NT . . . . . . . . . . . . . . . . . . . .11-6 Changes from Previous Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 Setting Page Generation Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7 RESET_TIMEOUT Template Command . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8 Adjusting Page Generator Logging on Windows NT . . . . . . . . . . . . . . . . . . . . .11-9 Adjusting for Large Database Retrievals on Windows NT . . . . . . . . . . . . . . . . .11-9 Increasing Request Handling on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . .11-11
vi
03/01/99
Contents
Setting the Thread Pool Size for the Cache Manager on Windows NT . . . . . .11-12 Restricting Access to the Servers on Windows NT. . . . . . . . . . . . . . . . . . . . . .11-13 Setting Allowed IP Addresses for the CMS . . . . . . . . . . . . . . . . . . . . . . . . .11-14 Setting Allowed IP Addresses for a CAS . . . . . . . . . . . . . . . . . . . . . . . . . .11-15
12
Tuning StoryServer on Solaris

Increasing Page Generator Requests on Solaris . . . . . . . . . . . . . . . . . . . . . . . . .12-2 Adjusting Page Generator Timeouts on Solaris . . . . . . . . . . . . . . . . . . . . . . . . .12-3 Changes from Previous Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 Setting Page Generation Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 RESET_TIMEOUT Template Command . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5 Adjusting Page Generator Logging on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . .12-6 Adjusting for Large Database Retrievals on Solaris . . . . . . . . . . . . . . . . . . . . . .12-7 Increasing Request Handling on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8 Setting the Thread Pool Size for the Cache Manager on Solaris . . . . . . . . . . . .12-10 Restricting Access to the Servers by IP address on Solaris . . . . . . . . . . . . . . . .12-11 Setting Allowed IP Addresses for the CMS . . . . . . . . . . . . . . . . . . . . . . . . .12-12 Setting Allowed IP Addresses for a CAS . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
13
Transferring Projects between Content Management Servers

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2 How Transfer Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4 Exporting and Importing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4 Typical Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-9 StoryServer Project Data and Database Content . . . . . . . . . . . . . . . . . . . . .13-10 Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-11 Transferring Content Design Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13 transferproject Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13 Transferring Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-16 transferproject Permissions and Other Requirements . . . . . . . . . . . . . . . . .13-16 Setting Environment Variables on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . .13-16 Import Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 Finding Project IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18 Exporting StoryServer Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19 Exporting StoryServer Project Data and Database Content Together . . . . .13-20 Importing StoryServer Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21
03/01/99
vii
Contents
Exporting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-22 Importing Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-23 Deleting StoryServer Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-26 Deleting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-26 Moving a Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-27 Things to Do after Transferring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-28 Whats Transferred and What Isnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-29 General Information about Transferring Projects . . . . . . . . . . . . . . . . . . . . . . .13-33 StoryServer Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-33 Parent Project and Status of Imported Content Items . . . . . . . . . . . . . . . . .13-34 Contents of Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-35
A StoryServer Process Reference

Process Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2 admin (CAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3 admin (CMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5 bob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8 config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9 ctld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11 expire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13 flushcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14 inboundmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16 launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19 logroller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21 pad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23 setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24 ss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25 ted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-29 tmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-30 transferproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-31 version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35 vhs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-40
B StoryServer File Reference

File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
viii
03/01/99
Contents
cmd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5 cmd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6 ctld.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6 ctld.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8 ctld.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10 ctldinfo.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11 ctldinfo.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13 delivery.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15 docroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-17 lastsession.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18 macrodata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19 metafiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20 obj.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21 PadArchiveDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22 pad.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22 pad.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-24 pad.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-25 PadWorkDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-26 plugin.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-27 pm.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-29 pm.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-31 Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-32 StoryServer.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-33 StoryServer.errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35 TasksWorkingDirsRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35 ted.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-36 templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-38 tmd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-39 tmd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-40 vhs.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-41 vhs.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-42 VhsProtoDocRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-44
C Remote Operations
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2 CAS Outside the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
03/01/99
ix
Contents
StoryServer Sessions Outside the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7 Setting the VHS_PORT Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10 Working with IP-aliasing Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10 Outbound Connections via HTTP Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-11 StoryServer Sessions Using SOCKS Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . C-15 StoryServer Sessions and SOCKS on Windows NT . . . . . . . . . . . . . . . . . . C-17 StoryServer Sessions and SOCKS on Solaris . . . . . . . . . . . . . . . . . . . . . . . C-18
D Managing GroupLens Express

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting GroupLens Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping GroupLens Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing Up the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-2 D-2 D-2 D-3 D-3 D-3 D-4 D-4 D-4 D-4 D-4 D-5 D-5
Configuring Virtual Hosting

Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2 How Virtual Hosting Works With StoryServer . . . . . . . . . . . . . . . . . . . . . . . E-2 Configuring Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-3 Netscape Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-4 Microsoft IIS 4 Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-5 Apache Web ServersSolaris Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-7 Testing the Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-9 Setting Up Development CASs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10 Creating Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10 Submitting Static Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10
Index
03/01/99
1
Summary: Audience:
Basic Concepts
Basic concepts for administering StoryServer and a high-level view of tasks. Administrators and other users of StoryServer 4.2
Before you begin, make sure that:
StoryServer CMS and CAS software installed A CMS configured At least one development CAS configured for the CMS StoryServer Production Center and Admin Center tool sets software installed Using This Book Concepts and Terms
Topics include:
03/01/99
1-1
Basic Concepts
Using This Book

This book provides information for both the authorized administrator and other users.
Part I (Chapters 1 through 5) provides an introduction to the StoryServer
Admin Center tools and instructions for using:
Configuration View to view information about StoryServer Configuration Management Server (CMS) and Content Application Servers (CASs). User/Group Manager to view and manage information about StoryServer users and groups
Chapter 2 consists of two extensive "roadmaps" for getting started with the Admin Center, and for performing various common procedures.
Part II (Chapters 6 through 12) provides more detailed information to allow
the admin user, usually a system administrator, to administer the StoryServer software through both the Admin Center tools and commandline interfaces. Chapter 11 explains adjusting variables to increase performance on Windows NT. Chapter 12 explains the same information for Solaris.
Part III (Chapter 13) provides complete information about the
transferproject utility, which allows projects to be transferred from one CMS to another.
Appendixes provide reference pages for commands and files, additional
information for optional configurations (including configuring hosts outside the firewall), an explanation of virtual hosting, and information on using the Observation Manager and Net Perceptions, Inc.s GroupLens Express.
Concepts and Terms

This book uses the concepts and terms found in Running StoryServer Tools. It also uses the following concepts and terms to explain StoryServer administration.
1-2
03/01/99
Basic Concepts
Content Types
StoryServer handles content stored in two ways: in the database and in the file system.
Database content File system content Content that you can sort by database queries. Ideally this includes much of your site content. Content stored directly in the file system, including such static files as graphics, audio, and HTML files that dont change or dont need templates. The web server configured with a CAS delivers these static files in the conventional way.
For more information on content types, see the chapter on content and template interaction in StoryServer 4 Overview. Figure 1-1 shows a basic StoryServer setup in which the CMS, development and live CASs, and StoryServer tools (clients) are installed on different host systems. While all hosts are behind a firewall, the live CAS provides web pages for the web server with access beyond the firewall. StoryServer also allows you to run hosts outside of your firewall. See Appendix C, Remote Operations for details.
03/01/99
1-3
Basic Concepts
Figure 1-1:
StoryServer Components
Web Site team uses StoryServer tools
CM Server
saga:7007
Router/ Firewall
Development CAS
http://saga.nd.com:8085
StoryServer DB
Live CAS
http://freya.nd.com:80
Web Server
Web Server
I N T E R N E T
/DocRoot
/DocRoot
1-4
03/01/99
Basic Concepts
Common Path Name Variables

The common file location (path name) variables used in this book include:
Variable install-path Indicates... The path name of the folder or directory in which the StoryServer CMS or CAS or tools software has been previously installed. For example:

StoryServer n Rn NT conf-n S UN conf host-port-number
NT D:\Program Files\Vignette S UN /opt
On Windows NT, the release number of the StoryServer software. For example, StoryServer 4. The version number of the StoryServer software. For example, R4.2. On Windows NT, this directory carries a number indicating the order in which the CMS was added to the host. For example, conf-1, conf-2, and so on. The fully qualified name of the web server host, the port number of the web server, and the sequence number of the CAS process. For example: antone.myco.com-989-2
id
Identification number assigned to a slave process when it was spawned.
See also
Roadmaps for Getting Started on page 2-1
03/01/99
1-5
Basic Concepts
1-6
03/01/99
2
Summary: Audience:
Roadmaps for Getting Started
Two tables for helping you get underway with the Admin Center. Administrators and other users of StoryServer 4.2 Basic Concepts on page 1-1
Before you begin:
03/01/99
2-1
Roadmaps
The two "roadmaps" below will help you to get underway with the StoryServer Admin Center. The first roadmap provides descriptions for the various tasks, as well as directing you to background and how-to information. The admin user controls StoryServer users and groups through the User/Group Manager. (See Managing StoryServer Users and Groups on page 5-1.) Additional features of the Configuration View and some commandline interfaces let the admin user manage StoryServer servers and processes. (See Monitoring StoryServer Servers and Processes on page 4-1.) The first table is arranged sequentially. In general, you will want to perform each procedure before you begin the next one. The second table lists a variety of procedures that can be performed in any sequence.
What to do Familiarize yourself with the Admin Center Tools. Create a password for the admin user ID and (optionally) the guest user ID. Create user entries and a separate group entry (recommended) for the owners of the Base Project in the Production Center tool set. Determine whether selfregistration should be allowed. Set electronic mail preferences. Description Take some time to learn the Admin Center interface. The admin user and members of the Admin group have wide-ranging privileges. Carefully control administrator authorization. You determine which users will be able to perform various jobs. Assigning authorization by group allows you to give multiple users the same privileges or responsibilities. For information, see Understanding the Admin Center Tools on page 3-1 Editing a User Entry on page 5-8
Managing StoryServer Users and Groups on page 5-1
Allow self-registration if users unknown to the Enabling Self-registration database should be able to log in to StoryServer. on page 5-6 Project owners assign tasks to users, and the users are notified by e-mail. In the Configuration View, an admin user can set email preferences which affect all users listed in the currently connected CMS. Setting E-mail Preferences on page 5-10
2-2
03/01/99
What to do Set StoryServer-wide variables and procedures.
Description You can define StoryServer-wide variables and procedures to identify information used by all the Page Generator processes in a single set of installed StoryServer files. Once you define the procedures, they are available to all templates managed by the CASs configured on that host.
For information, see Setting Up StoryServerwide Variables and Procedures on page 9-5
The following table is not arranged sequentially. The list represents a variety of procedures that the admin user might perform.
What to do View and modify configuration information for the CMS, CAS, and CAS processes. Create more CASs. Description The Configuration View provides a quick source of information about the various servers and processes running on your system. The CASs you add can reside on hosts other than the StoryServer database or the CMS, as long as the hosts can communicate with each other directly through the network and are not separated by a firewall. Certain services cannot start correctly unless the database service is already running. For information, see Monitoring StoryServer Servers and Processes on page 4-1 Adding a CAS and Copying Static Files on page 9-8
If you are running the CMS or CAS on the same Windows NT host as the database, adjust the sequence in which the services start. If you are using the Business Center tools, establish authorization for users to operate in the visitor database. If you are using the Development Center tools, establish authorization for users of the Content Designer. Remove a CAS.
Establishing Service Dependencies for CMS/CASWindows NT only on page 9-2
Running reports on visitor data can consume system processing resources. Limit the number of users who can create, run, and edit reports.
Authorizing Business Center Users on page 5-17
Content Designer users can create, read, write, and delete (if they created them) all Form Sets, Forms, and database tables in the system. Users can import existing database tables, but cannot change database columns in these tables. Note that if an Observation Manager has been configured, you must remove it before removing the CAS itself.
Authorizing Development Center Users on page 5-18
Removing a CAS on page 9-13
03/01/99
2-3
What to do Manage StoryServer files.
Description When you install and configure the software and toolsets, StoryServer creates directories and files used by the various processes.
For information, see Managing StoryServer Files on Windows NT or Solaris on page 6-1 and StoryServer File Reference on page B-1 Working with Web Servers on Windows NT or Solaris on page 10-1
Fine tune your web server.
Each CAS provides pages through a web server. Modifications you can make include: setting up webserver parsing, clearing pages from the root path, and (for Windows) using .asp scripts in templates. The CMS and CAS run several processes (also called "services" on Windows NT) that you can manage either through the Configuration View, Start menu options, or a command-line interface. The StoryServer database contains templates, the content records for the web pages generated by the CAS(s), and production management information for tracking both templates and content in the Production Center. When you configure a StoryServer development CAS, you can add a set of templates and content that make up the demonstration project: the Music a la Mode web site. To save space, you can remove this project, including its static files. You can modify variable settings to increase performance or adjust for different content or products you might be accessing. If your company has multiple StoryServer CMSs, you may need at times to transfer copya project from one CMS to another. You may want to configure a live CAS on a host outside your security firewall and allow it to communicate with a CMS on a host inside the firewall. Or, you might want to run a StoryServer tool session outside the firewall, for example, to allow remote project tracking.
Manage StoryServer processes.
Managing StoryServer Processes on Windows NT or Solaris on page 8-1 and StoryServer Process Reference on page A-1 Working with the Database on Windows NT or Solaris on page 7-1
Understand the StoryServer database.
Delete or restore the Vignette Demonstration Project.
Managing the Demonstration Project on page 9-15
Adjust StoryServer variables.
Tuning StoryServer on Windows NT on page 11-1 or Tuning StoryServer on Solaris on page 12-1 Transferring Projects between Content Management Servers on page 13-1 Remote Operations on page C-1
Transfer projects from one CMS to another.
Configure StoryServer hosts outside the firewall.
2-4
03/01/99
What to do Configure the Observation Manager and GroupLens Express.
Description The Net Perceptions, Inc.s GroupLens Express software adds collaborative filtering technology to StoryServer by storing user preferences and computing recommendations for items a site visitor might like. Virtual hosting allows you to set up one CAS to serve multiple virtual web servers.
For information, see Managing GroupLens Express on page D-1
Set up virtual hosting.
Configuring Virtual Hosting on page E-1
See also
Understanding the Admin Center Tools on page 3-1
03/01/99
2-5
2-6
03/01/99
3
Summary: Audience:
Understanding the Admin Center Tools
Overview of the StoryServer Admin Tools. Administrators and other users of StoryServer 4.2
Before you begin:
Basic Concepts on page 1-1 Roadmaps for Getting Started on page 2-1 Starting StoryServer Admin Center Tools Using the Tools Getting Help Closing Admin Center Tools
Topics include:
03/01/99
3-1
Starting StoryServer Admin Center Tools

Audience: Administrators and other users of StoryServer 4.2
You must have the Admin Center software installed with the basic StoryServer package to use the Admin Center tools. You start the Configuration View and the User/Group Manager from the StoryServer launch bar window, an example of which is shown in Figure 3-1. (For information on starting StoryServer, see Running StoryServer Tools.) NOTE: To use some of the Admin Center functions, you must log in as admin user or a member of the Admin group when you start StoryServer.
Figure 3-1: StoryServer launch bar
To start either Admin Center tool, click the appropriate tool icon once. The tool window opens, as shown in Figure 3-2, Configuration View primary window and Figure 3-3, User/Group Manager primary window.
3-2
03/01/99
Figure 3-2:
Configuration View primary window
03/01/99
3-3
Figure 3-3:
User/Group Manager primary window
See also
Using the Tools on page 3-4
Using the Tools

Audience: Topics include: Administrators and other users of StoryServer 4.2
Sorting Entries Expanding Server Entries in Configuration View
All users of the StoryServer Admin Center tools can view information about StoryServer, including the Content Management Server (CMS), Content Application Servers (CASs), and StoryServer users and groups. Admin users
3-4
03/01/99
can use options that change the servers, but these options are unavailable for other users. NOTE: A non-admin user can change his or her own user password, description, or e-mail address. See Editing a User Entry on page 5-8.
Sorting Entries
In the primary window pages (Configuration View or the Users or Groups page of User/Group Manager), you can sort the displayed information by clicking on the appropriate column head. An up- or down-triangle appears to the left of the title of the sorted column, indicating whether the column is sorted in forward or reverse order. Click again to sort the same column in the reverse order.
Expanding Server Entries in Configuration View

When the Configuration View primary window opens, the CMS to which this Storyserver session is connected appears on the first line. If the CMS associated processes are not already shown, you can expand the entry to show any CASs already installed and connected to the CMS. You can further expand CASs to show their processes. The CMS and each CAS entry are prefaced by an expandable icon (see Figure 3-2). You can use the icon to show information about these processes running on each CAS:
Cache Manager Observation Manager (if present) Page Generator Placement Manager Template Manager
NOTE: A CAS must be expanded before you can get status on a process. For more information, see Viewing CAS Information on page 4-4.
See also Getting Help on page 3-6
03/01/99
3-5
Getting Help
You can access the StoryServer 4.2 on-line manuals from a StoryServer Admin Center tools Help menu or from your web browser. In order to view the installed on-line manuals, you must:
Have a CMS and at least one development CAS configured Specify a default browser Have the development CAS selected in the Preferences window
For more information on setting preferences and accessing on-line information, see the section on getting help in Running StoryServer Tools.
See also Closing Admin Center Tools on page 3-6
Closing Admin Center Tools

You can exit an individual Admin Center tool from the File menu Close option in the tools primary window. All the tools windows close. You can also close Admin Center tools (and all other StoryServer tools open in the current session) by using the StoryServer launch bars File menu Exit option (or the Ctrl+Q key sequence with the cursor in the launch bar window). When you use this method to close tools, the next Storyserver session you open using the same login recalls your choice of open tools and automatically opens the primary windows of all tools that were open when you last closed StoryServer.
See also Managing StoryServer Users and Groups on page 5-1 Monitoring StoryServer Servers and Processes on page 4-1
3-6
03/01/99
4
Summary: Audience: Note:
Monitoring StoryServer Servers and Processes
How to use the Configuration View to view or change the servers and processes. Administrators and other users of StoryServer 4.2 Understanding the Admin Center Tools on page 3-1
Before you begin: Topics include:
Viewing CMS Information Viewing CAS Information Viewing CAS Process Information
The Configuration View primary window updates dynamically when changes are made to the StoryServer servers information.
03/01/99
4-1
Viewing CMS Information

A Configuration View session can provide information about one Content Management Server (CMS) and its Content Application Servers (CASs) at a time. The status field in the StoryServer launch bar shows the CMS you are accessing. For information on switching the StoryServer session to a CMS other than the one you are currently viewing, see the section on connecting to a different CMS in Running StoryServer Tools. For information on expanding and collapsing the Configuration View entries to view more or less information, see Expanding Server Entries in Configuration View on page 3-5.
I To view information about the CMS to which the Configuration View is currently connected: 1 2
In the Configuration View primary window, select the Content Management Server entry. With the cursor on the selected entry, click the right mouse button, and select Details from the pop-up menu. The Content Management Server (CMS) Details window opens with the following fields:
Shows the host and path name where the StoryServer CMS is installed. For example: NT art.myco.com:d:/Program Files/Vignette/Storyserver n/Engines/Rn S UN nemo.mycompany.com:/opt/StoryServer/Rn
Installation Name
Database Name
Shows the name of the database accessed by the StoryServer CMS. For example: satoridb
Database Server
Shows the name of the server for the database. For example: SQLSERVER
Database Type
Shows the type of database being accessed. Valid types include:
NT MSSqlServer, Oracle, Sybase S UN Informix, Oracle, Sybase.
4-2
03/01/99
Database User
Shows the user name for accessing the database. For example: rt_ful
On-line Documentation Path
Shows the location of the StoryServer on-line documentation. For example: http://harvey.myco.com:98/opt/StoryServer /docs/index.html If no development CASs are configured, the path for the Vignette web site version of the documents is provided.
Self Registration Allowed for StoryServer Users
Shows whether StoryServer user self-registration is enabled (Yes) or disabled (No). The enabled setting allows new users to log in and create a user name and password for themselves in the StoryServer database. Admin users can change this setting. For more information, see Enabling Self-registration on page 5-6. Shows the current host name (the fully qualified domain name: for example, archie.vignette.com) and port number (usually 25) for the Simple Mail Transfer Protocol server to use for StoryServer e-mail notifications. Admin users can change the values in this field. For more information, see Setting E-mail Preferences on page 5-10. Shows whether e-mail notifications are enabled (On) or disabled (Off). The enabled setting allows StoryServer to send e-mail notifications of tasks set in the Production Center tools. Admin users can change this setting. For more information, see Setting E-mail Preferences on page 5-10. (For Business Center) Shows users or groups authorized to create, run, and edit reports in both their personal and the shared folders using the Report Manager, and to create category:keyword pairs in the keyword manager. Default value of nobody means no users have this authorization. The admin user should change this value to valid user IDs when Business Center use begins. (For Business Center) Shows users or groups authorized to run reports in the shared folder and create, run, and edit reports in their personal folder using the Report Manager. Default value of nobody means no users have this authorization. The admin user should change this value to valid user IDs when Business Center use begins. (For Development Center) Shows users or groups authorized to create, read, write, and delete (if they created them) all Form Sets, Forms, and database tables in the system. Users can import existing database tables, but cannot change database columns in these tables. See Using the Content Designer.
SMTP Server
E-mail Notifications
Users with full authorization
Users with limited authorization
Users with Content Designer authorization
03/01/99
4-3
Click OK or Cancel to close the window. (Clicking OK commits any changes made by an admin user.)
See also Viewing CAS Information on page 4-4
Viewing CAS Information

Summary: Audience: Topics include: The Configuration View provides information about each CAS connected to a CMS. Administrators and other users of StoryServer 4.2
CAS Information in the Primary Window CAS Information in the Details Window
CAS Information in the Primary Window

The columns of the Configuration View primary window display the following information about each CAS:
Name Shows the name of the CAS in host-port-number format:
host - host name for the CASs web server port - port number for the CASs web server number - the sequence number of this CAS on the host (On Windows NT, the sequence number appears only after the second and subsequent CASs are configured for the port.)
For example: nemo.myco.com-9090-2 Host Shows the host and domain for the CASs web server. For example: nemo.myco.com Port Type Shows the port number that the CASs web server uses. Shows the designation of the CAS, either Development or Live
CAS Information in the Details Window

I To view CAS information in the Configuration View primary window 1 2
Right-click a CAS entry and select Details from the pop-up menu. Choose the corresponding tab to view General or Database information.
4-4
03/01/99
CAS General Information

Installation Shows the host and path name where the CMS for the CAS is installed For example: NT art.myco.com:D:/Program Files/Vignette/Storyserver n/Engines/Rn S UN nemo.myco.com:/opt/StoryServer/Rn Application Server Name Shows the fully qualified name of the CAS in host-port-number format. (On Windows, number is used only for the second and subsequent CAS configured for the port.) For example: edgar.myco.com-9090-2 Docroot Path Shows the location of the directory mapped to the web servers front door. For example: NT C:/InetPub/wwwroot S UN /install/nemo/docroot/ourdocs
CAS Database Information

Database Name Shows the name of the database accessed by the StoryServer CMS. For example: satoridb Database Server Shows the name of the server for the database. For example: KRYTEN Database Type Shows the type of database being accessed. Valid types include: NT MSSqlServer, Oracle, Sybase S UN Informix, Oracle, Sybase. Database User Shows the user ID for accessing the database. For example: rt_ful
See also
Viewing CAS Process Information on page 4-6
03/01/99
4-5
Viewing CAS Process Information

Summary: Audience: Topics include: The Configuration View provides information about each CAS process. Administrators and other users of StoryServer 4.2
CAS Process Information in the Primary Window CAS Process Information in the Details Window
The Configuration View primary window shows the following processes for each CAS connected to the CMS:
Cache Manager Observation Manager Page Generator Placement Manager Maintains cached content so that only dynamic information needs to be generated from the database. See also cmd on page A-8. Records profile markers encountered by each web visitor. This optional service is part of the Business Center. See also Business Center and Open Profile Services Guide . Interprets templates, accesses content, and generates web pages on demand. See also ctld on page A-11. Manages the deployment of static content (content that does not reside in the database) to the CAS docroots. See also pad on page A-23.
Template Manager Manages templates and updates the Page Generator concerning new or modified templates. See also tmd on page A-30.
CAS Process Information in the Primary Window

The columns of the Configuration View primary window display the following information about each CAS process:
Name - process name Host - host name and domain Port - port number the process uses to communicate
For a more complete description of each field, see the table in CAS Information in the Primary Window on page 4-4.
4-6
03/01/99
CAS Process Information in the Details Window

In the Configuration View primary window, to view CAS process information:
Right-click a CAS process entry and select Details from the pop-up menu.
Installation Shows the host and path name where the StoryServer CMS for the CAS is installed. For example: NT art.myco.com:D:Program Files/Vignette /Storyserver n/Engines/Rn S UN nemo:/opt/StoryServer/Rn Application Server Shows the name of the CAS to which this process belongs in host-port-number format. (On Windows, number is used only for the second and subsequent CAS configured for the port.) For example: nemo-9090-2 Process Shows the type of process. Valid types include Cache Manager, Observation Manager, Page Generator, Placement Manager, or Template Manager. Shows the host name and domain of the web server with which the process is associated. Shows the port number on which the process communicates. Shows OK if the process is running. (If the process is not running, an error message opens.)
Host Port Status
See also
Managing StoryServer Users and Groups on page 5-1
03/01/99
4-7
4-8
03/01/99
5
Summary: Audience:
Managing StoryServer Users and Groups
You can view and change lists of users and groups through the Admin Centers User/Group Manager. Administrators and other users of StoryServer 4.2 Basic Concepts on page 1-1
Overview Understanding Reserved User IDs Monitoring Users and Groups Managing Users Managing Groups Authorizing Business Center Users Authorizing Development Center Users
03/01/99
5-1
Overview
Each StoryServer Content Management Server (CMS) maintains lists of users and groups of users who can operate within the StoryServer platform. You can view and change the lists through the Admin Centers User/Group Manager. Project owners can assign users and groups to projects and tasks using the StoryServer Production Center tools. Only users or groups authorized by the project owner and authenticated by the StoryServer database can operate on a given project or task. NOTE: You can also create, manage, and delete users and groups by embedding CMS commands in your templates. These provide a browseraccessible alternative to the Admin Centers User/Group Manager. See CMS in the Template Cookbook. The User/Group Manager primary window contains information for these aspects of StoryServer, each contained in a page with a tab at the top:
Users Shows information about the currently valid users recognized by the StoryServer database. From this page:

Groups
An admin user can add, edit, copy, and delete users. A non-admin user can edit his or her own entry.
Shows information about the currently valid groups recognized by the StoryServer database. From this page:
An admin user can add, edit, copy, and delete groups.
All users can view currently valid users and groups through the User/Group Manager. The lists in the primary window update dynamically so that they remain current.
Understanding Reserved User IDs

On installation, StoryServer creates these reserved entries: the admin and guest user ID and the Admin group. (Other user IDs, nobody and system, are reserved but not managed by the User/Group Manager. See "Overview of Authorization" in the Production Center Guide.) The admin user ID belongs to the one default group, Admin.
5-2
03/01/99
The admin user and members of the Admin group are fully authorized to operate in the Admin Center tools. Other users can use the Admin Center tools in read-only mode, except that a valid user can change the password, description, or e-mail address on his or her own user entry. NOTE: The admin user and members of the Admin group are fully authorized to operate in the Production Center tools without specific authorization from a project owner. Admin users can add, delete, and edit StoryServer user and group entries through the User/Group Manager. If self-registration is enabled, a user can create a user ID when logging in, but only an admin user can add or remove user IDs from groups. Groups provide a convenient way to authorize several users at once. NOTE: After the StoryServer installation, an admin user creates new user and group entries in the StoryServer database. The first user entries should be new owners of the Base Project in the Production Center. The Admin group owns the Base Project by default, but a new group should be created for the real owners. For more information, see Adding a User Entry on page 5-6 and Adding a Group Entry on page 5-13. TIP: We recommend that you also create a project (for example, sandbox) with admin specified as project owner and no specified authorized users under the Base Project. Such a project can be used for experimentation by all users without damaging other projects. Everyone can add to the project, but only admin users could launch anything to the web.
See also Monitoring Users and Groups on page 5-3
Monitoring Users and Groups

Viewing User Attributes Viewing Group Attributes
All users can view currently valid users and groups through the User/Group Manager.
03/01/99
5-3
To view the list of users or groups currently able to operate in StoryServer, click on the Users or Groups tab in the User/Group Manager primary window.
Viewing User Attributes

The columns of the User/Group Manager show the following read-only information about current users:
User The users StoryServer login name (ID). StoryServer establishes and maintains this ID within the database. The reserved user IDs established by default when you install StoryServer are admin and guest (two other IDs, nobody and system are not shown in or managed by the User/Group Manager). (Optional) A full name or more descriptive information about the user. (Optional) The electronic mail address of the user. (Optional) The groups of which the user is a member. Groups provide a quick way to assign several users to a project or task without listing each one separately.
Description E-mail Address Groups
Viewing Group Attributes

The User/Group Manager shows the following read-only information about current groups:
Group Name StoryServer establishes and maintains the group name within the database. Admin is established by default as a reserved group name when you install StoryServer. (Optional) A full name or more descriptive information about the group.
Description
See also
Managing Users on page 5-5
5-4
03/01/99
Managing Users
Rules for User Entries Enabling Self-registration Adding a User Entry Editing a User Entry Cloning a User Entry Deleting a User Entry Setting E-mail Preferences
TIP: When a user owns the lock for an object, that object lock is owned everywhere the user is logged in. For this reason, we recommend that users requiring administrator privileges be added to the Admin group rather than share the admin user ID. For information on authorizing users to run Business Center reports, see Authorizing Business Center Users on page 5-17. For information about working with the Content Designer, see Authorizing Development Center Users on page 5-18.
Rules for User Entries

The rules governing StoryServer user and group names (IDs) are:
cannot have more than 16 characters can include letters, numbers, hyphens, and underscores can include upper- and lowercase letters cannot have spaces or apostrophes user IDs must be unique within StoryServer; that is, StoryServer will not
allow the same string of characters to be used as both a user ID and a group ID TIP: We recommend the convention of using lowercase for user names and initial capitals for group names: for example, admin and Admin.
03/01/99
5-5
Enabling Self-registration
An admin user can set the self-registration feature to allow a user to log in to StoryServer without requiring a user name that is already known to the database. The user enters a name and password in the login window. If the ID is unknown, the New User Registration window lets the user confirm the password and add an optional description and e-mail address. StoryServer then adds the user ID to the database. Self-registration is enabled by default when the CMS is installed. Self-registration remains in effect for all interactions requiring logins to the CMS or its Content Application Servers (CASs) until the setting is disabled. The new user has no group memberships; an admin user must edit the users entry in the User/Group Manager to add the new user to groups. The new user can add or change other optional information for his or her own user entry, such as the e-mail address, in the User/Group Manager. For more information, see Editing a User Entry on page 5-8.
I To enable or disable self-registration for all users of a given StoryServer database: 1
In the Configuration View primary window, right-click the Content Manager Server entry, and select Details from the pop-up menu. The Content Management Server Details window opens. Toggle Self Registration Allowed for StoryServer Users to Yes or No. Click OK or Apply to submit the change to the database.
2 3
Adding a User Entry

By default, the Admin group is the owner of the Base Project in the Production Center. Before other users can create projects, the admin user must create user entries for additional owners of the Base Project. Rather than add the Base Project owners to the Admin group, we recommend that you create a group for the owners (for example, Baseowners) and add the user IDs to it. The admin user should also be a member of the Baseowners group. NOTE: After adding the new group as owners of the Base Project in the Production Center, you can delete the Admin group from the owner field if you wish.
5-6
03/01/99
TIP: If you are creating many users at once, you may find it easier to create the user entries without group membership, then create or edit a group entry and add several users to the group at once.
I To add a user entry to the StoryServer database:
1 In the Users page of the User/Group
Manager primary window, click the New User icon.

2 In the User field, enter the name for the
The Add User window opens with the Details page displayed. Follow the guideline described in Rules for User Entries on page 5-5.
new user.
3 (Optional) In the Description field, enter
a full name or more detail about the user.

4 (Optional) In the E-mail Address field,
enter the electronic mail address of the user.

5 In the Password field, enter a password
The e-mail address is used by the CMS for project notifications. See Rules for User Entries on page 5-5. For security, only asterisks display instead of the letters you enter. Again, only asterisks display in the window. The Add User window closes and the user name is added to the Users page of the User/Group Manager primary window. The Groups page opens. The Add User window closes without making any changes to the StoryServer database. The Groups page opens.
for the new user.

6 In the Confirm Password field, type the
password again to verify it.

7 Choose:
Add the user entry without assigning group membership(s) by clicking OK. Continue to the Groups page. Click Cancel.
8 To continue and add the user to one or
more groups, click the Groups tab at the top of the Add User window.
9 Select one or more entries in the User is
The left arrow button becomes available. Moves one or more entries to the User is a member of list.
not a member of list.

10 Click the left arrow button. Repeat as
necessary.
11 Click OK or Cancel.
03/01/99
5-7
Editing a User Entry

Admin users can edit any field in the Edit User window pages except the User field; you cannot change the users ID. (To change the users ID, you must delete the user and re-enter the information.) A non-admin user can change the Description, E-mail Address, Password, and Confirm Password text fields for his or her own entry, but not the User field or the Groups memberships. TIP: When you start the StoryServer User/Group Manager for the first time, edit the admin user entry to add a password. Limit the number of users who know the password. To grant other users admin authentication, add them to the Admin group and delete them from the group when their need for Admin authentication is past. Optionally, you can also add a password to the guest user entry. NOTE: If you modify the entry for a user who is currently working in a StoryServer tool connected to this database, you can affect the users authorization for some operations. For example, if you remove a user from a group and the user is attempting an operation authorized only for that group, the user may not be able to continue. You can edit only one user entry at a time.
I To edit a user entry:
1 In the Users page of the User/Group Manager
The Details icon becomes available.
primary window, select a user entry.

2 Click Details to open the Edit User window with
the Details page displayed.

3 Edit the fields in the Details page as necessary or
go to Step 5.
4 Choose:
Commit the user entry without changing group membership(s) by clicking OK. Continue to the Groups page. Click Cancel.
The Edit User window closes and appropriate changes appear in the Users page of the User/Group Manager primary window. The Groups page opens. The Edit User window closes without making any changes to the StoryServer database.
5-8
03/01/99
5 To continue and change the users group
membership(s), click the Groups tab at the top of the Edit User window.
6 Choose
one or both:
Select one or more entries in the User is a member of list. Click the right arrow button to move the entries to the User is not a member of list. Select one or more entries in the User is not a member of list. Click the left arrow button to move the entries to the User is a member of list.
Cloning a User Entry

An admin user can clone an existing user entry to create a new entry. The new entry has only the group memberships of the copied entry. All other fields are blank for you to enter the new users information.
I To clone a user entry and create a new entry:
1 In the Users page of the User/Group
The Clone icon becomes available.
Manager primary window, select a user entry.

2 Click Clone.
The Copy User window opens with the Details page displayed. See Adding a User Entry on page 5-6. The Copy User window closes and the user name is added to the Users page of the User/Group Manager primary window. The Groups page opens. The Copy User window closes without making any changes to the StoryServer database.
3 Add information to the fields. 4 Choose:
Add the user entry without assigning group membership(s) by clicking OK. Continue to the Groups page. Click Cancel.
03/01/99
5-9
5 To continue and modify the users group
The Groups page opens.
membership(s), click the Groups tab at the top of the Copy User window.
6 Modify the users group(s). 7 Click OK or Cancel.
See Editing a User Entry on page 5-8.
Deleting a User Entry

Admin users can delete user entries from the StoryServer database. When you delete a user entry, it is also deleted from any groups of which it was a member. Deleting a user entry in the User/Group Manager does not automatically remove the users ID from project or content items in the Production Center. You must manually remove the ID. Assigning groups instead of individual user IDs requires less maintenance. NOTE: If you delete the user entry for a user who is currently working in a StoryServer tool connected to this database, you can affect the users authorization for some operations. For example, if the user is only viewing in the Admin Center tools, the operation can continue, but if a user is connecting to another CMS, the user will be unable to continue.
I To delete a user from the StoryServer database:
1 In the Users page of the User/Group Manager
A confirmation prompt opens.
primary window, right-click one or more user entries, and select Delete from the pop-up menu.
Setting E-mail Preferences

Topics include:
Setting the SMTP Host Enabling E-mail Notifications
5-10
03/01/99
Project owners assign tasks to users, and the users are notified by e-mail. An admin user can set e-mail preferences in the Configuration View that affect all users listed in the currently connected CMS.
Setting the SMTP Host
You can set name and port of the Simple Mail Transfer Protocol (SMTP) server to be used for StoryServer e-mail notifications from the CMS. The initial default is localhost:25.
I To set the SMTP server for a StoryServer CMS:
1 In the Configuration View primary
window, right-click the Content Management Server entry, and select Details from the pop-up menu.
2 Enter the fully qualified domain
The Content Management Server Details window opens.
For example: archie.myco.com:25. The entry must be given in the format: host:port host Specifies the fully qualified domain name of the local sites SMTP server. For example: archie.myco.com Specifies the servers port number, usually 25.
name and port number of the SMTP server to use when sending e-mail notification.
port
3 Click OK to submit the change to
the database.
NOTE: There is no native SMTP server in the Windows NT environment. You must specify the host and port of an SMTP server for the StoryServer servers to use.
03/01/99
5-11
Enabling E-mail Notifications
When you enable e-mail notification, all assigned users with valid e-mail addresses in the CMS receive notification of task assignment according to the following criteria:
For... One-time tasks Workflow tasks Recurring tasks (first in the schedule) Recurring tasks (subsequent tasks in the schedule) Failed program tasks The appropriate users are notified... Immediately when the task is created. When the task rises to the top of the workflow (that is, it is the current task). When the recurring task is created. When the previous task is completed or when the previous task becomes late, whichever comes first. (Project owners only) When a program task in the project or workflow is unsuccessful.
If a user prefers not to receive e-mail regarding any task, you can delete the email address from their user information (see Editing a User Entry on page 5-8). You cannot let a user receive e-mail for some tasks and not others.
I To enable or disable e-mail notification for a StoryServer CMS:
2 Set E-mail Notifications to On or Off:
On - Sends task notification e-mail to all assigned users (those with e-mail addresses in their StoryServer user entries) when a task satisfies one of the previously defined criteria. Off - Does not send e-mail notification for any task assigned in this CMS.
3 Click OK to submit the change to the
database.
See also
Managing Groups on page 5-13
5-12
03/01/99
Managing Groups
Rules for Group Entries Adding a Group Entry Editing a Group Entry Cloning a Group Entry Deleting a Group Entry
Rules for Group Entries

Group entries allow project owners to assign tasks or authorization to several users without listing each user separately. You can then add and remove users from a group without changing the authorization settings in the Production Center tools. Rules governing StoryServer group names include:
can include letters, numbers, hyphens, and underscores can include upper- and lowercase letters cannot have spaces group names must be unique within StoryServer a group cannot be a member of another group
NOTE: We recommend the convention of using lowercase for user names and initial capitals for group names, for example, admin and Admin.
Adding a Group Entry

Admin users can add group entries to StoryServer. By default, the Admin group is the owner of the Base Project in the Production Center. After adding user entries in the Users page for additional owners, we recommend that you create a new group (for example, Baseowners) and make the owners members of that group rather than add the new owners to the Admin group. Include the admin user as a member of the Baseowners group. For all group entries, you can add a group entry with or without listing any users as members. A group must exist before you can add users to it.
03/01/99
5-13
I To add a group entry to the StoryServer database:

1 In the Group page of the
User/Group Manager primary window, click the New Group icon.

2 In the Group field, enter the
The Add Group window opens with the Details page displayed.
name for the new group.

3 (Optional) In the Description
Follow the guideline described in Rules for Group Entries on page 5-13.
field, enter a full name or more detail about the group.

4 Choose:
Add the group entry without assigning members by clicking OK. Continue to the Users page. Click Cancel.
The Add Group window closes and the group name is added to the Groups page of the User/Group Manager primary window. The Users page opens. The Add Group window closes without making any changes to the StoryServer database. The Users page opens.
5 To continue and add users to the
groups, click the Users tab at the top of the Add Group window.
6 Select one or more entries in the
The left arrow button becomes available.
Group does not include Users list.

7 Click the left arrow button.
The selected user names display in the Group includes Users list.
Editing a Group Entry

Admin users can edit any field in the Edit Group window pages except the Group field; you cannot change the groups name. (To change the groups name, you must delete the group and re-enter the information.) You can edit only one group entry at a time.
5-14
03/01/99
If you change a groups name, the change is not automatically reflected in projects and content items in the Production Center. You must make the name change manually in the Production Center. NOTE: If you modify a group entry for a user who is currently using a StoryServer tool connected to this database, you can affect the users authorization for some operations. For example, if you remove a user from a group and the user is attempting an operation authorized only for that group, the user may not be able to continue.
I To edit a group entry:
1 In the Groups page of the User/Group Manager
The Details icon becomes available.
primary window, select an entry.

2 Click Details to open the Edit Group window
with the Details page displayed.

3 Edit the fields in the Details page as necessary or
go to Step 5.
4 Choose:
Commit the group entry without changing group members by clicking OK. Continue to the Users page. Click Cancel.
The Edit Group window closes and appropriate changes appear in the Groups page of the User/Group Manager primary window. The Users page opens. The Edit Group window closes without making any changes to the StoryServer database. The User page opens.
5 To continue and change the groups member list,
click the Users tab at the top of the Edit Group window.
6 Choose
one or both:
Select one or more entries in the Group includes Users list. Click the right arrow button to move the entries to the Group does not include Users list. Select one or more entries in the Group does not include Users list. Click the left arrow button to move the entries to the Group includes Users list.
03/01/99
5-15
Cloning a Group Entry

An admin user can copy an existing group entry to create a new entry. The new entry has only the members of the copied entry. All other fields are blank for you to enter the new groups information.
I To copy a group entry and create a new entry:
1 In the Groups page of the User/Group
The Clone icon becomes available.
Manager primary window, select a group entry.

2 Click Clone.
The Copy Group window opens with the Details page displayed. See Adding a Group Entry on page 5-13. The Copy Group window closes and the group name is added to the Groups page of the User/Group Manager primary window. The Groups page opens. The Copy Group window closes without making any changes to the StoryServer database. The Groups page opens.
3 Add information to the fields. 4 Choose:
Add the group entry without changing the members by clicking OK. Continue to the Users page. Click Cancel.
5 To continue and modify the groups
member list, click the Users tab at the top of the Copy Group window.
6 Modify the groups member list. 7 Click OK or Cancel.
See Editing a Group Entry on page 5-14.
Deleting a Group Entry

Admin users can delete group entries from the StoryServer database. Removing a group entry does not remove its members from the database. If you delete a group, the group name is not automatically removed from projects and content items in the Production Center. You must delete the group name from Production Center projects and content items manually. NOTE: If you delete the group entry for a user who is currently working in a StoryServer tool connected to this database, you can affect the users authorization for some operations. For example, if the user is only viewing in the Admin Center tools, the operation can continue, but if a user is trying
5-16
03/01/99
to start a task where only the group membership authorizes the operation, the user may be unable to continue. Additionally, deleting a group entry for a user will prevent the user from receiving any e-mail addressed to the group.
I To delete a group from the StoryServer database:
1 In the Groups page of the User/Group
A confirmation prompt opens.
Manager primary window, right-click one or more group entries, and select Delete from the pop-up menu.
See also
Authorizing Business Center Users on page 5-17 Authorizing Development Center Users on page 5-18
Authorizing Business Center Users

Running reports on visitor data can consume system processing resources. To limit the number of users who can create, run, and edit reports, an Admin user can establish authorization for users and groups to work with visitor data through the Business Center tools. The Business Center tools must be installed for you to use this authorization effectively. You authorize users to create, run, and edit reports in specific folders using the Report Manager.
I To authorize users and groups to use the Report Manager:
03/01/99
5-17
2 Under Business Center
Users with full authorization Allows the specified users to create, run, and edit reports in both their personal and the shared folders using the Report Manager. Default value of nobody means no users have this authorization. The admin user should change this value to valid user IDs when Business Center use begins.
Authorization, enter user or group names in the text boxes or select from users and groups known to the CMS by using the ... button to open the Users with full authorization or Users with limited authorization window, as appropriate. See Authorizing Business Center Users on page 5-17.
Users with limited authorization Allows the specified users to run reports in the shared folder but also create, run, and edit reports in their personal folder using the Report Manager. Default value of nobody means no users have this authorization. The admin user should change this value to valid user IDs when Business Center use begins.
3 Click OK to submit the change to
the database.
See also
Authorizing Development Center Users on page 5-18
Authorizing Development Center Users

Through the CMS Details window, you designate which users have access to the Content Designerwhere they can create, read, write, and delete (if they created them) all Form Sets, Forms, and database tables in the system. Users can import existing database tables, but cannot change database columns in these tables. See Using the Content Designer.
5-18
03/01/99
I To authorize users and groups to use StoryServers Content Designer:

1 In the Configuration View primary window,
right-click the Content Management Server entry, and select Details from the pop-up menu.
2 Under Development Center Authorization ,
Specified users will have enter the Users with Content Designer authorization to alter info in Authorization. You can enter user or group StoryServers Content Designer. names in the text box or select from users and groups known to the CMS by using the ... button.
3 Click OK to submit the change to the database.
See also
Authorizing Business Center Users on page 5-17
03/01/99
5-19
5-20
03/01/99
6
Summary: Audience:
Managing StoryServer Files on Windows NT or Solaris
How to manage various directories and files that StoryServer creates when you install and configure your servers. Administrators of StoryServer 4.2 Basic Concepts on page 1-1
Overview Understanding Server Files Viewing StoryServer Log Files Understanding Tool Directories Understanding Preference Files
03/01/99
6-1
Overview
When you install and configure the StoryServer software for the Content Management Server (CMS) and Content Application Servers (CASs), StoryServer creates directories and files used by the various processes. Adding other tool sets, such as the Admin Center and Development Center, also creates directories and files. In addition to the StoryServer files in your file system, you will see items in your database related to StoryServer such as database keys, indexes, and so forth. Contact your database administrator for more information on these items.
See also Appendix B, StoryServer File Reference Appendix A, StoryServer Process Reference
Understanding Server Files

Audience: Topics include: Administrators of StoryServer 4.2
Overview of Configuration Files CMS Configuration File (pm.cfg) Other CMS Files and Directories CAS Configuration Files Other CAS Files and Directories Understanding Configuration File Interaction
When you set up the StoryServer servers on Windows NT, StoryServer creates files and directories in the file system(s) you select, relative to the installation path. Files are installed in the same path on each host, whether the CMS or one of the CASs:
NT \install-path\StoryServer n\Engines\Rn\
specified when you installed the server software with setup.exe

S UN /install-path/StoryServer/Rn/
specified when you installed the server software with ssinstall.sh For information on file location variables, see Common Path Name Variables on page 1-5.
6-2
03/01/99
An example setup might have the CMS and one CAS installed and configured on one host, another CAS installed and configured on another host, and StoryServer tools installed on yet another host. (See Figure 1-1, StoryServer Components.)
Overview of Configuration Files

Name pm.cfg Location CMS & CAS (for path and details, see pm.cfg on page B-29.) Function Contains variables and configuration information for the CMS processes, including the CMS location, which remote CASs must maintain in order to access the CMS. See also pm.cfg on page B-29. Contains variables and information for all the CAS processes, including comments about the variables and valid values. See also StoryServer.cfg on page B-33. Contains global information for the Page Generator processes in a StoryServer installation. Allows Template developers to create additional Tcl commands and variables for Page Generators. See also delivery.tcl on page B-15.
StoryServer.cfg
CAS (for path and details, see StoryServer.cfg on page B-33.) CAS (for path and details, see delivery.tcl on page B-15.)
delivery.tcl
CMS Configuration File (pm.cfg)

When you configure the CMS, the CMS configuration file, pm.cfg, is created in the: NT \conf-n\Production subdirectory, for example:
D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\Production\pm.cfg
S UN /conf/Production subdirectory, for example

/opt/StoryServer/R4.2/conf/Production/pm.cfg.
This file contains variables and information for all the CMS processes. The CMSs CAS(s) access the pm.cfg to find where the CMS is running and for database information such as the SYSTEM_DB_* and TEXTSIZE settings.
03/01/99
6-3
For more information on editing the file, see Editing the pm.cfg File on Windows NT on page 11-2. Solaris users will edit the pm.cfg file directly through their preferred text editor. TIP: The file also includes comments about the variables and valid values. A copy of the CMSs pm.cfg file is included in each remotely installed CAS so that the remote CAS has the location of the CMS. You can edit the CMSs pm.cfg file, but the changes do not automatically propagate to the remote CAS(s) copies. To make the new information available to remotely installed CASs, you must run:
For... NT S UN Run.. The StoryServer Platform Configuration Program on the remote CAS. The remote CAS command: admin update_pmcfg See also: Updating a Remotely Installed CASWindows NT only on page 8-9. Updating a Remotely Installed CASSolaris only on page 8-11.
/install-path/StoryServer/Rn/conf/host-port-number/admin update_pmcfg
The program/command contacts the CMS and transfers the information to the remote CASs copy of the pm.cfg.
Other CMS Files and Directories

The CMS files and directories in the table are given relative to the following directories:
NT \install-path\StoryServer n\Engines\Rn S UN /install-path/StoryServer/Rn File or Directory Name File or Directory Location NT admin.bat \conf-n\Production\ expire.exe \taskbin\winnt\ S UN admin /conf/Production expire /taskbin/solaris Program to stop/start CMS Program to expire records, files, and templates Function
6-4
03/01/99
File or Directory Name File or Directory Location NT flushcache.bat \taskbin\winnt\ launch.exe \taskbin\winnt\ S UN flushcache /taskbin/solaris launch /taskbin/solaris logroller /taskbin/solaris pm.log \conf-n\Production\ pm.log /conf/Production
Function
Program to flush cached pages Program to launch records, files, and templates Program to archive log files Levels 3 and 4 error log for CMS dispatch service. See Viewing StoryServer Log Files on page 6-14. Levels 3 and 4 error log for timed event service. See Viewing StoryServer Log Files on page 6-14. Working directory for timed event program tasks. Program to version records, files, and templates Levels 3 and 4 error log for master requesthandler service. See Viewing StoryServer Log Files on page 6-14. Levels 3 and 4 error log for request-handler slave processes. See Viewing StoryServer Log Files on page 6-14.
ted.log \conf-n\Production\
ted.log /conf/Production
TedTasksWorkingDirsRoot \conf-n\Production\ version.exe \taskbin\winnt\ vhs.log \conf-n\Production\
TasksWorkingDirsRoot /conf/Production version /taskbin/solaris vhs.log /conf/Production
vhs.log.id \conf-n\Production\
vhs.log.id /conf/Production
03/01/99
6-5
File or Directory Name File or Directory Location NT VhsProtoDocRoot \conf-n\Production\ S UN VhsProtoDocRoot /conf/Production
Function
Directory for request handler working copies of the static files that it has processed
CAS Configuration Files

Two files affect a CASs configuration: StoryServer.cfg and delivery.tcl. On each remote CAS, there is also a CAS copy of the CMSs pm.cfg file.
StoryServer.cfg
The StoryServer.cfg file contains variables and information for all the CAS processes, including comments about the variables and valid values. NT When you edit the StoryServer.cfg file using the StoryServer Platform Configuration Program, the program gives you the option of propagating the changes to the CMS. For more information on editing the file, see Editing the StoryServer.cfg File on Windows NT on page 11-3. S UN If you edit the StoryServer.cfg file, use the /conf/host-port-number/admin updatepe command to propagate the changes to the CMS. For information on using the admin updatepe command, see Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12. For information on editing StoryServer.cfg variables, see Tuning StoryServer on Solaris on page 12-1. Each CAS contains its own StoryServer.cfg, which is located in the following subdirectory when you configure the CAS:
NT \conf-n\host-port-number S UN /conf/host-port-number
6-6
03/01/99
host port number
Indicates the name of the web server host for the CAS. Indicates the port number for the CASs web server. Indicates the sequence number automatically assigned to this CAS on the web server. (The sequence number appears only after the second and subsequent CASs are configured for the port.)
An example location would be

NT D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\farley-9096-2\StoryServer.cfg S UN /opt/StoryServer/R4/conf /farley-9096-2/StoryServer.cfg.
delivery.tcl
An additional configuration file, delivery.tcl, is created at the path level above individual CASs, allowing it to be shared by multiple CASs on a single host:
NT \install-path\StoryServer n\Engines\Rn\conf-n\delivery.tcl. S UN /install-path/StoryServer/Rn/conf/delivery.tcl.
The file lets the template developer affect the Page Generator process in each \host-port-number subdirectory of this paths installation.
See also Setting Up StoryServer-wide Variables and Procedures on page 9-5.
CAS copy of the CMSs pm.cfg file
While a CAS installed on the same host as its CMS shares the CMSs pm.cfg file, a CAS installed on another host has a copy of the CMSs pm.cfg file. In other words, if you install StoryServer and configure one or more CASs on a remote host from their CMS, a copy of the CMSs pm.cfg file is included in the directory:
NT \install-path\StoryServer n\Engines\Rn\conf-n\Production S UN /install-path/StoryServer/Rn/conf/Production
which is created with the remote CAS(s) so that the CAS(s) have the location of the CMS. You can edit the CMSs original pm.cfg file, but the changes do not propagate to the remote CASs copies unless you update them.
03/01/99
6-7
See Updating a Remotely Installed CASWindows NT only on page 8-9, or Updating a Remotely Installed CASSolaris only on page 8-11. NOTE: A CASs StoryServer.cfg file references the pm.cfg file on its local host.
Other CAS Files and Directories

The files for a CAS shown below are given relative to following install path:
NT \install-path\StoryServer n\Engines\Rn\conf-n\host-port-number
for example:
D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\farley-9096-2\ S UN /install-path/StoryServer/Rn/conf/host-port-number
for example:
/opt/StoryServer/R4/conf/farley-9096-3
In the table below, all files are in the host-port-number directory itself, except where indicated. Any paths are relative to the host-port-number directory.
File or Directory Name Location (if other than host-port-number directory) NT admin.bat cmd.log S UN admin cmd.log Program to stop/start CAS Levels 3 and 4 error log for Cache Manager. See Viewing StoryServer Log Files on page 6-14. Process ID for Cache Manager Database error log for Page Generator service (see the LOG template command) Database error log for Page Generator slave process (see the LOG template command) Use
cmd.pid ctld.log ctld.log
ctld.log.id
ctld.log.id
6-8
03/01/99
File or Directory Name Location (if other than host-port-number directory) NT S UN ctld.pid ctldinfo.log ctldinfo.log
Use
Process ID for Page Generator master process Levels 3 and 4 error log for Page Generator master process. See Viewing StoryServer Log Files on page 6-14. Levels 3 and 4 error log for Page Generator slave process. See Viewing StoryServer Log Files on page 6-14. Global Tcl information for all Page Generators installed under the same \install-path\StoryServer n\ Engines\Rn\conf-n location
ctldinfo.log.id
ctldinfo.log.id
delivery.tcl ..\
delivery.tcl ../
docroot ..\..\ lastsession.cfg ..\..\adm\ metafiles obj.conf Netscape servers only PadArchiveDir
docroot ../../ lastsession.cfg ../../adm/ metafiles obj.conf Netscape servers only PadArchiveDir
Contains online StoryServer information (development CAS only) Contains last configuration information as defaults for the next CAS configured on the host Contains template variations Backup copy of NSAPI configuration file for Netscape server (not present for IIS) Contains last version of replaced or deleted static files known to Placement Manager Levels 3 and 4 error log for Placement Manager master service. See Viewing StoryServer Log Files on page 6-14.
pad.log
pad.log
03/01/99
6-9
File or Directory Name Location (if other than host-port-number directory) NT pad.log.id S UN pad.log.id
Use
Levels 3 and 4 error log for Placement Manager slave process. See Viewing StoryServer Log Files on page 6-14. Process ID for Placement Manager Contains information tracking the progress of Placement Manager operations Error log for optional Observation Manager Configuration file for all this CASs services Template cache shared by Template Manager and Page Generator Levels 3 and 4 error log for Template Manager. See Viewing StoryServer Log Files on page 6-14. Process ID for Template Manager
pad.pid PadWorkDir PadWorkDir
pznd.log StoryServer.cfg templates tmd.log
pznd.log StoryServer.cfg templates tmd.log
tmd.pid
Understanding Configuration File Interaction

Topics include:
Configuration File Influence File Interaction on a Single Host File Interaction with Multiple Hosts
Whether on Solaris or Windows NT operating systems, the StoryServer pm.cfg, StoryServer.cfg, and delivery.tcl configuration files interact in several ways.
6-10
03/01/99
Configuration File Influence
As shown in Figure 6-1, the settings in each configuration file affect the following portions of the StoryServer system:
pm.cfg
Affects the entire StoryServer system associated with it.

StoryServer.cfg
Affects all the CASs processes.

delivery.tcl
Affects the Page Generator processes of the CASs configured on the same host that talk to the same CMS. These influences are implemented by the way in which the configuration files interact.
03/01/99
6-11
Figure 6-1:
Configuration files influence on a single host
StoryServer system on a single host
pm.cfg influences the whole StoryServer system. CMS processes CAS with its own StoryServer.cfg CAS with its own StoryServer.cfg ctld process ctld process
CAS with its own StoryServer.cfg ctld process
A single delivery.tcl affects ctlds on all CASs configured on this host with this CMS
File Interaction on a Single Host
When CASs are configured on the same host as the CMS, each CASs StoryServer.cfg file sources (reads) the CMSs pm.cfg file at install time. A statement near the end of each CASs StoryServer.cfg file causes the CASs ctld process (Page Generator) to read this StoryServer systems delivery.tcl file. The order of the information is important; the last-read setting overrides any previously read setting. The following example from a StoryServer.cfg file on a Solaris system shows the order of the
6-12
03/01/99
variable settings and some comments on what process accesses the information.
...most of the StoryServer.cfg file omitted CASs tmd process uses the SYSTEM DATABASE SETTINGS in pm.cfg ## SYSTEM DATABASE SETTINGS set STORYSERVER_PMCFG /opt/StoryServer/R4.2/conf/Production/pm.cfg source $STORYSERVER_PMCFG CASs ctld process uses the CONTENT DATABASE SETTINGS ## CONTENT DATABASE SETTINGS set ORACLE_HOME /u/oracle/app/oracle/product/8.0.3 set KHAN KHAN set DB_CLIENT dbconnect set vdbmsg(rwdblib) librwora_mt.so set set set set set set set CONTENT_DB_TYPE CONTENT_DB_SERVER CONTENT_DB_DATABASE CONTENT_DB_SID CONTENT_DB_USERNAME CONTENT_DB_PASSWORD CONTENT_DB_RWDBLIB Oracle KHAN "" ourID_thing ourID_thing ourID_thing ourID_thing
...some settings omitted CASs ctld process uses the delivery.tcl file for additional instructions ## Include external Tcl Files or DLOAD other API modules here if {[info exists _Process] && $_Process == "ctld" } { source /opt/StoryServer/R4.2/conf/delivery.tcl DLOAD libBOBTclClient.so InitBobClient } ...online docs setting omitted
NOTE: The Page Generator process also implicitly sources the /install-path/StoryServer/Rn/lib/stdlib.tcl file for most of the StoryServer Tcl commands.
03/01/99
6-13
File Interaction with Multiple Hosts
When CASs are configured on hosts other than the CMSs, the CASs on each remote host get a copy of the CMSs pm.cfg file at install time. If the CMSs pm.cfg file changes, these remote copies are not automatically updated. Because a CASs StoryServer.cfg file also reads the local version of the pm.cfg, the versions of the pm.cfg should be kept current across all CASs associated with the CMS. For information on updating a remote pm.cfg file, see Updating a Remotely Installed CASWindows NT only on page 8-9, or Updating a Remotely Installed CASSolaris only on page 8-11. Changes made to the StoryServer.cfg file for any CAS (remotely configured or not) should be propagated to the CMS. For example, if the database server settings in the CAS are different from those on the CMS, template preview will not work. For information on using the admin updatepe command, see Editing the Configuration Files on Windows NT on page 11-2, or Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12. A delivery.tcl file influences only the ctld processes of CASs configured on its host. If you want all the ctld processes in multiple-host StoryServer system to have the same information, you must copy your preferred version, using your preferred method, into the remote host locations, overwriting the existing delivery.tcl file(s).
See also Appendix B, StoryServer File Reference Appendix A, StoryServer Process Reference Viewing StoryServer Log Files on page 6-14
Viewing StoryServer Log Files

Viewing the EventLog Event Viewer on Windows NT Archiving the StoryServer.errors file on Solaris
6-14
03/01/99
StoryServer provides a mechanism for logging errors and messages: NT The EventLog service records events, errors, and messages for tools. S UN The StoryServer.errors file, usually found in the /var/adm directory, logs CAS errors and messages managed by the syslogd(1M) process on Solaris. Error logging and behavior are set in the following files for the CMS and CAS(s):
pm.cfg contains log levels for CMS processes. NT \install-path\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.cfg S UN /install-path/StoryServer/Rn/conf/Production/pm.cfg StoryServer.cfg contains log levels for CAS processes. NT \install-path\Vignette\StoryServer n\Engines\Rn \conf-n\host-port-num\StoryServer.cfg S UN /install-path/StoryServer/Rn/conf/host-port-number /StoryServer.cfg
Level 3 and 4 errors are logged in files associated with the processes that encountered the errors. For the names and locations of these log files, consult the tables in Other CMS Files and Directories on page 6-4 and Other CAS Files and Directories on page 6-8. The following table shows StoryServer default log levels and message distribution.
Written to Log Level 1 2 3 4 Message Type error warning audit debug NT EventLog service Eventlog service service log file service log file S UN syslogd syslogd process log file process log file
03/01/99
6-15
An example service or process log file location would be:

NT C:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\Production\ted.log S UN /install-path/StoryServer/Rn/conf/Production/ted.log
Viewing the EventLog Event Viewer on Windows NT

I To view StoryServer errors and messages (levels 1 or 2), use the EventLog Event Viewer: 1 2 3
Using your preferred method, open the Programs\Administrative Tools\Event Viewer. From the Log menu, select Application. From the Application Log list, double-click the StoryServer process whose log you want to view, for example, vhs, pad, or ted. The Event Detail window displays the messages and errors for the service name you selected.
Close the Event Viewer.
Archiving the StoryServer.errors file on Solaris

You can archive the StoryServer.errors file to minimize the size of a single file by using the StoryServer logroller command as a Program task in the Production Center. By default, logroller archives the files the following way:
1 2 3
Looks for the files in /var/adm. Copies the log to a file named StoryServer.errors.timestamp and puts the copies in /var/adm. Clears the StoryServer.errors file to 0 (zero) length.
The timestamp that logroller appends to the archive copies specifies the date and time, including seconds, of the operation. Examples of copy file names include: StoryServer.errors.97-02-18_23:04:09
6-16
03/01/99
With the logroller options, you can specify alternate source and destination directories and different names for the log files. You can also have logroller copy the log files without clearing them. For example:
logroller -c
For information on setting program tasks, see Production Center Guide. For more information on the logroller command, see the logroller reference page in Appendix A, StoryServer Process Reference.
See also Appendix B, StoryServer File Reference Appendix A, StoryServer Process Reference Understanding Tool Directories on page 6-17
Understanding Tool Directories

Windows Tool Directories Solaris Tool Directories Macintosh Tool Folders
StoryServer creates folders (directories) for its tool files when the tool sets are installed.
Windows Tool Directories

For a Windows installation of the tools, the following folders are installed in these default locations:
C:\Program Files\Vignette \StoryServer n\bin Contains the programs for StoryServer tools, including the executable (ss.exe) and shortcut for the StoryServer launch bar. Contains Java files and directories for the tools. Contains files used by the tool programs.
C:\Program Files\Vignette \StoryServer n\java C:\Program Files\Vignette \StoryServer n\lib
03/01/99
6-17
Solaris Tool Directories

For a Solaris installation of the tools, the following directories are installed at the location you specify:
/install-path/StoryServer /Rn/ui/bin /install-path/StoryServer /Rn/ui/java /install-path/StoryServer /Rn/ui/lib Contains the program for the StoryServer launch bar. Contains Java files and directories for the tools. Contains files used by the tool programs.
The following files are also installed in the /install-path/StoryServer/Rn/ui/ directory:

setinfo uninstall.sh Stores the tools that are installed. Used when the tool set(s) are uninstalled.
Macintosh Tool Folders

For a Macintosh installation of the tools, StoryServer installs the following:
/install-path/Vignette System Folder/Preferences /Vignette System Folder/Extensions /MRJ Libraries Contains the macrodata, copyright, and other tool files. Contains the Preferences file. StoryServer installs some items in this existing folder.
See also
Appendix B, StoryServer File Reference Appendix A, StoryServer Process Reference Understanding Preference Files on page 6-19
6-18
03/01/99
Understanding Preference Files

macrodata File Preferences File File Locations
StoryServer saves various preference information in two files:

macrodata - Contains macros and macro preferences from your work
with templates. The macrodata file is installed with the client installation. For your own use, StoryServer copies the files into your own home directory. The installed version remains in tact, and you can revert to it at any time if you wish.
Preferences - Contains preferences for the browser and CAS to use
when previewing templates or viewing on-line documentation. It also stores default login info. The Preferences file is generated and updated as necessary. The local versions of each file are stored under the users home directory. For the home directory locations of these files, see File Locations on page 6-21.
macrodata File
In the Development Center tools Macro Editor, you can create your own macros, customize versions of the povided macros, and maintain a list of your preferred macros. All of this information is stored in the macrodata file for use in the Template Editor and Visual Template Editor in the StoryServer Development Center. Your customized macro set becomes the default for your template editing sessionswhether with the Template Editor or the Visual Template Editor; both editors will save macro information to the same macrodata file.
03/01/99
6-19
The default install version of the macrodata file is stored in the following directories:
NT C:\Program Files\Vignette\StoryServer n\ Clients\lib\macrodata S UN /install-path/StoryServer/Rn/ui/lib/macrodata MAC /install-path/Vignette/macrodata
The Development Center tool copies the installed file to your own home directory, and adds your modifications or additions to the file the first time you save in the Macro Editor window. The Development Center then updates this local version of file with each subsequent save. For the home directory location of the file, see File Locations on page 6-21. You can edit your file manually and let other users copy it into their home directories if they want to use your macros in their Macro Editor sessions. For more information, see the chapter on using the Macro Editor in Working with Tools and Templates. To revert to the shipped default macros, remove your customized macrodata file. The shipped macros are used beginning with your next template editing session.
Preferences File
You set preferences for the browser and CAS to use when previewing templates in the Production Center tool set and in the Development Center. Your browser preference is also used for viewing online documentation in other StoryServer tools. These settings are saved in a Preferences file. The Preferences file stores your preferred list of browsers from which to choose for previewing templates and viewing online documentation. This file also stores the specific web server to use for previewing. StoryServer generates and updates this file when you:
Save your login defaults while logging in to StoryServer. Save your preferences by using the Preferences option from the File menu
of the StoryServer launch bar. You should not edit this file manually. For more information on using the StoryServer launch bar to set your browser preferences, see the section on setting browser preferences in Running StoryServer Tools.
6-20
03/01/99
File Locations
StoryServer stores your macrodata and Preferences files in different locations, depending on the operating system of the tool set host. NOTE: This location is different from the install location for the macrodata file. StoryServer makes a copy of that file and stores the copy in the one of the directories below.
NT - The default location in which to store both files is the Vignette
subdirectory in your home directory.

S UN - The default location in which to store both files is the .vgn
subdirectory in your home directory.

MAC - The default locations in which to store the files are:

macrodata - in a Vignette folder in your selected installation folder. Preferences - in the System Folder->Preferences->Vignette folder.
Appendix B, StoryServer File Reference Appendix A, StoryServer Process Reference
See also
03/01/99
6-21
6-22
03/01/99
7
Summary; Audience:
Working with the Database on Windows NT or Solaris
How to manage the StoryServer database, which contains templates, content records for web pages, and production management information for tracking templates and content. Administrators of StoryServer 4.2 Basic Concepts on page 1-1
Overview Requirements Understanding StoryServer Database Tables Database Password Encryption
03/01/99
7-1
Overview
The StoryServer database contains templates, the content records for the web pages generated by the CAS(s), and production management information for tracking both templates and content in the Production Center. You can disable StoryServer access to the database temporarily. For information on StoryServer content types and how content is accessed through the database tables, see StoryServer 4 Overview. You will see other items in your database related to StoryServer such as database keys, indexes, and so forth. Contact your database administrator for more information on these items.
Requirements
Database Permissions Database Size
The following sections give requirements and recommendations for using the StoryServer database on Windows NT or Solaris. TIP: We encourage you to back up your database regularly as recommended by your database vendor. This practice provides some protection for your StoryServer database information.
7-2
03/01/99
Database Permissions
The username under which StoryServer operates in the StoryServer database needs the following permissions for the various database types:
For database... NT Microsoft SQL Server NT/ S UN Sybase NT/S UN Oracle S UN Informix SQL CONNECT and RESOURCE permissions for the table space containing the StoryServer installation. The StoryServer database user needs... Access rights to create and drop tables and to insert and delete rows. The user also needs select permissions on the following system tables: syscolumns, systypes, sysobjects, sysreferences, and sysusers.
Database Size
For information on database size requirements, see Platform Installation & Configuration Guide (printed copy shipped with product). In addition, include enough space to accommodate your site templates, content, and logs. The necessary space varies depending on the size of your current site and future needs.
See also Understanding StoryServer Database Tables on page 7-3
Understanding StoryServer Database Tables

Audience: Administrators of StoryServer 4.2
StoryServer creates, maintains, and manages its own tables in the database, including tables for the CASs and for the CMS. (The table names are the same for both Windows NT and Solaris operating systems.) The table below shows the tables and briefly describes their use.
03/01/99
7-3
Table Name next_id
Type CAS
Description Tracks next identifier to use in a given StoryServer database table when asked for one, for example, by the GET_NEXT_ID StoryServer command Stores all templates Stores template paths Created for user convenience to store graphics, text, other content Stores Vignette users/groups authentication data Stores an entry for each authorized Business Center user and all report definitions that the user has created. Stores personalization content catalog information Contains StoryServer configuration information Production management information for templates, files, content records Stores metadata about Forms used by Content Designer ITEM commands Stores metadata about Fields (columns) in database tables used by Content Designer ITEM commands Stores metadata about tables managed by Content Designer and used by Content Designer ITEM commands Holds internal information about CMS classes and objects Contains the content designs from the Content Designer. See Using the Content Designer. Stores information about database tables that the Content Designer manages. See Using the Content Designer. Contains the list of browser features Contains form set information from the Content Designer. See Using the Content Designer. Stores personalization keyword registry information Contains project management information
template template_path vgn_altcontent vgn_an vgn_bz vgn_cc vgn_cf vgn_ci vgn_dal_collection vgn_dal_field vgn_dal_table vgn_dbconfig vgn_dc vgn_dt vgn_features vgn_fs vgn_kr vgn_pr
CAS CAS CAS CMS CMS & CAS CMS & CAS CMS CMS CMS & CAS CMS & CAS CMS & CAS CMS CMS CMS CAS CMS CMS & CAS CMS
7-4
03/01/99
Table Name vgn_scratch vgn_tk vgn_uc vgn_ur vgn_variations_map vgn_utn vgn_uvn vgn_version vgn_version_tag
Type CMS CMS CAS CAS CAS CMS & CAS CMS & CAS CMS CMS
Description Temporary working area for the CMS Contains task management information Stores personalization profile-marker-by-user information Stores personalization user registry information Maps templates to sets of browser features Created by Content Designer to hold content A view of a Content Designer-managed table Stores information on versions of templates, files, and records Stores labels associated with versions of templates, files, and records
NOTE: With the vgn_utn and vgn_uvn tables above, the view number will not necessarily be in sync with the table number.
See also Database Password Encryption on page 7-5
Database Password Encryption

Configuration Encryption in Templates
When you configure a CMS, you provide information about the database in which StoryServer will store project, template, record, and file information the system database. The information, which includes the database password, is stored in the CMSs configuration file, pm.cfg. StoryServer now accepts encrypted passwords. When you configure a CMS, StoryServer encrypts the database password by default. When you configure a CAS, the configuration process puts the same database information, including the encrypted password, in the CASs configuration
03/01/99
7-5
file, StoryServer.cfg. (Typically, content data is stored in the same database as the StoryServer system data. However, you can modify the database settings if you want that CAS to access and store data in a different content database.) The CMS and CAS configuration files include variables that control whether or not the database passwords are encrypted. The Configuration section discusses the variables. If your site is configured to encrypt database passwords, then you must encrypt the password in each template where it occurs, using the StoryServer encrypt command. If database password encryption is turned on and existing templates access a the database without encryption, the templates must be modified for encryption. For procedure information, see Encryption in Templates on page 7-9.
Configuration
Topics include:
Turning Off Database Password Encryption Turning Encryption Back On Changing the Database Password
Two configuration variables control whether database passwords are encrypted:

CMS (system) database The SYSTEM_DB_PASSWORD_ENCRYPTED
variable in the pm.cfg file.

CAS (content) default database The
vdbmsg(password_encrypted) variable in the StoryServer.cfg file. By default, these variables are set to yes. NOTE: If you upgraded from StoryServer 4.1 to StoryServer 4.2, the variables are set to no by default. See the Upgrade Guide from StoryServer 4.1. You can change the default configuration. Guidelines:
The CMS setting and the setting for CASs dont have to match. (Typically,
it makes sense for them to be the same, especially if StoryServer system data and content are stored in the same database.)
7-6
03/01/99
If any templates include a database password (for example, to connect to a
database thats not the default content database), then all CASs must have the same setting. Otherwise templates that include a password to access a database will fail on at least one CAS. (The error is that the template cant connect to the database.) For example, if the vdbmsg(password_encrypted) variable in the development CASs StoryServer.cfg file is set to yes and the live CASs variable is set to no, a template that encrypts a database password will succeed on the development CAS but fail on the live CAS.
Turning Off Database Password Encryption
I To turn off encryption of the StoryServer system database password: 1
Start editing the CMSs pm.cfg file. The default location of the file on Solaris is /install-path/StoryServer/Rn/conf/Production. On Windows NT, you edit the file through the StoryServer Platform Configuration Program. (See Editing the pm.cfg File on Windows NT on page 11-2.)
2 3
In the CMSs pm.cfg file, in the ## DATABASE SERVER SETTINGS section, set SYSTEM_DB_PASSWORD_ENCRYPTED to no. Find the SYSTEM_DB_PASSWORD variable (just above SYSTEM_DB_PASSWORD_ENCRYPTED), and replace the encrypted password with the plain-text password. Save and commit your changes.
Any CASs you configure after setting SYSTEM_DB_PASSWORD_ENCRYPTED to no will also have encryption turned off.
I To turn off password encryption for the default content database: 1
Start editing the CASs StoryServer.cfg file. The default location of the file on Solaris is /install-path/StoryServer/Rn/conf/host-port-n. On Windows NT, you edit the file through the StoryServer Platform Configuration Program. (See Editing the StoryServer.cfg File on Windows NT on page 11-3.)
03/01/99
7-7
2 3 4 5
Find the vdbmsg(password_encrypted) variable in the ## CONTENT DATABASE SETTINGS section of the file, and set it to no. In the same section of the file, find the CONTENT_DB_PASSWORD variable, and replace the encrypted password with the plain-text password. Save and commit your changes. Repeat the procedure for each CAS thats already configured.
Turning Encryption Back On
You can encrypt passwords with the encrypt command, which resides in the operating-system directory under the StoryServer bin directory. The default locations:
S UN
/install-path/StoryServer/Rn/bin/solaris
NT
\Program Files\Vignette\StoryServer n\Engines\Rn\bin\winnt
If you turn off encryption and later decide to turn it back on, follow these steps:
1
Use the encrypt command to get the encrypted versions of the system and content database passwords. (The passwords will be the same if your site stores content in the StoryServer database.) At the command line, enter: encrypt password For example, to encrypt the password l1vely, enter encrypt l1vely. encrypt displays a value like this: 21,Hs8g3nvRG. You may want to direct the output to a file. For example, on Windows NT:
encrypt l1vely > systems\dbpass
Substitute the encrypted StoryServer system database password for the plain-text password in the CMSs pm.cfg file. Save and commit the changes. Substitute the encrypted content database password for the plain-text password in each CASs StoryServer.cfg file. Save and commit the changes.
7-8
03/01/99
Changing the Database Password
If encryption is turned on and you change the database password, encrypt the new password and substitute it for the old password in the configuration files. Turning Encryption Back On on page 7-8 explains the procedure.
Encryption in Templates
Topics include:
Encrypting the Password in Templates Overriding the Configuration
A template can set variables to identify a particular database to access, for example, if the template needs to store or access a row in a content database other than the default database (identified in the StoryServer.cfg file). One of these variables is PASSWORD. NOTE: Typically, templates dont need to set the PASSWORD variable to access the StoryServer system database or the CAS default content database. They can default the password value instead. See the RECORD and ROW_INSERT commands. If a template sets the PASSWORD variable, then the password must be in the formencrypted or not encryptedthat StoryServer expects. The template can do this in either of two ways:
Match the StoryServer configuration (the encryption variable setting in
pm.cfg or StoryServer.cfg). If encryption is turned on, then encrypt the password.

Override the StoryServer configuration.
The next sections explain how to encrypt the password and how to override the configuration. NOTE: A template never has to decrypt a password.
Encrypting the Password in Templates
I To encrypt the database password in the templates that include the PASSWORD variable, follow these steps: 1
Find the templates that contain the password. You can search for these keywords in the templates directory: SET PASSWORD, CONNECT, and VDBCONNECT.
03/01/99
7-9
S UN Use grep or a similar command to search the templates directory:

/install-path/StoryServer/Rn/conf/host-port-n/templates
NT Use find or a similar command to search the templates directory:

\install-path\StoryServer n\Engines\Rn\conf-n \host-port-number\templates 2
Create the encrypted value of the database password with the StoryServer encrypt command. (For the encrypt path, see Turning Encryption Back On on page 7-8.) At the command line, enter: encrypt password For example, to encrypt the database password onion3X:
encrypt onion3X
encrypt returns a value like this: 2.ltw8LTHhVO.8l5. Or to encrypt the database password onion3X and write the encrypted value to a file, on Solaris:
encrypt onion3X >> /ssdb/dbadmin 3
In each template, replace the plain-text password with the encrypted password.
Overriding the Configuration

I To override the default encryption configuration, a template can set the password encryption variable to the opposite of its configured value before setting the database password:
To override the system database configuration, a template sets the
SYSTEM_DB_PASSWORD_ENCRYPTED variable.
To override the content database configuration, a template sets the
vdbmsg(password_encrypted) variable. For example, if encryption is turned on in pm.cfg for the system database password:
[SET SYSTEM_DB_PASSWORD_ENCRYPTED no] [SET [SET [SET [SET USERNAME storysdb] PASSWORD atlas44] SERVER barbell] DATABASE oramain]
7-10
03/01/99
Or if encryption is turned off in StoryServer.cfg for the content database password:

[SET vdbmsg(password_encrypted) yes] [SET [SET [SET [SET USERNAME storycdb] PASSWORD 2z:HDKsl7HLR] SERVER barbell] DATABASE oraC2]
NOTE: The template doesnt have to reset the encryption variable to its default value unless the template logic requires it. When a template sets the variable, its value is changed only within the context of the template evaluation.
See also Managing StoryServer Processes on Windows NT or Solaris on page 8-1
03/01/99
7-11
7-12
03/01/99
8
Summary: Audience:
Managing StoryServer Processes on Windows NT or Solaris
How to manage the CMS and CAS processes (services) through the Configuration View, Start menu options, or a command-line interface. Administrators of StoryServer 4.2
Before you begin:
Basic Concepts on page 1-1 Monitoring StoryServer Servers and Processes on page 4-1 Resetting CAS Processes Locating admin Commands Stopping and Starting the CMS with the admin Command Stopping and Starting the CAS with the admin Command Stopping and Starting with the Start Menu OptionsWindows NT only Updating a Remotely Installed CASWindows NT only Updating a Remotely Installed CASSolaris only Notifying the CMS of changes to StoryServer.cfgSolaris only Verifying CAS ProcessesSolaris only Managing Page Generation
Topics include:
03/01/99
8-1
Resetting CAS Processes

If you have changed a configuration file affecting the Page Generator or Template Manager process (for example, pm.cfg or StoryServer.cfg), you must reset the processes (services) to make them reread the configuration file(s). For more information on changing the pm.cfg and Storyserver.cfg files, see Tuning StoryServer on Windows NT on page 11-1, or Tuning StoryServer on Solaris on page 12-1. The reset operation does not stop and restart the process. For information on starting and stopping a process, see Stopping and Starting with the Start Menu OptionsWindows NT only on page 8-8 or Stopping and Starting the CAS with the admin Command on page 8-6. Of the five CAS processes, you can only reset the Page Generator and the Template Manager. NOTE: No reset operation is available for the Cache Manager, Observation Manager, or Placement Manager processes.
I To reset a Page Generator or Template Manager process: 1
In the Configuration View primary window, expand a CAS entry to show the CASs processes whose Page Generator or Template Manager process you want to change. Right-click the Page Generator or Template Manager process entry, and select Reset from the pop-up menu that appears. A prompt asks you to verify that you want to reset the process. Click OK to continue. At this point, the Page Generator rereads the following files:

StoryServer.cfg pm.cfg stdlib.tcl delivery.tcl
Or the Template Manager rereads:

StoryServer.cfg pm.cfg
8-2
03/01/99
For file locations, see StoryServer File Reference on page B-1. The Template Manager also removes the current template cache and generates a new one. NOTE: If StoryServer is unable to communicate with the CAS process, a warning displays. Click OK to continue. A notice advises that the process was not reset. Click OK to continue. See Stopping and Starting a CAS from the Start Menu on page 8-9.
4 5
When the operation is complete, a notice informs you that Page Generator or Template Manager has been reset. Click OK to continue.
See also Locating admin Commands on page 8-3
Locating admin Commands

CMS admin CAS admin
For those operations available from the command line, the CMS and each CAS have their own admin command. You must have system admin user privileges on the host where the CMS or CAS is installed in order to use its admin command.
CMS admin
The CMS admin command affects the CMS processes and is located at:
NT \install-path\StoryServer n\Engines\Rn\conf-n\Production\admin.bat S UN /install-path/StoryServer/Rn/conf/Production/admin
For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer 4 \Engines\R4.2\conf-2\Production\admin.bat
03/01/99
8-3
S UN /opt/StoryServer/Rn/conf/Production/admin
For information on this command-line interface, see the admin (CMS) reference page.
CAS admin
Each CAS has its own admin command that affects the its own processes. For each CAS, the admin command is located at:
NT \install-path\StoryServer n \Engines\Rn\conf-n\host-port-number\admin.bat S UN /install-path/StoryServer/Rn/conf/host-port-number/admin
NT D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\art.myco.com-93-2\admin.bat S UN /myHost/StoryServer/R4.2/conf/antone-9091-2/admin
For more information on this admin command, see the admin (CAS) reference page.
See also Stopping and Starting the CMS with the admin Command on page 8-4 Stopping and Starting the CAS with the admin Command on page 8-6
Stopping and Starting the CMS with the admin Command

NOTE: You must have system admin user privileges on the host where the CMS is installed to use its admin command. You may need to stop the CMS, for example, after disabling page generation and before performing database maintenance. You can stop and start all processes for a CMS using the admin command. See Locating admin Commands on page 8-3.
8-4
03/01/99
Using this command ensures that the CMS processes are stopped and started in the proper order. Each CMS contains the admin executable to stop and start its own processes:
Name dispatch manager Process Name bob Function Dispatches all CMS transactions Tracks timed events for the dispatch manager Manages requests for the dispatch manager Windows NT Service Name Vignette Production Dispatch Service Vignette Timed Event Service
timed-event process ted
request handler
vhs
Vignette Production Request Service
NOTE: When you stop the CMS process, specifically the dispatch manager, any content reaching the launch state in the Production Center will not launch. When the CMS processes are restarted, the launch operations are completed. TIP: Do not stop the CMS services if you want an imminent launch to proceed on time. To stop or start the CMS process properly, use the CMSs own admin stop and admin start commands. NOTE: For Windows NT, you can also use the Start menu option to stop or start the CMS services. See Stopping and Starting with the Start Menu OptionsWindows NT only on page 8-8.
I To stop or start a set of CMS Services using the admin command: 1 2
Log in as system admin user on the host where the CMS is installed. From a command line, navigate to the directory where the admin command for this CMS is located. See Locating admin Commands on page 8-3. Enter the following command at the prompt:
admin stop
or
admin start
03/01/99
8-5
Command-line messages provide status on each CMS service. For stop: If the StoryServer launch bar is running, a Warning opens indicating that the StoryServer CMS is not responding. Click OK to continue. The StoryServer launch bar Connected to field changes to red and displays Not connected. Otherwise, the prompt returns when the operation is complete. If you have started the CMS processes, you can now restart StoryServer, if it is not already running, and connect to the CMS, if desired. Log in to the CMS from the StoryServer Login window. NOTE: If you change the pm.cfg file, any remotely installed CASs will need the new information. See Updating a Remotely Installed CAS Windows NT only on page 8-9, or Updating a Remotely Installed CAS Solaris only on page 8-11.
4
If you disabled page generation before stopping and restarting the CMS processes, see Enabling StoryServer Page Generation on page 8-15.
See also Stopping and Starting the CAS with the admin Command on page 8-6
Stopping and Starting the CAS with the admin Command

NOTE: You must have system admin user privileges on the host where the CAS is installed to use its admin command. You can stop and start all services for a CAS using the admin command. See Locating admin Commands on page 8-3.
8-6
03/01/99
Each CAS contains the admin executable to stop and start its own processes:.
Name Cache Manager Page Generator Placement Manager Template Manager Process Name cm ctld pad tmd Function Maintains cached content Interprets templates, accesses content, generates web pages Manages deployment of static content to the CAS docroots Manages templates, updates Page Generator regarding new or modified templates. Windows NT Service Name Vignette Cache Manager Vignette Page Generator Vignette Placement Agent Vignette Template Manager
On Windows NT, you can also use the Start menu options to stop and start the CAS services. See Stopping and Starting with the Start Menu Options Windows NT only on page 8-8.
I To stop or start a set of CAS processes: 1 2
Log in as system admin user on the host where the CAS is installed. From a command line, navigate to the directory where the admin command for this CAS is located. See Locating admin Commands on page 8-3. At the prompt, enter either:
admin stop
or
admin start
For stop: Command-line messages provide status on each CAS process as it is stopped and returns when the operation is complete. For start: The command first checks all CAS processes and stops any that are running so the services can be started in the proper order. The command echoes the progress of the operation to the command line. After stopping the processes, the command starts them again, echoes the start attempts and status to the command line, and returns the prompt when the operation completes.
See also Stopping and Starting the CMS with the admin Command on page 8-4
03/01/99
8-7
Stopping and Starting with the Start Menu Options Windows NT only
Audience: Topics include: Administrators of StoryServer 4.2 on Windows NT
Stopping and Starting a CMS from the Start Menu Stopping and Starting a CAS from the Start Menu
You can stop and start CMS and CAS processes by using the Start menu options. These menu options execute the Servers admin.bat program and handle the processes in the correct order and are easier to execute than the command-line options.
See also Stopping and Starting the CMS with the admin Command on page 8-4 Stopping and Starting the CAS with the admin Command on page 8-6
Stopping and Starting a CMS from the Start Menu

From the host that is running the CMS process, you can use the Start menu options to stop or start all processes on the CMS. The CMShost-port and CAShost-port must be fully qualified, for example:
arty.myco.com-30210 I To stop or start a CMS from the Start Menu: 1
Open the Start menu and select the following options:

Programs - StoryServer n - CMShost-port
2 3
Select Start CMS or Stop CMS, depending on the action you want. You can verify in the Services Control Panel (Start - Settings Control Panel - Services) that the arty.myco.com-30210 services have stopped. The service name shows a blank status field when the service is stopped. For service names, see the table in Stopping and Starting the CMS with the admin Command on page 8-4.
8-8
03/01/99
Stopping and Starting a CAS from the Start Menu

From the host that is running the CAS process, you can use Start menu options to stop or start all processes on the selected CAS, including the Observation Manager, if installed. The CMShost-port and CAShost-port must be fully qualified, for example:
arty.myco.com-30210 arty.myco.com-80 I To stop or start a CAS using the Start menu: 1
Open the Start menu and select the following options:

Programs - StoryServer n - CMShost-port - CAShost-port
2 3
From the next menu, select Stop CAS or Start CAS, depending on the action you want. You can verify in the Services Control Panel (Start - Settings Control Panel - Services) that the arty.myco.com-80 service has stopped. The service name shows a blank status field when the service is stopped. For service names, see the table in Stopping and Starting the CAS with the admin Command on page 8-6.
See also Updating a Remotely Installed CASWindows NT only on page 8-9 Updating a Remotely Installed CASSolaris only on page 8-11
Updating a Remotely Installed CASWindows NT only

Audience: Administrators of StoryServer 4.2 on Windows NT
When you make changes to a CMSs configuration file (\install-path\StoryServer n\Engines\Rn\conf-n\Production\pm.cfg), the new information is available to any CASs (and their services) that access that CMS and are installed on the same host as the CMS. If a CAS is installed on a different host than the CMS, you must update the CAS(s) yourself. On Windows NT, to make the new information available to the services of remotely installed CASs (that is, CASs installed on other hosts but accessing this same CMS), you must run the remote CASs StoryServer Platform
03/01/99
8-9
Configuration Program on each remote host. This program determines that the CMS is running on another machine and makes a copy of its pm.cfg file for the remote CAS. If more than one CAS accessing the same CMS are installed on a remote host, the new \conf\Production\pm.cfg file will serve for all the CASs installed on that host and accessing the same CMS. You must have system admin user privileges on the CASs host to use the StoryServer Platform Configuration Program.
I To update a remotely installed CAS on Windows NT: 1 2
Log in as system admin user on the host where the remote CAS is installed. Open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration Program Windows NT only on page 9-6. In the Welcome window, click Next to continue. A Choose Option window replaces the Welcome message. From the list, select the Configure an existing Content Management Server option. Click Next to continue. From the list, select the CMS with which the CAS you want to update is configured. Click Next to continue. From the list, select the Update or remove the Content Management Server option. Click Next to continue. From the list, select the Update Content Management Server option. Click Next to continue. The program determines that the CMS is not local and makes a copy of the remote CMSs pm.cfg file in this StoryServer installations \install-path\StoryServer n\Engines\Rn\conf-n\Production\ directory. The program returns to the main menu when the operation is complete.
3 4 5 6 7
Select the Exit Setup option. Click Next to end the session.
See also Managing Page Generation on page 8-13
8-10
03/01/99
Updating a Remotely Installed CASSolaris only

Audience: Administrators of StoryServer 4.2 on Solaris
When you make changes to a CMSs configuration file (/install-path/StoryServer/Rn/conf/Production/pm.cfg), the new information is available to any CASs (and their processes) that access that CMS and are installed on the same host as the CMS. However, to make the new information available to remotely installed CASs (that is, CASs installed on other hosts but accessing this same CMS), you must run the following command on each remote CAS:
/install-path/StoryServer/Rn/conf/host-port-number/admin update_pmcfg
For information on the command location, see admin (CAS) reference page. You must have system admin user privileges on the CASs host to use the admin update_pmcfg command.
1 2
Log in as system admin user to the host where the remote CAS is installed. Enter the command:
/install-path/StoryServer/Rn/conf /host-port-number/admin update_pmcfg
The command contacts the CMS and transfers the information from the CMSs pm.cfg to the remote CASs copy of the pm.cfg. The command-line prompt returns when the operation is complete. If more than one CAS accessing the same CMS are installed on a remote host, you can run admin update_pmcfg from just one CAS. The new /conf/Production/pm.cfg file will serve for all the CASs installed on that host and accessing the same CMS. For information on this admin command, see the admin (CAS) reference page.
See also Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12
03/01/99
8-11
Notifying the CMS of changes to StoryServer.cfg Solaris only

NOTE: For Windows NT, when you edit the StoryServer.cfg file using the StoryServer Platform Configuration Program, the program gives you the option of propagating the changes to the CMS. For more information on editing the file, see Editing the StoryServer.cfg File on Windows NT on page 11-3. When you make changes to a CASs StoryServer.cfg file, you must update the CMS with the changes. Run the following command on the CAS to transfer the information: /install-path/StoryServer/Rn/conf/host-port-number/admin up datepe For information on the command location, see admin (CAS) reference page. You must have system admin user privileges on the CASs host to use the admin updatepe command.
I To notify the CMS of changes to StoryServer.cfg: 1 2
Log in as system admin user to the host where the remote CAS is installed. Enter the command:
/install-path/StoryServer/Rn/conf /host-port-number/admin updatepe
The command contacts the CMS and transfers the information from the remote CASs StoryServer.cfg. The command-line prompt returns when the operation is complete.
See also Verifying CAS ProcessesSolaris only on page 8-13
8-12
03/01/99
Verifying CAS ProcessesSolaris only

You can check the current version of the CAS processes on Solaris against the installed version. The operation uses the pkgchk(1M) command to match the files. TIP: The verification process lists deliberately modified files as well as those that may have been accidentally changed. Keep track of the files that you know have been changed since the CAS was installed so that you can eliminate them from the list of modified files or check them manually.
I To verify the CAS processes: 1 2
Log in to the host where the StoryServer CAS is running that you want to verify. Enter the command:
/install-path/StoryServer/Rn/conf /host-port-number/admin verify
(For information on the command location, see admin (CMS) on page A-5.) The command takes a few minutes to check the currently running processes, match the files, and respond whether any have been modified.
See also Managing Page Generation on page 8-13
Managing Page Generation

Disabling StoryServer Page Generation Enabling StoryServer Page Generation
You may occasionally want to disable access by StoryServer to the database during database maintenance. When the database is accepting StoryServer connections, pages are generated normally and cached when possible. When you disable access, StoryServer continues to deliver web pages that are already cached to the user.
03/01/99
8-13
If a user requests a page that is not cached, StoryServer promptly returns an error message to the user. In contrast, if your database is not working due to maintenance and you do not disable access to the database for StoryServer, the user has to wait much longer for error messages related to non-cached pages.
I To disable StoryServer page generation and enable it when the database is ready to accept connection follow these steps: 1 2
Disable StoryServer page generation. See directly below. Stop the CMS. See Stopping and Starting the CMS with the admin Command on page 8-4 or, for Windows NT users, Stopping and Starting a CMS from the Start Menu on page 8-8. Perform database maintenance, as needed. Start the CMS. See Stopping and Starting the CMS with the admin Command on page 8-4 or, for Windows NT users, Stopping and Starting a CMS from the Start Menu on page 8-8. Enable StoryServer Page Generation. See below.
3 4
Disabling StoryServer Page Generation

You can use the Configuration View to disable page generation on all CASs connected to a single CMS.
1
In the StoryServer launch bar, ensure that the CMS is connected to the database by checking its status, as explained in Viewing CMS Information on page 4-2. In the Configuration View primary window, right-click the CMS entry, and select Disable Page Generation from the pop-up menu. A prompt asks you to verify that you want to disable page generation. Click OK to continue. A stopwatch cursor appears while the operation proceeds. NOTE: If the CMS is unable to communicate with one of the CASs, a warning displays. Click OK to continue. For information on starting the CAS services, see Stopping and Starting the CAS with the admin Command on page 8-6. A Notice opens to show which CAS Page Generators have been disabled.
8-14
03/01/99
4 5
Click OK to continue. When the cursor returns to normal, the operation is complete. To continue disabling access to the StoryServer database, you must stop the CMS. See Stopping and Starting the CMS with the admin Command on page 8-4 or, for Windows NT users, Stopping and Starting a CMS from the Start Menu on page 8-8. Perform the database maintenance. Start the CMS. See Stopping and Starting the CMS with the admin Command on page 8-4 or, for Windows NT users, Stopping and Starting a CMS from the Start Menu on page 8-8. Continue to Enabling StoryServer Page Generation on page 8-15.
6 7
Enabling StoryServer Page Generation

You can use the Configuration View to enable page generation on all CASs connected to a single CMS.
1 2
After the CMS services are restarted, start a StoryServer session if one is not already running and log in to the CMS. In the Configuration View primary window, right-click the CMS entry, and select Enable Page Generation from the pop-up window that appears. A prompt asks you to verify that you want to enable page generation. Click OK to continue. A stopwatch cursor appears while the operation proceeds. NOTE: If the CMS is unable to communicate with one of the CASs, a warning displays. Click OK to continue. For information on starting the CAS services, see Stopping and Starting with the Start Menu Options Windows NT only on page 8-8. A Notice opens to show which CAS Page Generators have been enabled.
Click OK to continue. When the cursor returns to normal, the operation is complete.
See also Managing StoryServer on Windows NT and Solaris on page 9-1
03/01/99
8-15
8-16
03/01/99
9
Summary: Audience: Note:
Managing StoryServer on Windows NT and Solaris
Procedures for various management tasks. Administrators of StoryServer 4.2 Basic Concepts on page 1-1
Establishing Service Dependencies for CMS/CASWindows NT only Setting Up StoryServer-wide Variables and Procedures Accessing the Platform Configuration ProgramWindows NT only Adding a CAS and Copying Static Files Removing an Observation Manager Removing a CAS Managing the Demonstration Project
For information on removing server software, see Platform Installation & Configuration Guide (printed copy shipped with product).
03/01/99
9-1
Establishing Service Dependencies for CMS/CAS Windows NT only

If you install the CMS or CAS on the same Windows NT host as the database, certain services cannot start correctly unless the database service is already running. The following services are dependent on the database server:
The CMS Dispatch Service (bob) The CAS Template Manager (tmd) The CAS Observation Manager (pznd)
You must ensure that the Vignette Production Dispatch Service (bob), Template Manager (tmd), and Observation Manager (pznd) all start after the database service when the system starts. Otherwise, the CMS or CAS will attempt to start and fail because it cant find the database service. You set the dependencies for the start sequence by entering commands at a Windows NT Command Prompt window. NOTE: The Observation Manager (pznd) is an optional service, and so it may or may not be running on your system. NOTE: If the database and the CMS run on different hosts, and if the database and the CAS run on different hosts, this procedure is not necessary. The following table shows the database service variables you use with the following procedures.
Database Type Microsoft SQL Server Oracle Sybase Variable MSSQLServer OracleServiceINSTANCENAME SYBSQL_SERVER Example MSSQLServer OracleServiceORCL SYBSQL_SNOWWHITE
NOTE: The CMS and CAS can be running when you run this service update. Because setting dependencies is required only for StoryServer services running on the same host as the database server, your system architecture whether the CMS, the CAS, and the database are installed on the same or different hostsdetermines which dependencies you have to set.
9-2
03/01/99
If the following are on the same host... Database server, CMS, and CAS Database server and CMS Database server and CAS
Set dependencies for... bob, tmd, pznd bob tmd, pznd
NOTE: If you set service dependencies for a previous version of the CMS or CAS, you must reset the dependencies with the new StoryServer version number (4.2).
I To adjust the CMS or CAS start sequence in relation to the specified database service: 1 2
Determine which dependencies you need to set on the host. Make certain that you have the exact names of the services, including version numbers. If you do not have this information on hand, you can find it in the registry. Navigate to:
HKEY_LOCAL_MACHINE - SYSTEM - CurrentControlSet - Services
Use extra caution while navigating in the registry.

3 4
Open a Command Prompt window and navigate to the drive where the StoryServer software is installed. Navigate to the winnt directory where the services reside. For example, if you installed the CMS in the default location:
cd c:\Program Files\Vignette\StoryServer 4\Engines \R4.2\bin\winnt
At the prompt, enter a command for each dependency you have to set on the host, following the formats and examples below. The command prompt returns when the command completes. Be sure to update the version numbers to 4.2. NOTE: When setting any service dependency, you must spell the service names for the -name and -depends arguments exactly as they are registered. For example, if the Dispatch Server is registered as bob 4.2 30210with one space on each side of 4.2 then the command will fail if you put two spaces on either side.
03/01/99
9-3
Use one of the following formats:

On a CMS host to set the Dispatch Service (bob) dependency on the
database server:
executable -update -name "service" -depends dbvariable
Examples for the different databases, assuming the dispatch service (bob) uses port 30210:
bob -update -name "bob 4.2 30210" -depends MSSQLServer bob -update -name "bob 4.2 30210" -depends OracleServiceORCL bob -update -name "bob 4.2 30210" -depends SYBSQL_SNOW_WHITE
On a CAS to set the Template Manager (tmd) or Observation Manager
(pznd) dependency on the database server:

executable -update -name "service" -depends dbvariable
Examples:
bob -update -name "tmd 4.2 retama.atlas.com-100" -depends MSSQLServer bob -update -name "pznd 4.2 azure.puma.com-80" -depends SYBSQL_SOCRATES
In the formats above:

executable Any one of the StoryServer services (for example, bob). Each StoryServer service accepts an option to set dependencies for any of the other StoryServer services. For example, you can start the command with "bob" or "tmd" to set any of the StoryServer service dependencies on either a CMS or a CAS. The full identifier of the service; one of the following:
service

n bobport hostname-webserverport
bob n bobport tmd n hostname-webserverport pznd n hostname-webserverport
The StoryServer version number. For example, 4.2. The port of the Dispatch Service. The fully qualified name of the host on which tmd or pznd is running (for example, hermit.galaxy.com), followed by a hyphen, followed by the port of the CASs web server. See the table earlier in this section.
dbvariable
9-4
03/01/99
Setting Up StoryServer-wide Variables and Procedures

In the delivery.tcl file, you can define StoryServer-wide variables and procedures to identify information used by all the Page Generator processes in a single set of installed StoryServer files. Once you define the procedures in the delivery.tcl file, they are available to all templates managed by the Content Application Servers (CASs) configured on that host. If you want CASs installed on other hosts to have the same procedures, you must copy the delivery.tcl file into the following directory on the remote hosts: NT \install-path\StoryServer n\Engines\Rn\conf-n S UN /install-path/StoryServer/Rn/conf NOTE: After you modify the delivery.tcl file, your changes will take effect:
The next time that delivery.tcl evaluated. Note that
delivery.tcl is evaluated every time that the Page Generator Process (ctld) is called, and ctld is called every time a non-cached or dynamic page is viewed via the web.
If you manually reset ctld processes on all StoryServer web servers
within the above directory location. For more information, see Resetting CAS Processes on page 8-2. In the following example, the myDino variable defines the information for all CASs installed on the same host with this CMS to use. In the example, Brontosaurus dog is the information to be used.
I To set up StoryServer-wide variables and procedures: 1
From a command line, open the delivery.tcl file using your preferred editor. For example:
notepad delivery.tcl
Enter a variable of the format: set variable string For example:

set myDino "Brontosaurus dog"
Save your changes to the file and exit the editor.
03/01/99
9-5
The next time that ctld (Page Generator) is called, the ctld processes will generate the string Brontosaurus dog for a template that includes [SHOW myDino]. Note that ctld is called every time a template is viewed via the web. You can also force the Page Generator to read delivery.tcl by resetting the Page Generator process. See Resetting CAS Processes on page 8-2.
Accessing the Platform Configuration Program Windows NT only

StoryServer bases its Platform Configuration Program on InstallShield, which provides familiar types of option lists to guide you through various configuration and management tasks. You must have system admin user privileges on the CMS or CAS host to use the StoryServer Platform Configuration Program.
You can access the StoryServer Platform Configuration Program in several ways:
From the Start Menu From the Desktop From the Command Line
From the Start Menu

On host machines running a CAS or CMS, the Start menu includes the StoryServer Platform Configuration Program option.
1 2
Log in as system admin user on the host where the Platform is installed. Open the Start menu and point to Programs, then StoryServer n. Select the StoryServer Platform Configuration Program option. The StoryServer Platform Configuration Program opens in full-screen mode. A Welcome window explains the program.
Click Next to continue to a list of options.
9-6
03/01/99
From the Desktop

On host machines running a CAS or CMS, the desktop lets you select a series of icons to start the program.
1 2 3 4 5
Double-click the My Computer icon. The My Computer window opens. Double-click the Control Panel icon. The Control Panel window opens. Double-click the Add/Remove Programs icon. The Add/Remove Programs Properties window opens. Select the StoryServer n StoryServer Platform Configuration Program entry. Click the Add/Remove button. The StoryServer Platform Configuration Program opens in full-screen mode. A Welcome window explains the program.
From the Command Line

On host machines running a CAS or CMS, you can start the configuration program by running setup.exe from a command prompt.
1 2
Open a Command Prompt window and navigate to the drive where the CMS software is installed, if necessary. Navigate to the installation directory. For example, if you installed the CMS in the default location:
cd Program Files\Vignette\StoryServer n\Engines \Rn\adm\config\
Enter the following command at the prompt:

setup
The StoryServer Platform Configuration Program opens in full-screen mode. A Welcome window explains the program.
4
03/01/99
9-7
Adding a CAS and Copying Static Files

Topics include:
Adding a CAS and Copying Static Files on Windows NT Adding a CAS and Copying Static Files on Solaris
Before you can add a CAS, you must have installed the server software and created a CMS or connected to an existing CMS as explained in Platform Installation & Configuration Guide (printed copy shipped with product). You must also have installed a web server. The CASs you add can reside on hosts other than the StoryServer database or the CMS, as long as the hosts can communicate with each other directly through the network and are not separated by a firewall. Separating StoryServers various components onto different hosts may improve performance by limiting the processing load on any one host. If you want to use the Business Center tool set, you must configure an Observation Manager for the CAS, either when you add the CAS or later. Or you can associate the CAS with an existing Observation Manager in another CAS. For information on setting up the Observation Manager and installing and configuring Net Perceptions, Inc.s GroupLens Express, see Platform Installation & Configuration Guide (printed copy shipped with product). For information on using the Observation Manager, see the Business Center and Open Profile Services Guide. For information on managing GroupLens Express, see Appendix D, Managing GroupLens Express.
Adding a CAS and Copying Static Files on Windows NT

You must have system admin user privileges on the CASs host to use the StoryServer Platform Configuration Program.
I To add a CAS and copy static files on Windows NT: 1
Log in as system admin user on the host where the CAS is installed and open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration ProgramWindows NT only on page 9-6. In the Welcome window, click Next to continue. A Choose Option window replaces the Welcome message.
9-8
03/01/99
3 4 5 6
Select the Configure an existing Content Management Server (CMS) option. Click Next to continue. From the list, select the CMS to configure. Select the Configure, update or remove a Content Application Server option. Click Next to continue. Select the Configure a new Content Application Server option. Click Next to continue. Select a CAS type:
Development - accessible only to site developers and authors Live - accessible to external users
Click Next to continue.

7
Select a web server type, and click Next to continue. NOTE: The web server must be installed and configured before you can configure a CAS for it. The program searches for available ports for the CAS services.
Choose CAS ports. The program offers four port numbers, which you can use or replace with other, unused port numbers. Click Next to continue. Read carefully the confirmation window settings you have established. Click Next to continue. The program displays progressive messages as it creates configuration files; installs services, the web server module, and demo projects; resets template managers; and installs image files. The program returns to the main menu when the configuration is complete.
10
You will now want to copy the static files from an existing CAS. When you add a new CAS to an existing StoryServer system, the web server docroot of the new CAS needs to have copies of all the static files (that is, files that dont reside in the database) already known to the existing CASs web servers of the same type (development or live). Use your preferred method (for example, xcopy command or the File Manager graphical user interface) to copy the directory tree of static files from the
\install-path\StoryServer n\Engines\Rn\ conf-n\Production\VhsProtoDocRoot
03/01/99
9-9
directory to the docroot of the web server configured with the new CAS. You can find the location of the web servers docroot in the
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\StoryServer.cfg files DOCROOT
variable, where host-port-number is the new CASs web server. For example, if you use the xcopy command to copy the directory tree, you would enter the following command (shown on multiple lines, but entered as one line at the command prompt):
xcopy "C:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\VhsProtoDocRoot" "C:\inetpub \wwwroot" /s /i
NOTE: If the new CAS is a live CAS, copy files from the docroot of an existing live CASs web server instead of the Production\VhsProtoDocRoot directory to avoid exposing inprogress files on a live site. TIP: If you have added static files other than through the Production Center, StoryServer does not know about them. You should copy these files and do so according to the type of the new CAS. For example, copy files from the docroot of an existing development CASs web server to the docroot of a new development CASs web server.
Adding a CAS and Copying Static Files on Solaris

You use the /install-path/StoryServer/Rn/adm/config script to add CASs to the StoryServer platform. For more information on creating a CAS, see the chapter on configuring a CMS and CASs in Platform Installation & Configuration Guide (printed copy shipped with product). When you add a new CAS to an existing StoryServer system, the web server docroot of the new CAS needs to have copies of all the static files (that is, files that dont reside in the database) already known to the existing CASs web servers of the same type (development or live). Use your preferred method (for example, tar(1) or cpio(1)) to copy the directory tree of static files from the
/install-path/StoryServer/Rn/conf/Production/VhsProtoDocRoot
directory to the docroot of the web server configured with the new CAS. You can find the location of the web servers docroot in the
/install-path/StoryServer/Rn/conf/host-port-number/StoryServer.cfg
9-10
03/01/99
files DOCROOT variable, where host-port-number is the new CASs web server. For example, if you use the tar command to copy the directory tree, you would enter the following commands:
# cd /install-path/StoryServer/Rn/conf/Production/VhsProtoDocRoot # tar cf - . | (cd /new-AppServer-docroot-path; tar xfBp -)
NOTE: If the new CAS is a live CAS, copy files from the docroot of an existing live CASs web server instead of the Production/VhsProtoDocRoot directory to avoid exposing inprogress files on a live site. TIP: If you have added static files other than through the Production Center, StoryServer does not know about them. You should copy these files and do so according to the type of the new CAS. For example, copy files from the docroot of an existing development CASs web server to the docroot of a new development CASs web server.
Removing an Observation Manager

Topics include:
Removing an Observation Manager on Windows NT Removing an Observation Manager on Solaris
The Observation Manager is a process on a CAS which gathers website visitor information for the Business Center. You can set up an Observation Manager when you first configure a CAS or you can do it later. The Observation Managers CAS may or may not be associated with a GroupLens Express (GLE) Engine, depending on how your CAS is configured. If the association exists, you must use the StoryServer Platform Configuration program (for Windows NT) or the config command (for Solaris) to remove the CASs association before you can remove the Observation Manager. For information on setting up the Observation Manager and installing and configuring GLE, see Platform Installation & Configuration Guide (printed copy shipped with product). For information on using the Observation Manager, see the Business Center and Open Profile Services Guide. For information on managing GroupLens, see Appendix D, Managing GroupLens Express.
03/01/99
9-11
One Observation Manager can be used by several CASs and all the information gathered from the CASs will be stored in a single website visitor database. NOTE: You can remove the Observation Manager only if its CAS is the only CAS in the StoryServer system that uses the Business Center.
Removing an Observation Manager on Windows NT

I To remove an Observation Manager from a CAS on Windows NT: 1
Log in as system admin user on the host where the CAS is installed and open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration ProgramWindows NT only on page 9-6. Proceed through the initial windows and, when available, select the Configure an existing Content Management Server option. Click Next to continue. From the list, select the CMS to configure. Select the Configure, update or remove a Content Application Server option. Click Next to continue. Select the Setup/Remove an Observation Manager option. Click Next to continue. Select the Remove an Observation Manager with a CAS option. Click Next to continue. From the list, select the CAS from which to remove the Observation Manager. Click Next to continue. The program displays progressive messages as it removes the service. When the program completes, it returns you to the CAS operation choice window. You can now remove the CAS or exit the StoryServer Platform Configuration Program. For more information, see Removing a CAS on page 9-13.
3 4 5
Removing an Observation Manager on Solaris

I To remove an Observation Manager from a CAS on Solaris: 1
Log in as system admin user on the host where the CAS you want to remove is installed.
9-12
03/01/99
Enter the following command:

/install-path/StoryServer/Rn/adm/config
(For information on file location variables, see Common Path Name Variables on page 1-5.) The interactive script begins and displays the Content Application Server Configuration Menu.
3 4
Select the number for the Personalize option. Select the number for the Remove option. A list of CASs with Observation Managers set up for this StoryServer system appears. For example:
Existing StoryServer personalization configurations include: 1 wallace-8040-1 2 wallace-8080-1 Choose the StoryServer Observation Manager to remove [?, ??, q]: 5
Enter the number of the Observation Manager you want to remove. The script identifies your selection and asks if you want to continue. Enter y to continue. The command removes the Observation Manager, stops the web server, stops the CAS, then restarts the web server and the CAS and shows the CAS processes status. The script then returns to the main menu.
6 7
Removing a CAS
Topics include:
Removing a CAS on Windows NT Removing a CAS on Solaris
Before you can remove... A CMS A CAS
You must remove... All StoryServer CASs from a particular StoryServer system. The Observation Manager, if it has been configured. See Removing an Observation Manager on page 9-11.
03/01/99
9-13
You use the StoryServer Platform Configuration Program (on Windows NT) or the config command (on Solaris) to remove a CAS from a StoryServer system. Removing a CAS differs from removing the StoryServer software installation(s). For information on removing the installed StoryServer software, see the Platform Installation & Configuration Guide (printed copy shipped with product). You must have system admin user privileges on the CASs host to remove a CAS.
Removing a CAS on Windows NT

I To remove a CAS on Windows NT: 1
As system admin user on the host where the CAS is installed, open the StoryServer Platform Configuration Program using your preferred method if not already open. See Accessing the Platform Configuration Program Windows NT only on page 9-6. Proceed through the initial windows and, when available, select the Configure an existing Content Management Server and click Next to continue. From the list, select the CMS to configure and click Next to continue. Select the Configure, update or remove a Content Application Server option. Click Next to continue. Select the Remove a Content Application Server option. Click Next to continue. From the list, select one or more CASs to remove. Only CASs configured on the local host are displayed. (You can click the Select All button to select all CASs in the list.) Click Next to continue. Verify your choice(s) in the confirmation message. The program displays progressive messages as it uninstalls services and the web server module and updates information in the delivery.tcl file to remove the CAS(s). When the program completes, it returns you to the CAS operation choice window. You can now exit the StoryServer Platform Configuration Program.
3 4
9-14
03/01/99
Removing a CAS on Solaris

I To remove a CAS on Solaris: 1 2
Log in as system admin user on the host where the CAS you want to remove is installed. Enter the following command:
(For information on file location variables, see Common Path Name Variables on page 1-5.) The interactive script begins and displays the Content Application Server Configuration Menu.
3 4
Select the number for the Remove option. The script responds with an explanation of the removal steps and asks if you want to continue. Enter y to continue. A list of CASs set up for this StoryServer system appears. For example:
StoryServer CASs include: 1 wallace-8040-1 2 wallace-8080-1 Choose the StoryServer CAS to remove [?, ??, q]:
5 6 7
Enter the number of the CAS you want to remove. (If only one CAS exists, the script identifies it and asks if you want to continue.) To confirm the removal, enter y. The command removes the CAS and asks if you want to remove another CAS. Enter y to continue or n to return to the main menu.
Managing the Demonstration Project

Topics include:
Deleting the Vignette Demonstration Project on Windows NT Restoring the Vignette Demonstration Project on Windows NT Deleting the Vignette Demonstration Project on Solaris Restoring the Vignette Demonstration Project on Solaris
03/01/99
9-15
When you configure a StoryServer development CAS on Windows NT or Solaris, you can add a set of templates and content that make up the demonstration project to the database, the Music a la Mode web site. To save space, you can also remove this project, including its static files from the development CASs. If either of the following situations occurs, you may want to restore the Vignette demonstration project to the StoryServer database:
You modified the demonstration project templates or content in some way
and want to restore them to their original state. If this is the case, you must first delete the project, then restore it.
You previously removed the demonstration project from the database using
the config script and want to restore it.
Deleting the Vignette Demonstration Project on Windows NT

To remove the demonstration project on Windows NT, you use the StoryServer Platform Configuration Program. The program removes the demonstration project content from the CASs you select from those installed on the same host. It also removes demo-related templates and static files from the CMS. If you have a CAS installed on a different host than the CMS, you must run the StoryServer Platform Configuration Program on the host where the remote CAS is installed. The program removes the projects static files and updates the Template Manager for the CAS on that host. NOTE: You must have system admin user privileges on the CMSs host or on a remote CASs host to run the StoryServer Platform Configuration Program.
I To delete the Vignette Demonstration Project on Windows NT: 1
Log in as system admin user on the host where the CAS is installed and open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration ProgramWindows NT only on page 9-6. In the Welcome window, click Next to continue. A Choose Option window replaces the Welcome message. From the list, select the Install or remove a project package option. Click Next to continue.
2 3
9-16
03/01/99
4 5
Select the Remove a project package option. Click Next to continue. Select one or more projects to remove. (If you have only the Vignette demonstration project, MusicAlaMode, it is automatically selected.) Click Next to continue. The program displays progressive messages as it removes the project package, package information, and static files and resets the template managers to read the project changes. The program returns to the main menu when the removal is complete.
Restoring the Vignette Demonstration Project on Windows NT

To restore the demonstration project on Windows NT, you use the StoryServer Platform Configuration Program and select the CAS to which you want to restore the project. If you have a CAS installed on a different host than the CMS, you must run the StoryServer Platform Configuration Program on the host where the remote CAS is installed. The program updates the projects static files and updates the Template Manager for the CAS on that host. NOTE: You must have system admin user privileges on the CMSs host or on a remote CASs host to run the StoryServer Platform Configuration Program.
I To restore the Vignette Demonstration Project on Windows NT: 1
Log in as system admin user on the host where the CAS is installed and open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration ProgramWindows NT only on page 9-6. In the Welcome window, click Next to continue. A Choose Option window replaces the Welcome message. From the list, select the Install or remove a project package option. Click Next to continue. Select the Install a project package option. Click Next to continue. Select one or more project packages to add. (If the Vignette demonstration project, MusicAlaMode, is the only available project, it is automatically selected.)
2 3 4 5
03/01/99
9-17
Click Next to continue. The program displays progressive messages as it installs the project package (including a progress indicator), package information, and static files and resets the template managers to read the project changes. The program returns to the main menu when the configuration is complete.
6
Deleting the Vignette Demonstration Project on Solaris

To remove the demonstration projects on Solaris, you execute the /install-path/StoryServer/Rn/adm/config script and select the Delete option. The script removes the demonstration project content from all the CASs installed on the same host as the CMS theyre accessing. It also removes demo-related templates and static files from the CMS. If you have a CAS installed on a different host than the CMS, you must run /install-path/StoryServer/Rn/adm/config on the host where the remote CAS is installed. The script removes the projects static files and updates the Template Manager for the CAS on that host. NOTE: You must have system admin user privileges on the CMSs host or on a remote CASs host to run the StoryServer Platform Configuration Program.
I To delete the Vignette Demonstration Project on Solaris: 1 2
Log in to the host where the CMS is installed that serves the CAS for which you want to remove the demonstration projects. Enter the following command:
(For information on file location variables, see Common Path Name Variables on page 1-5.) The interactive script begins and displays the CAS Configuration Menu.
3 4
Enter the number for the Delete option. The script responds with a description of the delete operation and asks if you want to continue. Enter y to continue. The script echoes the operations it performs as it deletes the demonstration templates and records from the CMS, the project content from the database,
9-18
03/01/99
and the project static files from each CAS installed on this host. After notifying the Template Manager about the removed templates, the script again displays the CAS Configuration Menu.
5
Select another operation or enter q to quit.
Restoring the Vignette Demonstration Project on Solaris

To restore the demonstration project on Solaris, you execute the /install-path/StoryServer/Rn/adm/config script, select the Update option, and select the CAS to which you want to restore the project. If you have a CAS installed on a different host than the CMS, you must run the /install-path/StoryServer/Rn/adm/config script on the host where the remote CAS is installed. The script updates the projects static files and updates the Template Manager for the CAS on that host. NOTE: You must have system admin user privileges on the CMSs host or on a remote CASs host to run the StoryServer Platform Configuration Program.
I To restore the Vignette Demonstration Project on Solaris: 1 2
Log in to the host where the CMS for the CAS you want to update is installed. Enter the following command:
(For information on file location variables, see Common Path Name Variables on page 1-5.) The interactive script begins and displays the CAS Configuration Menu.
3 4
Enter the number for the Update option. The script responds with a description of the update operation and asks if you want to continue. Enter y. The script echoes the operations it performs as it updates the demonstration templates and records in the CMS and the project content in the database. The script then steps through the list of CASs using this CMS and asks you to confirm whether you want to update the CASs static files with the project files and publish the projects templates to the CAS.
Enter y if you want to update or publish.
03/01/99
9-19
After updating and publishing, the script again displays the CAS Configuration Menu.
6
Select another operation or enter q to quit.
9-20
03/01/99
10
Summary: Audience:
How to modify certain features of the web server. Administrators of StoryServer 4.2
Before you begin:
Basic Concepts on page 1-1 Monitoring StoryServer Servers and Processes on page 4-1 Mapping the Root Path (/) to a Front Door CURL Working with Web Server Parsing Clearing Pages from a Root Path Using .asp Scripts in TemplatesWindows NT only
Topics include:
03/01/99
10-1
Mapping the Root Path (/) to a Front Door CURL

Mapping the root documentation path to a particular CURL for your web sites front door on Windows NT allows your front door page to use variations (also known as browser capabilities) available through the use of CURLs. In other words, using the HTTPD_FDCURL variable, the front door of your website can take advantage of variations even though the page was not arrived at by a CURL. Whether the web server is Apache, IIS, or Netscape, the StoryServer.cfg file for the CAS associated with the web server contains a variable you can modify to the CURL you want.
I To map the root path to a front door CURL: 1
Log in as system admin user on the host where the CMS is installed and open the StoryServer.cfg file for editing. See Editing the StoryServer.cfg File on Windows NT on page 11-3. Find the commented line under WEB SERVER SETTINGS for HTTPD_FDCURL:
#set HTTPD_FDCURL "your frontdoor"
Uncomment the line and replace your frontdoor with the path to the CURL for your front door. For example, if you mapped the root path to the CURL /public/FrontDoor/0,1001,,FF.html, the line would look like this:
set HTTPD_FDCURL "/public/FrontDoor/0,1001,,FF.html"
4 5
Save your changes. See Editing the StoryServer.cfg File on Windows NT on page 11-3. To make the web server use the new values, stop and restart the web server.
Working with Web Server Parsing

Topics include:
StoryServer Changes to obj.conf File on Netscape Disabling Parsing on Netscape Optimizing parse-html on Netscape Parsing on IIS 4Windows NT only Parsing on ApacheSolaris only
10-2
03/01/99
StoryServer component templates offer a valuable way to increase your web server performance by taking advantage of StoryServers flexible caching strategy. StoryServer component templates and the personalization features provided by the Business Center require server-side parsing in order to work. (See information on component templates in the chapter on Content Delivery Templates in the Template Development Guide and COMPONENT in Template Command Reference.) However, enabling parsing on your web server does have a slight performance penalty. If your site does not use components, you may want to disable parsing as described here. NOTE: Dont disable parsing if your web site uses StoryServer component templates or if it tracks web visitor data through the StoryServer Business Center. The following sections discuss enabling, disabling, and optimizing parsing on Netscape, IIS, and Apache web servers:
StoryServer Changes to obj.conf File on Netscape

For Netscape 2.01, 3.0, and 3.5.1, StoryServer relies on the Netscape parse-html function (server-side includes) to interpret component templates properly. When setting up a Netscape web server, StoryServer enables parsing for the server. It does so partly by modifying these lines of the web servers obj.conf file to look similar to this (the arguments can be in any order):
ObjectType fn="shtml-hacktype" Service fn="parse-html" opts="noexec" method="(GET|HEAD|POST)" type="magnus-internal/parsed-html"
The two lines above instruct Netscape to parse all html files for server-side includes. The parse-html function must be called for the COMPONENT command to work. (The opts="noexec" phrase disables server-side exec calls.)
Service fn="send-file" method="(GET|HEAD|POST)" type="*~magnus-internal/*"
This above line enables content to be submitted and to have server-side parsing included at the same time.
03/01/99
10-3
NOTE: If you use the Netscape Administration Server interface to alter the web servers obj.conf file, ensure that the method="(GET|HEAD|POST)" phrase in this line includes the POST option. If it is missing, submittals (posts) wont work.
Disabling Parsing on Netscape

Topics include:
Disabling Interpretation of COMPONENT Results Disabling Server-side Includes on Netscape
NOTE: Dont disable parsing if your web site uses StoryServer component templates or if the site tracks web visitor data through the StoryServer Business Center. To disable parsing on Netscape for Windows NT or Solaris, you modify the CASs StoryServer.cfg file and the web servers obj.conf file. After both files are changed, stop and restart your web server.
Disabling Interpretation of COMPONENT Results
NOTE: For II4 web servers, see Parsing on IIS 4Windows NT only on page 10-6.
I To disable your Netscape web server so that it doesnt interpret COMPONENT command results: 1
Log in as system admin user on the host where the CMS is installed and open the StoryServer.cfg file for editing. See Editing the StoryServer.cfg File on Windows NT on page 11-3. Find the line under WEB SERVER SETTINGS for HTTPD_COMPONENTSCAN:
HTTPD_COMPONENTSCAN 1
To disable parsing, change the value to 0 (zero):

HTTPD_COMPONENTSCAN 0
4 5
Save your changes and select a commit option. See Editing the StoryServer.cfg File on Windows NT on page 11-3. Before parsing is completely disabled, you must also change the Netscape web servers obj.conf file. See Disabling Server-side Includes on Netscape on page 10-5.
10-4
03/01/99
Disabling Server-side Includes on Netscape

I To disable server-side includes (parse-html) completely, edit the Netscape web servers obj.conf file: 1 2
Log in as a user with system admin user privileges to the host where the web server and CAS are running that you want to modify. Open a command line and navigate to the directory:
NT \ws-install-path\ws-instance\config\ S UN /ws-install-path/ws-instance/config/
For example, if you installed the web server in the default location:
NT cd \Netscape\Server\https-myhost\config S UN cd /Netscape/Server/https-myhost/config 3
Using your preferred editor, open the obj.conf file for an NSAPI web server configured with StoryServer. For example:
notepad obj.conf
To disable server-side includes (parse-html) completely, remove these two lines from the web servers obj.conf file:
ObjectType fn="shtml-hacktype" Service fn="parse-html" opts="noexec" method="(GET|HEAD|POST)" type="magnus-internal/parsed-html 5
Set HTTPD_COMPONENTSCAN to 0. See Disabling Interpretation of COMPONENT Results on page 10-4. TIP: You can also use the Netscape Administration Server interface to disable and enable parsing. If you disable parse-html (either from the interface or by manually modifying the file as in Step 3) and later enable it through the interface, ensure that the method="(GET|HEAD|POST)" phrase includes the POST option. You must add the POST option manually.)
6 7 8
Save the changes to the web servers obj.conf file. From the Netscape Administration Server interface, apply the changes with the Apply and Load Configuration Files commands. To make the web server use the new values, stop and restart the web server.
03/01/99
10-5
Optimizing parse-html on Netscape

You can configure Netscape and StoryServer to execute the parse-html function on only those templates (html pages) that require it: for example, .shtml pages.
I To optimize parse-html on Netscape: 1 2
Use the Netscape Administration Server to change the Parse HTML setting to the desired type of file (files with the extension .shtml). Edit the web servers obj.conf file to add the POST option to the method on the parse-html function. The resulting line should look like this:
Service fn="parse-html" opts="noexec" method="(GET|HEAD|POST)" type="magnus-internal/parsed-html"
NOTE: If you make this change, you must also set HTTPD_COMPONENTSCAN to 0. See Disabling Interpretation of COMPONENT Results on page 10-4.
3 4 5 6
Save the changes to the web servers obj.conf file. From the Netscape Administration Server interface, apply the changes with the Apply and Load Configuration Files commands. Stop and restart your web server. Change the default extension for templates containing COMPONENT commands to .shtml so the web server will parse them.
Parsing on IIS 4Windows NT only

NOTE: To increase performance, you may want to set up parsing only for specific paths rather than for the entire site. For more information, see your IIS documentation. For IIS 4 web servers, use the Microsoft Management Console to change the properties for the web server instance.
I To control parsing with the IIS 4 web servers: 1
Log in as a user with system admin user privileges to the host where the web server and CAS that you want to modify are running.
10-6
03/01/99
Open the Microsoft Management Console (this may be referred to as Internet Service Manager in your menu), right-click on your web server instance and select Properties. With WWW Service selected, click the Edit button. Select the Home Directory tab. In the Permissions section, select the Script option field if it isnt already selected. This option allows scripts to be run on the webserver. Select Configuration. You will see a list of Application Mappings. To enable ssinc.dll for .html and .htm, add two lines to the properties that look similar to this, depending on your configuration:
.htm .html C:\WINNT\System32\inetsdrv\ssinc.dll C:\WINNT\System32\inetsdrv\ssinc.dll
3 4 5 6 7
8 9 10 11 12
Make sure that no exclusions exist for either .htm or .html file types. Click OK in the Configuration window, then Apply in the Microsoft Management Console. Repeat these steps for each web server instance on this host for which you will configure a CAS. In Windows Explorer, select the web servers docroot entry and open its Properties window. Select the Security tab and click Permissions. In the Directory Permissions window that opens, set the permissions for the context on which IIS is running. This is: IUSR_hostname (which is the user name under which server-side includes run scripts on this web servers docroot).
a b
Confirm that the user name Type of access is set to Change (which provides read, write, delete, and execute permissions). Select both the Replace Permissions on Subdirectories and Replace Permissions on Existing Files option fields, if theyre not already selected.
13 14
Click OK in the Directory Permissions window and OK in the Properties window. Stop and restart your web server. NOTE: The IIS web server also supports server-side-include parsing for HTTP GETs. If you still want to be able to scan particular pages, create
03/01/99
10-7
templates using the SSI suffix (by default .stm). If your template uses the SSI suffix, the generated page will be scanned for components. NOTE: An ASP (Active Server Pages) template is required for an asp component to work. ASP templates must have the .asp extension.
Parsing on ApacheSolaris only

You can add a handler to the native Apache configuration file (for example, the web servers httpd.conf file) to enable parsing and to specify what kind of files should be parsed. The setting preferably should be added at the end of the configuration file. For example:
AddHandler server-parsed .html
NOTE: See your Apache documentation for the name and location of the configuration file and the preferred location in the file for specifying additional server settings. For more information on configuring a native Apache web server with StoryServer, see Platform Installation & Configuration Guide (printed copy shipped with product).
Clearing Pages from a Root Path

After you make changes to a set of content that appears in cached pages, you can use the flushcache command to flush previously generated pages from a CASs cache. The next request then accesses the new content. NOTE: A change to a template (save or launch, for example) automatically clears the cache for that template path. The CLEAR_CACHE command in a content entry save template also flushes the specified template path from a specified cache. Use the flushcache command in the Production Center as a Program task in a workflow. For more information on setting program tasks, see Production Center Guide. NOTE: Do not use the flushcache command to clear pages after you expire a template. You must manually delete cached pages related to a template you expire. You set the action of the flushcache command (that is, whether it renames the cached pages or removes them from the cache) for each CAS in its
10-8
03/01/99
StoryServer.cfg file CMD_ACTION variable. The default is RENAME, which provides a renamed, backup file for delivery to the web site if the new page isnt generated for some reason. To have flushcache remove cached pages from the cache, change the value to DELETE. For more information on changing values in the file, see Editing the StoryServer.cfg File on Windows NT on page 11-3.
I To clear pages from a CAS document root, you set a Program task in the Production Center tools as part of a workflow: 1
In the Details for Task window (for example, in a Production Center project-level task), select the Program task, if its not already selected. The text field becomes available. In the Program task text field, type flushcache and the options you want. The format is:
flushcache host port path ... host port path Specifies the system where the web server whose document root you want to clear is running. Specifies the Cache Managers port number on the CAS associated with the web server document root. Specifies one or more directories relative to the document root containing the pages you want to clear.
For example, to clear pages from the directory

NT \OurSite\Books S UN /OurSite/Books
in the document root for the web server whose Cache Managers port is 13625 on system farley:
NT flushcache farley 13625 \OurSite\Books S UN flushcache farley 13625 /OurSite/Books
To flush multiple paths with one command:

NT flushcache farley 13625 \OurSite\Books \OurSite\Magazines S UN flushcache farley 13625 /OurSite/Books /OurSite/Magazines 3
In the Due pane, set the task to occur at any time (in effect, immediately) or specify a date and time and whether to repeat the task.
03/01/99
10-9
TIP: Flushing a cache creates a lot of system activity. To prevent performance degradation, benchmark your most resource-consuming flush and schedule repeating tasks no more often than that interval. Its also prudent to stagger flushes of different areas or caches to avoid severe competition for system resources.
4
When you have completed any other changes to the Details window, click OK. The flushcache command takes effect when you specified.
Using .asp Scripts in TemplatesWindows NT only

So that .asp scripts (Active Server Pages), server-side includes, and other StoryServer template programming features are correctly delivered to the user, make sure that the first entry in the web servers list of default file names is set to default.asp. For more complete information on setting the default file names, see Platform Installation & Configuration Guide (printed copy shipped with product). If your site will use .asp scripts in StoryServer templates, you must also change the default value of a variable in the CASs StoryServer.cfg file. NOTE: An ASP template is required for an asp component to work. ASP templates must have the .asp extension.
I To configure the StoryServer.cfg file to handle .asp scripts: 1 2
Access the CASs StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3. Find this line:
set CMD_MIMETYPE_EXT
The default value is 0.

3 4 5
Set the number to 1. Otherwise, StoryServer interprets a path ending in .asp as a directory and will not find the page. Save the changes to the StoryServer.cfg file, as explained in Step 10 of Editing the StoryServer.cfg File on Windows NT on page 11-3. Stop and start the CAS. See Stopping and Starting the CAS with the admin Command on page 8-6 or Stopping and Starting with the Start Menu OptionsWindows NT only on page 8-8.
10-10
03/01/99
03/01/99
10-11
10-12
03/01/99
11
Summary: Audience:
Variable settings that you can modify to increase performance or adjust for different content or products, and how to use the StoryServer Platform Configuration Program to edit settings in the configuration files on NT. Administrators of StoryServer 4.2 on NT
Before you begin:
Monitoring StoryServer Servers and Processes on page 4-1 Managing StoryServer Files on Windows NT or Solaris on page 6-1 Editing the Configuration Files on Windows NT Increasing Page Generator Requests on Windows NT Adjusting Page Generator Timeouts on Windows NT Adjusting Page Generator Logging on Windows NT Adjusting for Large Database Retrievals on Windows NT Increasing Request Handling on Windows NT Setting the Thread Pool Size for the Cache Manager on Windows NT Adjusting Web Server Processes on Windows NT Restricting Access to the Servers on Windows NT
Topics include:
03/01/99
11-1
Editing the Configuration Files on Windows NT

Topics include:
Editing the pm.cfg File on Windows NT Editing the StoryServer.cfg File on Windows NT
This section explains how to use the StoryServer Platform Configuration Program options to update and test your changes to the configuration files for the Content Management Server (CMS) and Content Application Servers (CASs). Other sections in this chapter discuss the various settings and changes you can make.
Editing the pm.cfg File on Windows NT

NOTE: Solaris users will edit the pm.cfg file directly through their preferred text editor. For the location of the pm.cfg file on Solaris, see pm.cfg on page B-29. The StoryServer Platform Configuration Program lets you open the pm.cfg file (either the file where the CMS is installed or where any CAS is installed on another host) using your preferred editor. When you start editing, the program saves a backup copy of the file in case you decide to abandon your changes and revert to the starting version. When you commit your changes, the program immediately stops the CMS services and restarts them with the new configuration information. You must have system admin user privileges on the CMSs host to use the StoryServer Platform Configuration Program.
I To edit the pm.cfg file: 1
Log in as system admin user to the host where the CMS is installed and open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration ProgramWindows NT only on page 9-6. Click through the initial windows. Select the Configure an existing Content Management Server (CMS) option. Click Next to continue. Select the CMS to configure. Click Next to continue.
2 3 4
11-2
03/01/99
Select the Update or remove the Content Management Server option. Click Next to continue. The Choose option window changes to your selection. Select the Update Content Management Server option. Click Next to continue. The Choose editor window opens. Use the default editor supplied (D:\WINNT\notepad.exe) or enter the fully qualified path to an editor of your choice. Click Next to continue. The CMSs pm.cfg file is opened using your selected file editor. Modify the file as needed. (See other sections in this chapter.) Save your changes and close the file. A confirmation message asks you to confirm that you want to commit the changes to the CMSs pm.cfg file. Choose one of the following options:
Yes - Your changes are committed to the pm.cfg file.
6 7
8 9 10
The program stops, then restarts the CMS services, testing the changes. The program returns you to the editor if the services fail to restart. If the services restart, the program displays an information message that the update is complete and recommends updating remote hosts. Click OK to continue. The program returns to the main menu. The Page Generator service(s) access the changes as soon as the next request is made. Services that access the StoryServer.cfg file will also get the changes because the StoryServer.cfg file references the pm.cfg file.
No - Your changes are discarded. The program returns to the update or
remove CMS option menu. NOTE: You must run this same program on each host where a CAS that accesses this CMS is installed. The program makes a copy of the updated pm.cfg file in the CASs \conf\Production directory. For more information, see Updating a Remotely Installed CAS Windows NT only on page 8-9.
Editing the StoryServer.cfg File on Windows NT

NOTE: Solaris users will edit the StoryServer.cfg file directly through their preferred text editor. For the location of the StoryServer.cfg file on Solaris, see StoryServer.cfg on page B-33.
03/01/99
11-3
The StoryServer Platform Configuration Program lets you open a CASs StoryServer.cfg file using your preferred editor, modify settings, and test your modifications before saving the new StoryServer.cfg file. When you start editing, the program saves a backup copy of the file in case you decide to abandon your changes and revert to the starting version. You must have system admin user privileges on the CASs host to use the StoryServer Platform Configuration Program.
I To edit the StoryServer.cfg file: 1
Log in as system admin user to the host where the CAS is installed and open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration ProgramWindows NT only on page 9-6. Click through the initial windows. Select the Configure an existing Content Management Server (CMS) option. Click Next to continue. Select the CMS to configure. Click Next to continue. Select the Configure, update or remove a Content Application Server option. Click Next to continue. Select the Update a Content Application Server option. Click Next to continue. A list of CASs configured on this host opens. Select the CAS whose StoryServer.cfg file you want to modify. Click Next to continue. The Choose editor window opens. Use the default editor supplied (D:\WINNT\notepad.exe) or enter the fully qualified path to an editor of your choice. Click Next to continue. The CASs StoryServer.cfg file is opened using your selected file editor. Modify the file as needed. (See other sections in this chapter.) Save your changes and close the file. A confirmation message asks you to confirm that you want to commit the changes to the CASs StoryServer.cfg file. Choose one of the following options:
Test changes [recommended] - The program ensures that all services
2 3 4 5 6 7 8
9 10
11
start correctly with your modifications by stopping and attempting to restart the CAS services using the new configuration information. If a service fails to start, the program returns you to the editor window for further changes. If the services start successfully, the program updates
11-4
03/01/99
the CASs StoryServer.cfg file, notifies the CMS of the changes, and displays an update complete message. Click OK to continue.
Continue immediately. The services will not be stopped. - The
changes are committed to the StoryServer.cfg file and notifies the CMS of the changes without testing. You will not know if there is a problem until the next time the services are stopped and restarted, although the Page Generator does access the changes on the next request. The program displays a message when the update is complete. Click OK to continue. The program returns to the main menu.
Cancel changes without saving - The program displays an update
cancelled message. Click OK to continue. The program restores the StoryServer.cfg file with which you started and returns to the Configure, Update, or Remove a CAS dialog box.
12
Stop and restart the web server.
Increasing Page Generator Requests on Windows NT

You can increase Page Generator throughput by increasing the number of requests (slave processes) the Page Generator allows. You must have system admin user privileges on the host system where the CAS is installed to modify the StoryServer.cfg file, in which the request variable is stored.
I To increase Page Generator requests: 1 2
Access the CASs StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3. In the PAGE GENERATOR SETTINGS section of the file, find this line:
set CTLD_POOL_SIZE

3
Increase the number, for example, to 10. TIP: Observe how many instances are actually logging over time and adjust the pool size number closer to the actual occurrence maximum, depending on your peak load. (On a live system, the default log level is 2, which will create a log file, but no contents will be written to the file. Change the log level as necessary.) See ctld.log on page B-6 and ctldinfo.log.id on page B-13.
03/01/99
11-5
Save the changes to the StoryServer.cfg file and restart the web server, as explained in Step 11 and 12 of Editing the StoryServer.cfg File on Windows NT on page 11-3. NOTE: If you did not select to test your changes, you should reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2.
Adjusting Page Generator Timeouts on Windows NT

Topics include:
Changes from Previous Releases Setting Page Generation Timeouts RESET_TIMEOUT Template Command
Setting a time limit for page generation prevents a template with a programming error, such as an infinite loop, from tying up a CASs Page Generator.
Changes from Previous Releases

In earlier StoryServer releases, two configuration variables acted together to determine how long a CAS's Page Generator could take to generate a page: the CTLD_EVAL_TIMEOUT set the number of seconds that the Page Generator could take to evaluate a template, and the HTTPD_TIMEOUT variable set the number of seconds that the web server would wait for a response from the Page Generator. Both variables were set in the CASs StoryServer.cfg file. You would set each variable value higher than the default if any template on your site took a long time to generate pages (for example, a complex template or a web-based content entry template that accepted very large content submissions). Page Generation timeout handling has changed to allow more flexibility. The CTLD_EVAL_TIMEOUT variable works differently, and the HTTPD_TIMEOUT variable no longer exists. A new StoryServer template command, RESET_TIMEOUT, is available to set the timeout in individual templates.
11-6
03/01/99
Setting Page Generation Timeouts

The length of time the Page Generator can take to generate a page is set in two ways:
With a new StoryServer template command, RESET_TIMEOUT.
RESET_TIMEOUT resets the timeout value for the template its in, overriding the CTLD_EVAL_TIMEOUT value.
With the CTLD_EVAL_TIMEOUT variable in the CASs
StoryServer.cfg file. CTLD_EVAL_TIMEOUT sets the default length of time that the Page Generator can take to evaluate a template and produce a page.
I To set the Page Generator timeout: 1 2
set CTLD_EVAL_TIMEOUT
The default value is 20, the number of seconds the service attempts to evaluate the template.
3 4
Increase the value to a reasonable length for most templates. Save the changes to the StoryServer.cfg file and restart the web server. NOTE: If you did not select to test your changes, you should reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2.
Now use RESET_TIMEOUT in templates that take a long time to evaluate. (You can also use it in templates that take less time than usual to evaluate.) See RESET_TIMEOUT Template Command on page 11-8. NOTE: If you worked with a previous release of StoryServer, notice the difference in how CTLD_EVAL_TIMEOUT works now. Before, you would set it high enough for the templates that took the longest time to evaluate. Now, you set it high enough for most templates, and you use RESET_TIMEOUT in templates that take longer. The length of time that the web server will wait for a response from the Page Generator is either the CTLD_EVAL_TIMEOUT value plus seven seconds or, if the template uses RESET_TIMEOUT, the new timeout value plus seven seconds.
03/01/99
11-7
RESET_TIMEOUT Template Command

The RESET_TIMEOUT command has two forms:
RESET_TIMEOUT n
where n is a number specifying seconds. n cannot be 0. This syntax resets the Page Generator timeout to n seconds, regardless of how much time remains in the current timeout period when RESET_TIMEOUT is evaluated. You can use this syntax to increase or lower the default timeout for a particular template.
RESET_TIMEOUT +n
where n is a number specifying seconds. n cannot be 0. This syntax resets the Page Generator timeout, adding n seconds to whatever time remains in the current timeout period when RESET_TIMEOUT is evaluated. For example, if n is 15 and 13 seconds remain when the Page Generator evaluates RESET_TIMEOUT, then the timeout is reset to 28 seconds. Use this syntax to increase the default timeout for a particular template. Its especially useful in library templates. For example, you know a library subroutine takes 10 seconds, but you dont know the other time requirements of the templates that may include the library template. Using [RESET_TIMEOUT +10] in the library template will add enough time for the library subroutine evaluation in whatever template includes it. The maximum value allowed for n with either form is 2147483647 (the standard Tcl limit). Some suggestions for using RESET_TIMEOUT:
Keep in mind that RESET_TIMEOUT must be evaluated before the current
timeout expires.
Place RESET_TIMEOUT near the beginning of the template. You dont have to reset the timeout back to the default: the value is changed
only in the context of the template evaluation. NOTE: Be careful when using RESET_TIMEOUT. Resetting the timeout can potentially tie up resources, since the Page Generator and web server will wait indefinitely (if RESET_TIMEOUT is set to a very high value or included in a loop that never completes, for example).
11-8
03/01/99
Adjusting Page Generator Logging on Windows NT

You can turn audit logging on and off (the default) for the Page Generator. When you are debugging a development CAS, you might want the more informative audit messages, but a live CAS probably doesnt need the additional logging and the necessarily decreased performance. Errors and warnings are still written to the EventLog service when the audit logging is turned off. You must have system admin user privileges on the host system where the CAS is installed to modify the CASs StoryServer.cfg file.
I To adjust logging: 1 2
set CTLD_LOG_LEVEL
The default value is 2, meaning auditing is disabled; only errors and warnings will be logged. To enable audit logging, change the value to 4.
3
Save the changes to the StoryServer.cfg file and restart the web server. NOTE: If you did not select to test your changes, you should reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2.
Adjusting for Large Database Retrievals on Windows NT

In the DATABASE SERVER SETTINGS section of the CMSs pm.cfg file, you can adjust for some database differences. For example, StoryServer has increased the Sybase SQL Server 11.02 limit to 128 kilobytes for a response to a single database query. If you have templates that request a 300K image from the Sybase database, you should modify the pm.cfg file TEXTSIZE variable to 300K.
03/01/99
11-9
The TEXTSIZE limit applies to database operations as follows:

Microsoft SQL Server Sybase Oracle Applies to read and write operations Applies only to read operations Does not apply
NOTE: Consult with your database administrator regarding any constraints the database has on handling large binary images. For example, if you use Sybase and are working with large alternate content files such as GIFs, your DBA may recommend that you increase the database procedure cache.
I To adjust for large database retrievals: 1 2
Access the CMSs pm.cfg file as explained in Editing the pm.cfg File on Windows NT on page 11-2. In the DATABASE SERVER SETTINGS section of the file, find this line:
set TEXTSIZE nnnnnn
The default value is 131072 (128K).

3
Increase the number to accommodate the largest image you regularly request from the database, which is the largest image the CAS(s) will have to handle. TIP: For example, for a template that pulls a 300K image, set the value accordingly: 307200 (1024x300).
4 5
Save the changes to the pm.cfg file as explained in Step 9 of Editing the pm.cfg File on Windows NT on page 11-2. If you have CASs that access this CMS but are installed on hosts other than the host for the CMS, you must update the remote CASs copy of the pm.cfg file. See Updating a Remotely Installed CASWindows NT only on page 8-9. Reset the Page Generator and Template Manager processes in each CAS that accesses this CMS to read the new configuration file values. See Resetting CAS Processes on page 8-2.
11-10
03/01/99
Increasing Request Handling on Windows NT

The request handling service allows a specified number of requests for template operations or static file (re)submissions to be made at a time. You can increase this number by modifying the VHS_POOL_SIZE variable in the CMSs pm.cfg file. If you modify the VHS_POOL_SIZE variable, you should also modify the PAD_POOL_SIZE variable in the
\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number \StoryServer.cfg
file for each CAS accessing the CMS. NOTE: Template operations and submission of static files are often timeconsuming operations. There may be some performance cost for increasing the number of requests handled for these operations.
I To increase request handling: 1 2
Access the CMSs pm.cfg file as explained in Editing the pm.cfg File on Windows NT on page 11-2. In the PRODUCTION MANAGER SETTINGS section of the file, find this line:
set VHS_POOL_SIZE

3 4 5
Increase the number, for example, to 10. Save the changes to the pm.cfg file as explained in Step 9 of Editing the pm.cfg File on Windows NT on page 11-2. If you have CASs that access this CMS but are installed on hosts other than the one for the CMS, you must update the remote CASs copy of the pm.cfg file. See Updating a Remotely Installed CASWindows NT only on page 8-9. Access the CASs StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3 to adjust the variable for the Placement Manager. In the PLACEMENT MANAGER SETTINGS section of the file, find this line:
set PAD_POOL_SIZE

8
Increase the number, for example, to 10.
03/01/99
11-11
Save the changes to the StoryServer.cfg file, as explained in Step 11 of Editing the StoryServer.cfg File on Windows NT on page 11-3.
Setting the Thread Pool Size for the Cache Manager on Windows NT
If a template is configured to cache its pages, StoryServer generates the related page the first time the template is requested and then stores the page in the disk cache under the web server document root. Subsequent requests for the page receive the cached version directly from disk. The StoryServer Cache Manager (cmd) maintains the cached pages. The Cache Manager flushes a page from the cache when one of three things occurs:
The related template is updated. The flushcache program task, in the StoryServer Production Center, flushes
the template path.

The CLEAR_CACHE template command flushes the template path.
A new variable, CMD_POOL_SIZE, determines how many threads are available to the Cache Manager for flushing the page cache. The CMD_POOL_SIZE variable is set in the Application Servers StoryServer.cfg file. Its default value is 5, and its minimum valid value is 2. You can set the value as high as you want, but typically the most useful range is between 5 and 10. The default value, 5, is reasonable in most cases. If the cache is flushed frequently at your site, then you may want to increase the CMD_POOL_SIZE value to 8 or 10. The higher number lessens the chance that incoming requests will be held up by long requests that arrived earlier. Setting the number higher than 10 or so may use resources unnecessarily. Flushes are done by directory, and only one thread can act on a single directory at one time. For example, suppose the Cache Manager receives three requests, in the order listed, to flush the following paths:
1 2 3
/news/local /news/local /news/local/images
11-12
03/01/99
Then separate threads can simultaneously service the requests to flush paths 1 and 3, but the second request to flush /news/local must wait until the first request to flush that path completes. If the Page Generator receives 10 requests to flush a single path, only one thread will run at a time, even if 10 threads are available.
I To change the default value for CMD_POOL_SIZE: 1 2 3 4
Start editing the CASs StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3. Find the CMD_POOL_SIZE variable (in the ## CACHE MANAGER SETTINGS section of the file), and change its value. Make the change take effect as explained in Step 11 of Editing the StoryServer.cfg File on Windows NT on page 11-3. Repeat the procedure for each CAS.
Adjusting Web Server Processes on Windows NT

Many web servers also let you adjust the number of processes that the web server will try to handle concurrently. You should weigh the possible advantages of increasing the number of processes against any performance disadvantage. The recommended number of processes and how you adjust them varies from web server to web server. Consult your web server vendors documentation for specific information.
Restricting Access to the Servers on Windows NT

Topics include:
Setting Allowed IP Addresses for the CMS Setting Allowed IP Addresses for a CAS
By default, StoryServer services accept connection from any source. You can limit access to the CMS and CASs by setting variables in their configuration files to accept connections only from specified IP addresses.
03/01/99
11-13
NOTE: Examine your specified IP address list carefully to ensure that you have included all the connections that you want to provide, including those of other servers in the StoryServer system. You must provide valid IP addresses in the correct format: for example, 207.9.9.8. You can specify each individual machine. You can also specify all machines in a subnet. For example, 207.8.8 would restrict access to only the machines in the 207.8.8 subnet.
Setting Allowed IP Addresses for the CMS

NOTE: The CMS must include the IP address of its own host as well as the IP addresses of all the CAS hosts that need to connect to it and any client hosts that run the StoryServer tools. Failure to include all appropriate addresses may cause StoryServer to malfunction.
I To specify allowed IP addresses for the CMS: 1 2
Access the CMSs pm.cfg file as explained in Editing the pm.cfg File on Windows NT on page 11-2. Modify the file to include a line similar to the following, which specifies its own host, several individual machines, and a subnet:
set PE_ALLOW_IP_ADDRESSES "207.8.8.8 207.8.8.9 207.8.8.26 207.8.8.181 207.8.8.92 207.8.8.66 207.8.8.60 206.192.67.62 206.193.22"
3 4
Save the changes to the pm.cfg file as explained in Step 9 of Editing the pm.cfg File on Windows NT on page 11-2. Stop and restart the CMS. See Stopping and Starting the CMS with the admin Command on page 8-4 or Stopping and Starting with the Start Menu OptionsWindows NT only on page 8-8. Change the CASs StoryServer.cfg files. See Setting Allowed IP Addresses for a CAS on page 11-15.
11-14
03/01/99
TIP: If a connection to the CMS fails, examine the error logs for the CMS (pm.log) or the CAS processes (for example, pad.log) to find the IP address of the host that couldnt connect. Add the IP address to the pm.cfg file. See Viewing StoryServer Log Files on page 6-14.
Setting Allowed IP Addresses for a CAS

NOTE: The CAS must include the IP address of its own host as well as the IP addresses of the CMS host and any client hosts that run the Admin Center tools. Failure to include all appropriate addresses may cause StoryServer to malfunction.
I To set allowed IP addresses for a CAS: 1 2
Access the CASs StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3. Modify the file to include a line similar to the following, which specifies its own host and a subnet of other machines:
set DE_ALLOW_IP_ADDRESSES "207.8.8.9 207.8.8.181 206.193.22"
3 4
Save the changes to the StoryServer.cfg file, as explained in Step 11 of Editing the StoryServer.cfg File on Windows NT on page 11-3. Stop and start the CAS. See Stopping and Starting the CAS with the admin Command on page 8-6 or Stopping and Starting with the Start Menu OptionsWindows NT only on page 8-8. TIP: If a connection to the CAS fails, examine the error logs for the CMS (pm.log) or the CAS processes (for example, pad.log) to find the IP address of the host that couldnt connect. Add the IP address to the StoryServer.cfg file. See Viewing StoryServer Log Files on page 6-14.
03/01/99
11-15
11-16
03/01/99
12
Summary: Audience:
Variable settings that you can modify to increase performance or adjust for different content or products, and how to use the StoryServer Platform Configuration Program to edit settings in the configuration files on Solaris. Administrators of StoryServer 4.2 on Solaris
Before you begin:
Monitoring StoryServer Servers and Processes on page 4-1 Managing StoryServer Files on Windows NT or Solaris on page 6-1 Increasing Page Generator Requests on Solaris Adjusting Page Generator Timeouts on Solaris Adjusting Page Generator Logging on Solaris Adjusting for Large Database Retrievals on Solaris Increasing Request Handling on Solaris Setting the Thread Pool Size for the Cache Manager on Solaris Adjusting Web Server Processes on Solaris Restricting Access to the Servers by IP address on Solaris
Topics include:
03/01/99
12-1
Increasing Page Generator Requests on Solaris

You can increase Page Generator throughput by increasing the number of requests the Page Generator allows. You must have system admin user privileges on the host system where the CAS is installed to modify the StoryServer.cfg file, in which the request variable is stored.
I To increase Page Generator requests: 1
Open the StoryServer.cfg file: In the PAGE GENERATOR SETTINGS section of the file, find this line:
set CTLD_POOL_SIZE
/install-path/StoryServer/Rn/conf/host-port-number/StoryServer.cfg 2

3
Increase the number, for example, to 10. TIP: Observe how many instances are active over time (on Solaris, for example, ps -eo time,comm | grep ctld) and decrease the pool size number closer to the actual occurrence maximum, depending on your peak load.
4 5 6
Save the changes to the StoryServer.cfg file. Reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2. Run
/install-path/StoryServer/Rn/conf/host-port-number/admin updatepe
to notify the Content Management Server (CMS) of the changes to StoryServer.cfg. For more information on admin updatepe, see Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12.
7
To make the web server use the new value, you must stop your web server and start it again.
12-2
03/01/99
Adjusting Page Generator Timeouts on Solaris

Topics include:
Changes from Previous Releases Setting Page Generation Timeouts RESET_TIMEOUT Template Command
Setting a time limit for page generation prevents a template with a programming error, such as an infinite loop, from tying up a CASs Page Generator.
Changes from Previous Releases

In earlier StoryServer releases, two configuration variables acted together to determine how long a CAS's Page Generator could take to generate a page: the CTLD_EVAL_TIMEOUT set the number of seconds that the Page Generator could take to evaluate a template, and the HTTPD_TIMEOUT variable set the number of seconds that the web server would wait for a response from the Page Generator. Both variables were set in the CASs StoryServer.cfg file. You would set each variable value higher than the default if any template on your site took a long time to generate pages (for example, a complex template or a web-based content entry template that accepted very large content submissions). Page Generation timeout handling has changed to allow more flexibility. The CTLD_EVAL_TIMEOUT variable works differently, and the HTTPD_TIMEOUT variable no longer exists. A new StoryServer template command, RESET_TIMEOUT, is available to set the timeout in individual templates.
Setting Page Generation Timeouts

The length of time the Page Generator can take to generate a page is set in two ways:
With the CTLD_EVAL_TIMEOUT variable in the CASs
StoryServer.cfg file. CTLD_EVAL_TIMEOUT sets the default length of time that the Page Generator can take to evaluate a template and produce a page.
03/01/99
12-3
With a new StoryServer template command, RESET_TIMEOUT.
RESET_TIMEOUT resets the timeout value for the template its in, overriding the CTLD_EVAL_TIMEOUT value.
I To set the Page Generator timeout: 1
Open the StoryServer.cfg file:

In the PAGE GENERATOR SETTINGS section of the file, find this line:
set CTLD_EVAL_TIMEOUT
The default value is 20, the number of seconds the service attempts to evaluate the template.
3
Increase the value to a reasonable length for most templates. TIP: Observe how many instances are active over time (on Solaris, for example, ps -eo time,comm | grep ctld) and decrease the pool size number closer to the actual occurrence maximum, depending on your peak load.
4 5 6
Save the changes to the StoryServer.cfg file. Reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2. Run
to notify the Content Management Server (CMS) of the changes to StoryServer.cfg. For more information on admin updatepe, see Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12.
7
Now, use RESET_TIMEOUT in templates that take a long time to evaluate. (You can also use it in templates that take less time than usual to evaluate.) See the RESET_TIMEOUT Template Command on page 12-5 section. NOTE: If you worked with a previous release of StoryServer, notice the difference in how CTLD_EVAL_TIMEOUT works now. Before, you would set it high enough for the templates that took the longest time to evaluate. Now, you set it high enough for most templates, and you use RESET_TIMEOUT in templates that take longer.
12-4
03/01/99
The length of time that the web server will wait for a response from the Page Generator is either the CTLD_EVAL_TIMEOUT value plus seven seconds or, if the template uses RESET_TIMEOUT, the new timeout value plus seven seconds.
RESET_TIMEOUT Template Command

The RESET_TIMEOUT command has two forms:
RESET_TIMEOUT n
where n is a number specifying seconds. n cannot be 0. This syntax resets the Page Generator timeout to n seconds, regardless of how much time remains in the current timeout period when RESET_TIMEOUT is evaluated. You can use this syntax to increase or lower the default timeout for a particular template.
RESET_TIMEOUT +n
where n is a number specifying seconds. n cannot be 0. This syntax resets the Page Generator timeout, adding n seconds to whatever time remains in the current timeout period when RESET_TIMEOUT is evaluated. For example, if n is 15 and 13 seconds remain when the Page Generator evaluates RESET_TIMEOUT, then the timeout is reset to 28 seconds. Use this syntax to increase the default timeout for a particular template. Its especially useful in library templates. For example, you know a library subroutine takes 10 seconds, but you dont know the other time requirements of the templates that may include the library template. Using [RESET_TIMEOUT +10] in the library template will add enough time for the library subroutine evaluation in whatever template includes it. The maximum value allowed for n with either form is 2147483647 (the standard Tcl limit). Some suggestions for using RESET_TIMEOUT:
Keep in mind that RESET_TIMEOUT must be evaluated before the current
timeout expires.
Place RESET_TIMEOUT near the beginning of the template. You dont have to reset the timeout back to the default: the value is changed
only in the context of the template evaluation. NOTE: Be careful when using RESET_TIMEOUT. Resetting the timeout can potentially tie up resources, since the Page Generator and web server
03/01/99
12-5
will wait indefinitely (if RESET_TIMEOUT is set to a very high value or included in a loop that never completes, for example).
Adjusting Page Generator Logging on Solaris

You can turn audit logging on and off (the default) for the Page Generator. When you are debugging a development CAS, you might want the more informative audit messages, but a live CAS probably doesnt need the additional logging and the necessarily decreased performance. Errors and warnings are still written to the syslogd process when the audit logging is turned off. To modify the CASs StoryServer.cfg file, you must have system admin user privileges on the host system where the CAS is installed.
I To adjust logging: 1
Open the StoryServer.cfg file on the CAS:

In the PAGE GENERATOR SETTINGS section of the file, find this line:
set CTLD_LOG_LEVEL
The default value is 2, meaning auditing is disabled; only errors and warnings will be logged. To enable audit logging, change the value to 4.
3 4 5
Save the changes to the StoryServer.cfg file. Reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2. To notify the CMS of the StoryServer.cfg changes, run:
For more information on admin updatepe, see Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12.
6
12-6
03/01/99
Adjusting for Large Database Retrievals on Solaris

In the DATABASE SERVER SETTINGS section of the CMSs pm.cfg file, you can adjust for some database differences. For example, StoryServer has increased the Sybase SQL Server 11.02 limit to 128 kilobytes for a response to a single database query. If you have templates that request a 300K image from the Sybase database, you should modify the pm.cfg file TEXTSIZE variable to 300K. The TEXTSIZE limit applies to database read operations for Sybase only. It does not apply to Informix or Oracle databases. NOTE: Consult with your database administrator regarding any constraints the database has on handling large binary images. For example, if you use Sybase and are working with large alternate content files such as .gif files, your DBA may recommend that you increase the database procedure cache.
I To adjust settings for large database retrievals: 1 2
Stop the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.) Open the pm.cfg file for the CMS:
/install-path/StoryServer/Rn/conf/Production/pm.cfg
In the DATABASE SERVER SETTINGS section of the file, find this line:
set TEXTSIZE
The default value is 131072 (128K).

4
Increase the number to accommodate the largest image you regularly request from the database, which is the largest image the CAS(s) will have to handle. TIP: For example, for a template that pulls a 300K image, set the value accordingly: 307200 (1024x300).
5 6 7
Save the changes to the pm.cfg file. Start the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.) If you have CASs that access this CMS but are installed on hosts other than the host for the CMS, you must update the remote CASs copy of the pm.cfg file. (See Updating a Remotely Installed CASSolaris only on page 8-11.)
03/01/99
12-7
8 9
Open the /install-path/StoryServer/Rn/conf/delivery.tcl file. Create a variable setting at the end of the file as follows:
set vdbmsg(maxtext) nnnnnn
Set the value (nnnnnn) of the vdbmsg(maxtext) variable to the same size as the largest image the CAS(s) will have to handle. For example, if the largest image is 300KB, set the value to 307200. The internal default (not specified in the delivery.tcl file when shipped) is 32KB.
10
Save the changes to the delivery.tcl file. TIP: This file affects the CASs installed locally with the CMS. Copy this file to any remotely installed CASs /install-path/StoryServer/Rn/conf/delivery.tcl file if you want those CASs to have the vdbmsg(maxtext) variable setting. See Updating a Remotely Installed CASSolaris only on page 8-11.
11
Reset the Page Generator and Template Manager processes in each CAS that accesses this CMS to read the new configuration file values. See Resetting CAS Processes on page 8-2.
Increasing Request Handling on Solaris

The request handling process allows a specified number of requests for template operations or static file (re)submissions to be made at a time. You can increase this number by modifying the VHS_POOL_SIZE variable in the CMSs pm.cfg file. If you modify the VHS_POOL_SIZE variable, you should also modify the PAD_POOL_SIZE variable in the StoryServer.cfg file for each CAS accessing the CMS:
NOTE: Template operations and submission of static files are often timeconsuming operations. There may be some performance cost for increasing the number of requests handled for these operations.
I To increase request handling: 1 2
Stop the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.) Open the pm.cfg file for the CMS:
12-8
03/01/99
In the PRODUCTION MANAGER SETTINGS section of the file, find this line:
set VHS_POOL_SIZE

4 5 6 7
Increase the number, for example, to 10. Save the changes to the pm.cfg file. Start the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.) If you have CASs that access this CMS but are installed on hosts other than the one for the CMS, you must update the remote CASs copy of the pm.cfg file. (See Updating a Remotely Installed CASSolaris only on page 8-11.) To adjust the variable for the Placement Manager, open the StoryServer.cfg file for the CAS: In the PLACEMENT MANAGER SETTINGS section of the file, find this line:
set PAD_POOL_SIZE
/install-path/StoryServer/Rn/conf/host-port-number/StoryServer.cfg 9

10 11 12 13
Increase the number, for example, to 10. Save the changes to the StoryServer.cfg file. The next time you stop and start the CASs, the Placement Manager process reads the new configuration file values. To notify the CMS of the StoryServer.cfg changes, run the updatepe command:
For more information on admin updatepe, see Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12.
03/01/99
12-9
Setting the Thread Pool Size for the Cache Manager on Solaris
If a template is configured to cache its pages, StoryServer generates the related page the first time the template is requested and then stores the page in the disk cache under the web server document root. Subsequent requests for the page receive the cached version directly from disk. The StoryServer Cache Manager (cmd) maintains the cached pages. The Cache Manager flushes a page from the cache when one of three things occurs:
The related template is updated. The flushcache program task, in the StoryServer Production Center, flushes
the template path.

The CLEAR_CACHE template command flushes the template path.
A new variable, CMD_POOL_SIZE, determines how many threads are available to the Cache Manager for flushing the page cache. The CMD_POOL_SIZE variable is set in the Application Servers StoryServer.cfg file. Its default value is 5, and its minimum valid value is 2. You can set the value as high as you want, but typically the most useful range is between 5 and 10. The default value, 5, is reasonable in most cases. If the cache is flushed frequently at your site, then you may want to increase the CMD_POOL_SIZE value to 8 or 10. The higher number lessens the chance that incoming requests will be held up by long requests that arrived earlier. Setting the number higher than 10 or so may use resources unnecessarily. Flushes are done by directory, and only one thread can act on a single directory at one time. For example, suppose the Cache Manager receives three requests, in the order listed, to flush the following paths:
1 2 3
/news/local /news/local /news/local/images
Then separate threads can simultaneously service the requests to flush paths 1 and 3, but the second request to flush /news/local must wait until the first request to flush that path completes. If the Page Generator receives 10 requests to flush a single path, only one thread will run at a time, even if 10 threads are available.
12-10
03/01/99
I To change the default value for CMD_POOL_SIZE: 1
Start editing the CASs StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3. Solaris users will edit the file through their preferred editor; see StoryServer.cfg on page B-33. Find the CMD_POOL_SIZE variable (in the ## CACHE MANAGER SETTINGS section of the file), and change its value. Make the change take effect as explained in Step 11 of Editing the StoryServer.cfg File on Windows NT on page 11-3. Solaris users will edit the file through their preferred editor; see StoryServer.cfg on page B-33. Repeat the procedure for each CAS.
2 3
Adjusting Web Server Processes on Solaris

Many web servers also let you adjust the number of processes that the web server will try to handle concurrently. You should weigh the possible advantages of increasing the number of processes against any performance disadvantage. The recommended number of processes and how you adjust them varies from web server to web server. Consult your web server vendors documentation for specific information.
Restricting Access to the Servers by IP address on Solaris

Topics include:
Setting Allowed IP Addresses for the CMS Setting Allowed IP Addresses for a CAS
By default, StoryServer services accept connection from any source. You can limit access to the CMS and CASs by setting variables in their configuration files to accept connections only from specified IP addresses. NOTE: Examine your specified IP address list carefully to ensure that you have included all the connections that you want to provide, including those of other servers in the StoryServer system.
03/01/99
12-11
You must provide valid IP addresses in the correct format: for example, 207.9.9.8. You can specify each individual machine. You can also specify all machines in a subnet. For example, 207.8.8 would restrict access to only the machines in the 207.8.8 subnet.
Setting Allowed IP Addresses for the CMS

NOTE: The CMS must include the IP address of its own host as well as the IP addresses of all the CAS hosts that need to connect to it and of any client hosts that run the StoryServer tools. Failure to include all appropriate addresses may cause StoryServer to malfunction. To modify the pm.cfg file, you must have system admin user privileges on the CMSs host.
I To specify allowed IP addresses for the CMS: 1 2
Open the pm.cfg file for the CMS:

Modify the file to include a line similar to the following, which specifies its own host, several individual machines, and a subnet:
set PE_ALLOW_IP_ADDRESSES "207.8.8.8 207.8.8.9 207.8.8.26 207.8.8.181 207.8.8.92 207.8.8.66 207.8.8.60 206.192.67.62 206.193.22"
3 4 5
Save the changes to the pm.cfg file. Stop and restart the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4). Change the CASs StoryServer.cfg files. (See Setting Allowed IP Addresses for a CAS on page 12-13.) TIP: If a connection to the CMS fails, examine the error logs for the CMS (pm.log) or the CAS processes (for example, pad.log) to find the IP address of the host that couldnt connect. Add the IP address to the pm.cfg file.
12-12
03/01/99
Setting Allowed IP Addresses for a CAS

NOTE: The CAS must include the IP address of its own host as well as the IP addresses of the CMS host and of any client hosts that run the Admin Center tools. Failure to include all appropriate addresses may cause StoryServer to malfunction. To modify the StoryServer.cfg file, you must have system admin user privileges on the CASs host.
I To set allowed IP addresses for a CAS: 1
Open the StoryServer.cfg file for the CAS:

Modify the file to include a line similar to the following, which specifies its own host and a subnet of other machines:
set DE_ALLOW_IP_ADDRESSES "207.8.8.9 207.8.8.181 206.193.22"
3 4
Save the changes to the StoryServer.cfg file. Stop and start the CAS. (See Stopping and Starting the CAS with the admin Command on page 8-6.) TIP: If a connection to the CAS fails, examine the error logs for the CMS (pm.log) or the CAS processes (for example, pad.log) to find the IP address of the host that couldnt connect. Add the IP address to the StoryServer.cfg file.
03/01/99
12-13
12-14
03/01/99
13
Summary: Audience:
How to transfer projects from one Content Management Server (CMS) to another. Administrators of StoryServer 4.2 Working with the Database on Windows NT or Solaris on page 7-1
Overview Requirements, Assumptions, and Restrictions How Transfer Works transferproject Syntax Transferring Projects Things to Do after Transferring Whats Transferred and What Isnt General Information about Transferring Projects
03/01/99
13-1
Overview
If your company has multiple StoryServer CMSs, you may need at times to transfercopya project from one CMS to another. Some possible reasons to transfer projects:
To move projects from a staging server to a live server For short-term backup To distribute projects from a development environment to live sites To replace existing projects with updated versions
The StoryServer transferproject utility, which you execute at the operating system command prompt, transfers a projectincluding its records, files, and templates, and its subprojects with their records, files, and templatesbetween CMSs. Both CMSs must be running the StoryServer Platform software, version 4.1 or later.
Requirements, Assumptions, and Restrictions

Some conditions for transferring projects:
The Content Management Servers between which you transfer projects
must both be running the StoryServer Platform software, version 4.1 or later. (The exportForm and importForm commands are only available on 4.2.)
The source CMS must be running for all transferproject export
operations. The destination CMS must be running for all transferproject import operations. If a project to be transferred contains file content items, all CASs configured for the CMS must be also running.
The transferproject utility transfers StoryServer project data and
database content only between StoryServer databases. The content to be transferred must be stored in the StoryServer database, not in a separate content database.
You must have the appropriate StoryServer authorization. Members of the
Admin group are authorized for all transferproject operations. For specific authorizations, see the StoryServer Authorizations section.
13-2
03/01/99
You can set an option (-z option) in the transferproject command
to determine what should be done in the event of import conflicts between the source and destination CMSs. See Import Conflicts on page 13-18.
The transferproject utility provides a way for you to transfer
projects, including database content, between CMSs. transferproject is not a database replication tool. After importing content tables from a database of one type to a different database type, you may need to make adjustments for schema differences. For example, you may need to add primary keys and indexes. See Things to Do after Transferring on page 13-28.
transferproject handles most standard SQL datatypes, but
differences in database datatype restrictions may prevent some database content from transferring between databases of different types. See Schema Restrictions on page 13-25.
The transferproject delete options delete projects (with all their
subprojects) and database tables on the destination CMS. You must use them with caution to avoid deleting projects, templates, records, files, and tables you didnt intend to.
transferproject uses an intermediate file format, the project
package. Project package file formats may change in future releases, so project packages are suitable for short-term backups only. Conflicts may arise when transferring projects between different versions of the StoryServer Platform Software, for instance because MSIE 3 browser capability is supported on 4.1 but not on 4.2.
Transferring projects can have significant impact on CMS performance on
both the export side and the import side. For both operations, transferproject makes continuous requests to the CMS processes. If possible, transfer projectsespecially large onesat off-peak times.
transferproject doesnt transfer all project and content properties,
and you may want to change some that are transferred or inherited from the parent project at the destination CMS. See Whats Transferred and What Isnt on page 13-29.
All files, records, and templates are imported with a status of Live,
Ready To Launch, or Ready For Internal Use. Unless you want all imported content (except for internal use only templates) to launch immediately, make sure the parent project doesnt have the autolaunch attribute set: Automatically launch content as soon as workflow completes.
03/01/99
13-3
If you want content that is Live on the source CMS to appear with the
status Ready for Launch on the destination CMS, use the -s option with the transferproject command. See Parent Project and Status of Imported Content Items on page 13-34. NOTE: If the autolaunch attribute for the destination CMS is turned on, the -s option will not prevent transferred content from being launched. The destination CMS will see that the transferred content is Ready for Launch and launch it immediately.
When templates are transferred, their IDs are automatically reset on the
destination CMS. If any templates use the INCLUDE LIB command (which specifies a library template by its ID), you must modify them after the transfer. See Things to Do after Transferring on page 13-28.
How Transfer Works

Topics include:
Exporting and Importing Projects Typical Transfers StoryServer Project Data and Database Content Project Package Transferring Content Design Objects
Exporting and Importing Projects

To transfer a project, you export the project from the source CMS into a package (a set of files), and you import that package into the destination CMS. (For a description of the project package, see Contents of Project Package on page 13-35.)
13-4
03/01/99
Different operations of the transferproject utility handle both exporting and importing the project:
export export -r exportData import importData Exports Project Data Exports Project Data and any Database Content referenced by records Exports all Database Content for the project Imports Project Data Imports Database Content
NOTE: You will have to use both import and importData to unpack a single project package created with export -r. Some characteristics of project transfer:
When you import a project, it is immediately available on the CMS. If you
are connected to the CMS through the StoryServer Tools, you can see the project appear in the Project Managers project listing.
A project is transferred with all its records, files, and templates, as well as
its subprojects, their records, files, and templates, and so on.

You can transfer the StoryServer project data and the database content
independently.
You can transfer projects regardless of operating system and StoryServer
database type. For example, you can transfer a project from a CMS installed on Solaris with an Oracle database to another CMS installed on Windows NT with an MS SQLServer database.
You can transfer a project from any point of the source project hierarchy,
and you can import the project to any point of the destination project hierarchy (except that no project can be above the Base Project).
When you export a project from the source CMS, you specify the projects
content management ID. The package created includes that project and all its subprojects, if any, and all their subprojects, and so on. When you import a project, you specify the management ID of an existing project on the destination CMS. That project will be the parent project of the imported project.
When you import a project that contains file content items, the destination
CASs must be running.
03/01/99
13-5
After you transfer a project, you may want to make some changes. For example, you may want to create workflow tasks for the transferred content or create any necessary table schema. The figures that follow show how projects can be exported from different parts of the source CMSs project hierarchy and imported into different parts of the destination CMSs project hierarchy. In Figure 13-1, the project specified for export is Archery. The project package includes the StoryServer project data for Archery and its subprojects. At the destination CMS, the Base Project is specified to be the parent of the imported project.
Figure 13-1: Transferring a Project to the Base Project
from source CM Server
project package
to destination CM Server
13-6
03/01/99
In Figure 13-2, the project specified for export is Templates, a subproject of the Archery project. The project package includes the StoryServer project data for Templates and its subprojects. At the destination CMS, the College Sports project is specified to be the parent of the imported project. College Sports already contains a subproject called Content.
Figure 13-2: Transferring a Project to a Lower Level in the Hierarchy
from source CM Server
project package
to destination CM Server
03/01/99
13-7
Table 13-3 shows the project contents on the source and destination CMSs. Notice that all the content items have transferred, that the status of the content items has changed, and that the tasks in the source project didnt transfer to the destination project.
Figure 13-3: Project Contents
project on source CM Server
project package
project on destination CM Server
13-8
03/01/99
Typical Transfers
There are three basic situations for project transfer:
Youre adding a project to a destination CMS, and the project doesnt
already exist on that CMS. For example, you may have added a CMS in another area and want to transfer certain projects to it.
Youre replacing a project on the destination CMS with some variation of
the same project. For example, you may have redesigned the projects templates on a CMS reserved for development work and now want to update the original project.
You want to add the contents of a project to another project on a different
CMS. You can do any of the following transfers with transferproject:

You can import a new project to the CMS or update (or overwrite) an
existing project with new content.

You can import the project to a new location (and project name) or import it
to an existing location (and project name). Later sections in this chapter explain these transferproject operations. Heres a typical sequence for transferring a project. It assumes that youre importing a project thats new to the destination CMS, not updating an existing project or adding contents to an existing project. The sequence:
1
If you are working on Solaris, make sure that the required database environment variables are set correctly. See Setting Environment Variables on Solaris on page 13-16. With transferprojects export operation, export the StoryServer project data for the project from the source CMS. The StoryServer project data includes the project hierarchy and all StoryServer metadata, records, templates, files, and keywords, but not tasks, authorizations, notes, and so on. See Whats Transferred and What Isnt on page 13-29. transferproject exports the data as a set of files. The set of files is called a project package. transferproject places the files into a directory you specify, the project package directory.
3 4
With transferprojects exportData operation, export the database content for the project from the source CMS. At the destination CMS, check the attributes of the project under which the new project will be imported (the destination parent project). Turn off
03/01/99
13-9
automatic launch if you dont want the transferred content items to go Live immediately. See transferproject on page A-31.
5 6
Import the database content to the destination CMS with transferprojects importData operation. The import operation exits if it finds a conflict between the source database content and the destination database (such as duplicate table names). Resolve the conflict and execute the command again. To force the operation to continue despite errors, you can use the -k option. See transferproject on page A-31.
Import the StoryServer project data to the destination CMS with transferprojects import operation. You specify the parent project for the transferred project. If the import operation finds conflicts between the source and destination projects (such as duplicate template names or file path names), it lists the conflicts and exits, unless you use the -z option to specify how to handle object conflicts. If you do not use -z, you will want to resolve any conflicts and execute the command again. See transferproject on page A-31. After completing the transfers, make any changes needed or desirable for the project on the destination CMS.
StoryServer Project Data and Database Content

transferproject distinguishes projects conceptually into two parts:
The StoryServer project data. The project data includes templates, files, and
the project metadata, such as project hierarchy, project properties, content properties, and records. The project data is stored in system tables in the StoryServer database.
Database content. The database content consists of rows in content tables in
the StoryServer database. The rows may or may not correspond to records. When you transfer a project, you may or may not need to transfer both StoryServer project data and database content. For example, suppose the content tables are stored in a separate content database, not in the StoryServer database. If the content database is accessible to the destination CMS, theres no need to transfer the tables. If the content database isnt accessible to the
13-10
03/01/99
destination CMS, you may wish to use a database tool, such as Sybases bcp, to transfer the tables more efficiently. Or suppose a project contains templates that reference content (for example, with the SEARCH command), but you havent created any records for the content. (A database row requires a record only if you want to manage its productionworkflow, launch schedule, and so onthrough the StoryServer Production Center.) In that case, theres no need to transfer content tables, so you would transfer only the StoryServer project data. (Of course, you have to ensure that the templates can access the content from the destination CMS.) Conversely, perhaps you want to transfer only database content, not a projectto have sample content available as you develop templates, for example. NOTE: If a transferred template lists a primary table in its Details window, the destination CMS creates an entry for that table (if one doesnt already exist) in the next_id table in its StoryServer system database. No entries are made in the destination next_id table for database tables transferred without StoryServer project data. There are two ways to transfer database content with transferproject:
Transfer the database content by itself, specifying one or more tables to
transfer. transferproject will transfer all the rows in the tables.

Transfer database content along with the projects StoryServer project data.
transferproject automatically finds the database rows associated with each transferred record and includes only those rows when it transfers the tables. As a general rule, its preferable to import a projects database content before its StoryServer project data, so the content will be available when templates are accessed.
Project Package
A project package is a set of files that a transferproject export, exportData, or exportForm operation creates and places in a directory you specify. The base name of each file is the name of the project package directory, and each file has an extension corresponding to its content. For example, if transferprojects export operation creates the project package in the directory/opt/ssxfer, the directory will contain this set of files:
03/01/99
13-11
ssxfer.attr (ssxfer.tar) or (ssxfer.zip and ssxfer.exe) ssxfer.data ssxfer.purge ssxfer.sch.syb ssxfer.sch.inf ssxfer.sch.mss ssxfer.sch.ora Two of the files contain the StoryServer project data:
The .attr file contains the StoryServer project data for the project,
subprojects, records, and templates. NOTE: The .attr file is structured like a binary file. Do not edit it, and use binary mode when moving a project package from Solaris to Windows NT.
The .tar or .exe file contains a distribution package for the file content
items in the project. The .exe file is a self-extracting zip archive. The other files are related to database content:
The .data file contains the database row contents for records in the
project.
The .purge file contains SQL statements for dropping the tables
transferred with the project. transferprojects deleteData operation processes the SQL to delete the tables from the destination database.
Each of the remaining files (*.sch.*) is a schema file specific to the
Sybase, Informix, Microsoft SQL Server, or Oracle database type. These files contain SQL statements for creating the tables the project needs in the destination database. Notice that a schema file is created for each database type, so the package can be imported into any CMS regardless of which of the database types it uses. When the export operation creates the project package, the package contains all the files, but the database content files will all be 0 bytes in length (unless you include the -r option, which is discussed later). The -o exportData option creates a project package that contains only the files related to database content. For more information, see Contents of Project Package on page 13-35.
13-12
03/01/99
Transferring Content Design Objects

In addition to Project Data and Database Content, the transferproject command allows you to transfer Content Design Objects (that is, form sets and data collections) generated with the Content Designer, a tool available in the StoryServer Development Center. As with Project Data and Database Content, you first export information from a source CMS to a project package and then import the contents of the project package into the destination CMS. In this case, the project package contains only one file, in the form projPackageDir.attr_fs. For example, ssxfer.attr_fs. To transfer Content Design Objects, you will use the exportForm and importForm operations with the transferproject command. For information on syntax and usage, see the table below or transferproject on page A-31. For more information about the Content Designer, see Using the Content Designer or Template Fundamentals. For example:
transferproject -o exportForm -p /film -v -b juno:13666 -t "Siskel & Ebert" transferproject -o importForm -p /film -v -b ozone:25000
The exportForm operation creates a file in the project package directory (/film) with the extension .attr_fs. In the above example, the file film.attr_fs would be created. The -t option is used to specify one (or more) form set names. Since form set names can contain a space, "," functions as a delimiter:
-t "Siskel & Ebert,Rex Reed"
transferproject Syntax
The transferproject command resides in the StoryServer operatingsystem directory below the bin directory. The default locations:
S UN
/install-path/StoryServer/Rn/bin/solaris
NT
\Program Files\Vignette\StoryServer n\Engines\Rn\bin\winnt
03/01/99
13-13
NOTE: Execute the transferproject command from the bin/solaris directory or the bin\winnt directory. Syntax as shown in the transferproject usage statement:
transferproject -b host:port:projectid -o { export [ -f file-format ] [ -r ] import [ -s ] [ -z option [ -n version]] delete exportData -t table-list importData [ -k ] deleteData [ -k ] exportForm -t form set-list importForm } -p directory [ -l logininfo ] [ -v ] [ -? ]
You specify the operation that transferproject performsexport the StoryServer project data, export the database content, import the StoryServer project data, and so onwith the -o operation option, where operation can be export, import, delete, exportData, importData, deleteData, exportForm, or importForm. NOTE: For legibility, this chapter shows examples of the transferproject command broken into multiple lines. Always enter the command as one line. The table below shows the transferproject syntax by operation. For the options and arguments, see transferproject on page A-31 of Appendix A.
delete delete StoryServer project data transferproject -o delete -b destCMhost:port:projID -l SSusername:password [-v] deleteData delete database content transferproject -o deleteData [-k] -b destCMhost:port -p projPackageDir -l SSusername:password [-v] export export StoryServer project data transferproject -o export -b sourceCMhost:port:projID -p projPackageDir -l SSusername:password [-f file-format] [-v]
13-14
03/01/99
export export StoryServer project data and database content transferproject -o export -r -b sourceCMhost:port:projID -p projPackageDir -l SSusername:password [-f file-format] [-v] exportData export database content transferproject -o exportData -b sourceCMhost:port -p projPackageDir -l SSusername:password -t "table-list" [-v] import import StoryServer project data transferproject -o import [-s] [-z option [ -n version ]] -p projPackageDir -b destCMhost:port:projID -l SSusername:password [-v] importData import database content transferproject -o importData [-k] -b destCMhost:port -p projPackageDir -l SSusername:password [-v] exportForm export Content Designer form set-list (For use with StoryServer Development Center.) transferproject -o exportForm -b sourceCMhost:port -p projPackageDir -l SSusername:password -t "form set-list" [-v] importForm import Content Designer form set-list (For use with StoryServer Development Center.) transferproject -o importForm -b destCMhost:port -p projPackageDir -l SSusername:password [-v] none display a usage statement transferproject -?
03/01/99
13-15
Transferring Projects
Topics include:
transferproject Permissions and Other Requirements Setting Environment Variables on Solaris Import Conflicts Finding Project IDs Exporting StoryServer Project Data Exporting StoryServer Project Data and Database Content Together Importing StoryServer Project Data Exporting Database Content Importing Database Content Deleting StoryServer Project Data Deleting Database Content Moving a Project Package
transferproject Permissions and Other Requirements

The general requirements for using the transferproject command:
For export operations, you must have a StoryServer user ID on the CMS
from which the project is exported, and you must have write permission for the project package directory.
For import operations, you must have a StoryServer user ID on the CMS to
which the project is imported, and you must have read permission for the project package directory. To import StoryServer project data, you must also have the appropriate StoryServer authorization. See StoryServer Authorizations on page 13-33.
For delete operations, you must have a StoryServer user ID on the CMS to
which the project is imported, and you must have read permission for the project package directory. To delete StoryServer project data, you must also have the appropriate StoryServer authorization. See StoryServer Authorizations on page 13-33.
On Solaris, the appropriate environment variables must be set. See Setting
Environment Variables on Solaris on page 13-16.
Setting Environment Variables on Solaris

On Solaris, the transferproject utility requires that some environment variables be set if youre exporting, importing, or deleting database content:
13-16
03/01/99
LD_LIBRARY_PATH Path to the StoryServer libraries. Set the variable
to this value: /install-path/StoryServer/Rn/lib/solaris

ORACLE_HOME, SYBASE, or INFORMIXDIR and INFORMIXSERVER
Database-specific identifier. Set this environment variable before using the exportData, importData, or deleteData operation. Set the database environment variable for the database type used by the CMS you identify with transferprojects -b option (the source CMS with the exportData operation and the destination CMS with the importData and deleteData operations). The variable must be valid on the machine where transferproject is executed. Set the variable to the path of the database client installation, as explained in the database client documentation. For an Informix database, also set the INFORMIXSERVER variable to the logical name of the Informix database server. If the library path isnt set when you execute one of the transferproject operations that requires it, the transfer will fail. transferproject will report something like this: [DBNOTFOUND] No access library ... If the database variable isnt set, transferproject will report that the connect to the database failed, and a message from the database server should report the reason for the failure. Some things to keep in mind:
If you are exporting data and then importing it within the same
environment, you can set all the variables before starting, as long as the database identifiers dont conflict. For example, if you are transferring data between Oracle and Sybase databases, you can set the PATH, LD_LIBRARY_PATH, ORACLE_HOME, and SYBASE variables once before starting the transfer operations.
If you are transferring between databases of the same type, you may need to
reset the database environment variable if the export and import operations need to access different database clients. For example, if you are transferring database content between two Informix databases, you must reset the INFORMIXSERVER environment variable between export and import operations if the database clients access a different server, even if the clients are the same.
03/01/99
13-17
Import Conflicts
Before importing a project, transferprojects import operation checks for conflicts between the project data and the StoryServer data for the destination CMSs projects. By default, if it finds conflicts, it reports them and exits. You can adjust this behavior by using the -z option with the transferproject command. See transferproject on page A-31. A conflict occurs when one of the following items, which must be unique on a CMS, is the same on the CMS and in the project to be imported:
Template name Template path File path name Record definition, which consists of the database key (primary key name
and value), table name, database name, and database server name For example, suppose the project youre importing contains a template named Catalog Insert.If a template with that name already exists on the destination CMS, the transfer wont work. transferproject will report that a template of the same name already exists. transferproject -o import checks for all conflicts, rather than exiting as soon as it finds one conflict, so you can fix them all at once and then execute transferproject again. transferproject treats project names differently from template names, template paths, file path names, and record definitions. StoryServer doesnt permit two subprojects of the same parent project to have the same name, but transferproject will import a project that has the same name as a subproject of the destination parent project. However, instead of creating a separate project, transferproject adds the contents of the transferred project to the existing project on the destination system. The constraints for template names, template paths, file path names, and record definitions still apply: the transfer will fail if there are conflicts on the destination CMS.
Finding Project IDs

When you export a projects StoryServer project data, you must know the StoryServer management ID of the project to export. When you import a projects project data, you need the ID of the project to put the new project under. To delete a project, you need its ID.
13-18
03/01/99
I To find project IDs through the StoryServer Tools Project Manager: 1 2
From the StoryServer Tools launch bar, open the Production Centers Project Manager. Check the projects management ID in either of these ways:
Select the project, open its Details window, and go to the Misc page.
Youll see this line: Management ID: /pr/number.

Select the projects parent project in the Projects pane. The management
ID of the project youre looking for is probably listed in the Contents pane. If it isnt, select the Set Visible Columns button and add Mgmt ID to the list of columns selected for display. The button looks like this:
If you want to put an imported project directly under the Base Project in the project hierarchy, specify /pr/a, which is the management ID of the Base Project on all CMSs.
Exporting StoryServer Project Data

To export a projects StoryServer project data (without its database content), enter this command at the command line:
transferproject -o export -b sourceCMhost:port:projID -p projPackageDir -l SSusername:password [-f file-format] [-v]
If you do not use the -f argument, on Windows NT, the files are saved in zip format by default. On Solaris, the files are saved in tar format by default. Use the -f argument to specify tar on Windows NT, or zip on Solaris. See transferproject Syntax on page 13-13 for other argument descriptions. As transferproject creates the project package, it reports that its querying project, template, record, and file information and creating the file distribution for the project. The following command exports the project with management ID /pr/34, on the CMS host sorcerer and CMS port 62120. It places the project package in the directory /opt/ssxfer. The package includes StoryServer project data for project /pr/34 and all its subprojects, if it has any.
03/01/99
13-19
transferproject -o export -b sorcerer:62120:/pr/34 -p /opt/ssxfer -l swalker:hi11top
The following command exports the project with management ID /pr/51, on the CMS host sable and CMS port 37500. It places the project package in the directory /prog/prtransfer. Any file content items in the project are packaged in tar format.
transferproject -o export -b sable:37500:/pr/51 -p /prog/prtransfer -f tar -l gchau:timber6025
Exporting StoryServer Project Data and Database Content Together

To export a projects StoryServer project data and its database content, you can specify the -r option when you execute transferprojects export operation. The -r option is designed for simple transfers, that is, transfers in which the project has a small set of database content and each content row has a corresponding Production Center record. With the -r option to export, transferproject finds the database rows corresponding to all CMS content item records in the project. It exports tables that contain only the rows for the content item records, instead of exporting all the rows in the source tables. For example, if a source table contains 1000 rows, and you want only the 300 rows that correspond to content item records in the project, then -r is a more efficient choice than a separate exportData operation. (If youre replacing tables in the destination database, remember that tables created with export -r will contain content rows for the imported projects content item records only.) If you want to export entire tables, regardless of whether rows correspond to project records, use the exportData operation instead of the -r option. (See Exporting Database Content on page 13-22.) To export a projects StoryServer project data and database content, enter this command at the command line:
transferproject -r -o export -b sourceCMhost:port:projID -p projPackageDir -l SSusername:password [-f file-format] [-v]
See transferproject Syntax on page 13-13 for argument descriptions.
13-20
03/01/99
To import the project at the destination system, you use both the import operation and the importData operation, just as you would if you had exported the StoryServer project data and the database content separately. The following command exports the project with management ID /pr/22, on the CMS host sable and CMS port 37500, including both the projects StoryServer project data and its database content:
transferproject -o export -r -b sable:37500:/pr/22 -p /prog/prtransfer -l Admin:Bnutmeg31
If transferproject cant find the row data corresponding to a content item record, a message reports an error querying the record data and identifies the database and record ID. This message also appears:
Error getting object record: No such row
Importing StoryServer Project Data

I To import a project from a project package created by the export operation: 1
Make sure the automatic launch attribute of the destination parent project is set correctly for the result you want. The workflows of content items arent transferred. Depending on how the automatic launch attribute is set in the parent project, templates, records, and files will be Live or Ready To Launch immediately after the project is imported (except for internal use only templates, which always transfer as Ready For Internal Use). See Parent Project and Status of Imported Content Items on page 13-34. NOTE: To keep imported content items from launching immediately, make sure the automatic launch attribute is not selected in the parent projects Details window. See transferproject on page A-31.
If the destination parent project already has a subproject with the same name as the project you want to import, choose what to do:
If you want to replace the destination project (for example, if you want to
import an updated version of the project), either delete it, following the procedure explained in Deleting StoryServer Project Data on page 13-26, or use the -z option to specify how to handle import problems. See transferproject on page A-31.
If you want to add the contents of the imported project to the destination
project, import the project.
03/01/99
13-21
If you want both the existing destination project and the imported project
to exist separately on the CMS, change the name of one of the projects, or specify a different destination parent project for the imported project.
3
If the project package isnt accessible to the machine where it will be imported, move the project package to an accessible location. See Moving a Project Package on page 13-27. Enter this command at the command line:
transferproject -o import -p projPackageDir [-v] -b destCMhost:port:projID -l SSusername:password
projID is the management ID of the project that will be the parent of the project youre importing. See transferproject Syntax on page 13-13 for other argument descriptions. As transferproject imports the project package, it reports that its transferring project, template, record, and file information and creating the file distribution for the project. When the transfer completes, the transferred project will be available through the StoryServer Production Center. The database rows corresponding to the project records wont be available unless theyve already been imported from a project package with the importData operation. NOTE: The management ID of the Base Project is always /pr/a. Specify /pr/a as the project ID if you want the imported package to be immediately below the Base Project in the project hierarchy. The following command imports a project from the project package directory /apps/ssxfer to the CMS host destiny at port 50220. The project files are in the default format. The management ID of the parent project on destiny is /pr/67.
transferproject -o import -b destiny:50220:/pr/67 -p /apps/ssxfer -l pgranger:784wingtips
Exporting Database Content

To export database tables to a project package, enter this command at the command line:
transferproject -o exportData -b sourceCMhost:port -p projPackageDir -l SSusername:password -t "table-list" [-v]
table-list is a list of one or more tables to export. Put spaces between table names, and surround the list with quotation marks if it includes more than one
13-22
03/01/99
table. See transferproject Syntax on page 13-13 for other argument descriptions. The following command exports the tables Auditnos and Audithist from the database used by the CMS at sorcerer:62120. It places the project package in the directory /opt/ssxfer.
transferproject -o exportData -b sorcerer:62120 -p /opt/ssxfer -t "Auditnos Audithist" -l swalker:hilltop
Importing Database Content

The importData operation imports database content from a project package created either by either of these transferproject operations:
transferproject -o exportData transferproject -o export -r
To import database content from a project package, follow these steps:

1
If the tables you want to import already exist in the database used by the destination CMS (for example, if you want to import updated versions of the tables), delete them, following the procedure explained in Deleting Database Content on page 13-26. If the project package isnt accessible to the machine where it will be imported, move the project package to an accessible location. See Moving a Project Package on page 13-27. Enter this command at the command line:
transferproject -o importData [-k] -b destCMhost:port -p projPackageDir -l SSusername:password [-v]
The -k option tells transferproject to continue even if an error occurs while its processing the schema file. See When to Use the k Option on page 13-24. For other argument descriptions, see transferproject Syntax on page 13-13. If any table with the same name as one of the imported tables already exists in the destination database (and you havent specified the -k option), transferproject reports the error and exits after the first error. (For other errors that prevent the import operation from completing, see Schema Restrictions on page 13-25.)
03/01/99
13-23
The following command imports the project package thats in the directory /apps/ssxfer. transferproject creates the transferred tables in the database used by the CMS at delrio:36550.
transferproject -o importData -b delrio:36550 -p /apps/ssxfer -l Admin:axTR89
When to Use the k Option
The importData operation executes SQL statements from a schema file to import database content. It takes the SQL from the schema file corresponding to the destination database type in the project package. If importData encounters an SQL error while processing the schema file, it exits by default. The -k option forces importData to continue even if a processing error occurs. For example, if importData cant create a table because the table already exists in the destination database, importData will continue, even though the table creation failed. Similarly, the deleteData operation executes SQL statements from the purge file in the project package and exits by default if an error occurs. The k option forces deleteData to continue even if a processing error occurs. Some examples of using -k:
After exporting the content data, you manually dropped one of the tables
listed in the project packages purge file. With -k, deleteData deletes the remaining tables, even though it couldnt delete the one you dropped.
Youre importing three tables, and one of them already exists in the
destination StoryServer system database. With -k, importData creates the other two tables, even though it couldnt create the third.
Youre importing a table with 50 rows, and the same table exists in the
destination StoryServer system database. The existing table contains 40 rows. With -k, importData inserts the unique 10 rows from the project package table into the existing table, even though it couldnt create the table and even though the other 40 attempts to insert a row failed. Keep in mind that sequence affects what actually happens if a processing error occurs and you havent specified -k. Take the middle example aboveyoure importing three tables, and one of them already exists in the destination StoryServer system database. If the existing table is the last one specified in the project package schema file, then the processing error doesnt occur until after the importData operation has created the two other tables. If the
13-24
03/01/99
existing table is the first one specified in the schema file, the processing error occurs before the importData operation has created any of the tables. Similarly, assume that you dont specify -k with the third example (importing a table with 50 rows), and the first four rows in the project package table are unique, but the fifth is already in the existing table. The importData operation inserts the first four of the 50 rows from the project package table into the existing table before a processing error occurs (it cant insert the fifth row) and transferproject exits.
Schema Restrictions
Remember that transferproject, although it successfully transfers content between databases regardless of their type, is not a database replication tool. If youre transferring content between databases of different types, schema restrictions may prevent database content from being imported. Some examples of schema restrictions that can cause errors with transferproject -o importData:
Datatypes Oracle has a limit of one unbounded text type (the Oracle
LONG datatype), but Sybase, Informix, and Microsoft SQLServer allow multiple unbounded text types in a single table. The schema file that is created for Oracle will have two unbounded text columns that use the LONG datatype. If the destination database is Oracle 7, which allows only one unbounded column per table, the import will fail. Various databases have various limits on the maximum sizes of certain datatypes, for example, limitations on precision and scale components for numeric datatypes, or limitations on the maximum size of a character datatype.
Case sensitivity Sybase and Microsoft SQLServer allow mixed case:
two columns can be defined with names different only in case, such as empPhone and EmpPhone. Oracle treats everything as uppercase. If the source database is Sybase or MS SQLServer and the destination database is Oracle, the Oracle schema file will have two columns named EMPPHONE, which is not allowed. Informix treats everything as lowercase, so the Informix schema file will have two columns named empphone, which is not allowed.
Column sizes Informix allows a character column to be defined with a
maximum of 32k1 characters. Oracle character columns have a maximum of 2000 characters.
03/01/99
13-25
Deleting StoryServer Project Data

You delete a projects StoryServer project data with transferprojects delete operation. The StoryServer project data includes all the projects contents and the subprojects under it in the project hierarchy. When you delete projects, be sure youre deleting at the right level of the project hierarchy. Remember that the delete operation will delete not only the specified project, but all its subprojects, their subprojects, and so on down the hierarchy. Before deleting a project, be sure that its all right to delete its contents and the contents of all its subprojects. Check for new templates, records, or files that StoryServer users may have added. To delete a projects StoryServer project data (all its contents, including its subprojects and all their contents), enter this command at the command line:
transferproject -o delete -b destCMhost:port:projID -l SSusername:password [-v]
The following command deletes the StoryServer project data of project /pr/49 and all of its subprojects from the CMS host ducat at port 66650.
transferproject -o delete -b ducat:66650:/pr/49 -l MIS:TWL6564
NOTE: You cant delete the Base Project, /pr/a. If you try to delete it, transferproject displays a message that deleting the Base Project isnt allowed.
Deleting Database Content

The deleteData operation to transferproject works from the purge file in a project package created by the exportData operation or the export operation with the -r option. The purge file lists the tables to be dropped from the destination StoryServer database. To avoid losing database content from the destination database when you transfer projects, you must understand what tables will be dropped and know whats in them. To see what tables deleteData will drop, check the package-directoryname.purge file in the project package. (See Contents of Project Package on page 13-35.) Before executing deleteData, make sure that the tables can be dropped. Back them up if necessary.
13-26
03/01/99
To delete a projects database content, enter this command at the command line:
transferproject -o deleteData [-k] -b destCMhost:port -p projPackageDir -l SSusername:password [-v]
projPackageDir must be the directory where the project package created by exportData or export -r is stored. Use the -k option to force the deleteData operation to continue despite any SQL errors that occur when it processes the purge file. See When to Use the k Option on page 13-24. In the following example the first command exports the database content (the PartNo and Catalog tables) of project /pr/64 on CMS host samson at port 78900. It puts the project package in the directory /baker/systems/xfer. The second command drops the PartNo and Catalog tables of project /pr/41 from the database used by the CMS host ducat at port 66650. The third command imports the database content from the project package created by the first command. The tables are imported to CMS host ducat at port 66650.
transferproject -o exportData -b samson:78900 -p /baker/systems/xfer -t "PartNo Catalog" -l H98_ay4Np:jQ18p transferproject -o deleteData -b ducat:66650 -p /baker/systems/xfer -l janeR:snowstorm transferproject -o importData -b ducat:66650 -p /baker/systems/xfer -l janeR:snowstorm
NOTE: The deleteData step above is optional.
Moving a Project Package

After you create a project package with transferprojects -o export operation or -o exportData operation, move it if the project package directory isnt accessible to the destination CMS. NOTE: transferproject requires that the project package directory name and the base name of the project package files be the same. Follow these steps to move the project package:
03/01/99
13-27
Create a directory on the destination machine with the same name as the project package directory on the source machine. For example, if the directory on the source machine is /opt/SS/transfers, create a directory named transfers on the destination machine (for example, /fs6/ss/transfers).
Copy the package files to the matching directory on the destination machine, using standard operating system tools. NOTE: The project package includes a file with the extension .attr. This file, which contains the StoryServer project data, must be treated like a binary file. When moving a project package from Solaris to Windows NT, use binary mode. Otherwise, the .attr file will be invalid on Windows NT.
Things to Do after Transferring

Some things to check and do after importing a project:
Adjust project properties as needed (owners, users, attributes, workflow,
default template paths).

Recreate any necessary table schema information not included in the
transfer, such as primary keys, foreign keys, indexes, and unique constraints.
Modify any templates that use the INCLUDE LIB command, which
specifies a library template by its ID, to use the INCLUDE LIBNAME command, which specifies the library template by its name. (Theres no longer a performance penalty for including libraries by name rather than by ID.) This change is necessary because template IDs are automatically reset on the destination CMS.
If you transferred any database content without corresponding project data,
manually create an entry in the next_id table for any table that requires one and for which an entry doesnt already exist. A table requires an entry in the next_id table if its identified as the primary database table by any template. Enter the table name in the tblName column, and enter the next available ID for that table in the id column. The next available ID is one more than the largest ID value in the imported row data. For example, if you import a table with 50 rows, and the rows have IDs that range from 251 through 300,
13-28
03/01/99
then enter 301 in the id column. If for some reason you import an empty table, set the next available ID to 1. You may also want to add a note about the transfer to the project and to save versions of the imported templates, records, and files.
Whats Transferred and What Isnt

The tables that follow show which project, template, record, and file properties are transferred to the destination project. The tables also show how the properties that arent transferred are handled. The following table shows which project properties transferproject transfers.
Project Property parent project name attributes (final review by owner, automatic launch, automatic versioning on launch) project owners authorized users default template paths default workflows management ID history Transferred? no yes no inherited from destination parent project inherited from destination parent project inherited from destination parent project Inherited or Replaced? replaced with destination parent project
no no yes no no no
inherited from destination parent project inherited from destination parent project no
03/01/99
13-29
Project Property keywords
Transferred? yes/no
Inherited or Replaced? Keywords at the project level are not maintained. Category:keyword information is maintained in templates and records transferred with projects, and the Keyword Manager for the destination CMS is updated with any new keyword information found in those templates and records.
versions notes tasks subprojects templates files records rows (database content)
no no no yes yes yes yes yes (with export -r or exportData)
no no no
NOTE: transferproject exports the current copy (last saved copy) of records, files, and templates. The following table shows which template properties transferproject transfers.
Template Property name cache setting body internal-use-only setting paths Transferred? yes yes yes yes yes Inherited or Replaced?
13-30
03/01/99
Template Property primary table file extension category template ID management ID workflow status
Transferred? yes yes yes no no no yes/no
Inherited or Replaced?
replaced with new one replaced with new one no
launchable template: if was Live, becomes Live (unless you use the -s option, in which case Live becomes Ready to Launch); if not originally Live, becomes Ready To Launch internal use only template: always becomes Ready For Internal Use.
history versions keywords
no no yes
no no category:keyword information is maintained in transferred templates and the Keyword Manager for the destination CMS is updated with any new information. no
notes
no
The following table shows which record properties transferproject transfers.

Record Property name table name Transferred? yes yes Inherited or Replaced?
03/01/99
13-31
Record Property database information (server, database name, primary key name) database management ID workflow status
Transferred? no
Inherited or Replaced? replaced with destination servers database information replaced with new one replaced with new one no if was Live, becomes Live (unless you use the -s option, in which case Live becomes Ready to Launch); otherwise, becomes Ready To Launch no no category:keyword information is maintained in transferred records, and the Keyword Manager for the destination CMS is updated with any new information no
no no no yes/no
history versions keywords
no no yes
notes
no
The following table shows which file properties transferproject transfers.

File Property name content path management ID workflow Transferred? yes yes yes no no replaced with new one no Inherited or Replaced?
13-32
03/01/99
File Property status
Transferred? yes/no
Inherited or Replaced? if was Live, becomes Live (unless you use the -s option, in which case Live becomes Ready to Launch); otherwise, becomes Ready To Launch no no no
history versions notes
no no no
General Information about Transferring Projects

Topics covered:
StoryServer Authorizations Parent Project and Status of Imported Content Items Contents of Project Package
StoryServer Authorizations
The following table shows the required StoryServer authorizations for transferproject operations. Members of the Admin group are authorized for all operations.
Operation delete StoryServer Authorization Needed Owner of destination projects parent project, and authorized to delete the templates, records, and files in the project (content owner, owner of project to be deleted, or member of Admin group) Any StoryServer user of the destination CMS Any StoryServer user of the source CMS Any StoryServer user of the source CMS Any StoryServer user of the source CMS Owner of the parent project on the destination CMS
deleteData export exportData exportForm import
03/01/99
13-33
Operation importData importForm
StoryServer Authorization Needed Any StoryServer user of the destination CMS User with Content Designer authorization on the destination CMS
NOTE: For database interactions, transferproject assumes the permissions of the StoryServer database user.
Parent Project and Status of Imported Content Items

When templates, records, and files are imported into a project, their workflows arent transferred. As a result, their statuses may differ from their statuses on the source CMS. This table shows how the statuses are set on the destination CMS:
Content Item Record, file, or launchable template Status before Export (on Source CMS) Live Status after Import (on Destination CMS) Live (unless you use the -s option, in which case Live becomes Ready to Launch) Ready To Launch
Record, file, or launchable template Internal use only template
Ready To Launch, Awaiting Final Review, or Working Ready for Internal Use, Awaiting Final Review, or Working
Ready For Internal Use
As the table shows, the status of all imported records, files, and templates (except for internal use only templates) will be either Live or Ready To Launch. If the parent project of the imported project is set to launch content automatically, then all that content will immediately become Live, unless the -s option is used in which case all Live content becomes Ready to Launch. Its advisable to set up a safe parent project when you first begin working with transferproject: a project that isnt set to launch content automatically.
13-34
03/01/99
The autolaunch attribute is set on the General page of the projects Details window: Automatically launch content as soon as workflow completes .
Contents of Project Package

With an export option, transferproject creates a project package that contains several files with different extensions: package-directory-name.attr package-directory-name.file-format package-directory-name.data package-directory-name.purge package-directory-name.sch.syb package-directory-name.sch.inf package-directory-name.sch.mss package-directory-name.sch.ora Two files contain the StoryServer project data: package-directoryname.attr and package-directory-name.file-format, where file-format is tar or zip. If you do not use the -f argument, on Windows NT, the files are saved in zip format by default. On Solaris, the files are saved in tar format by default. Use the -f argument to specify tar on Windows NT, or zip on Solaris. The .attr file must be treated like a binary file. When moving a project package from Solaris to Windows NT, use binary mode. Otherwise, the .attr file will be invalid on Windows NT. This table shows the meaning of each file by extension.
Extension .attr Operation export Description Contains the CMS StoryServer project data for the projects, templates, records, and files in the package. This file is structured like a binary file. Do not edit it, and use binary mode when moving a project package from Solaris to Windows NT. Contains a tar distribution package of the files added to the project as content items. On Solaris, this is the default format. Contains a zip distribution package of the files added to the project as content items. On Windows NT, this is the default format.
.tar
export
.zip
export
03/01/99
13-35
Extension .data
Operation exportData export -r export exportData export -r export exportData export -r export exportData export -r export exportData export -r export exportData export -r export
Description Contains formatted data for the tables identified with exportData or export -r. Contains information for removing the tables specified with exportData or export -r. Empty if export is specified without -r. Contains create table functions in Informix format for installing the tables specified with exportData. Empty if export is specified without -r. Contains create table functions in MS SQLServer format for installing the tables specified with exportData. Empty if export is specified without -r. Contains create table functions in Oracle format for installing the tables specified with exportData. Empty if export is specified without -r. Contains create table functions in Sybase format for installing the tables specified with exportData. Empty if export is specified without -r.
.purge
.sch.inf
.sch.mss
.sch.ora
.sch.syb
If the dist Directory Remains
When creating a project package that includes files, the export operation creates a subdirectory called dist (distribution) under the project package directory. Under the dist directory, it creates an additional directory hierarchy for each file based on the files path. After running tar or zip to complete the project package, the export operation removes the dist directory. Similarly, the import operation recreates the file paths under a dist directory and removes the dist directory when it completes. If the export or import operation is interrupted before it completes, it may not remove the dist directory. If that happens, just remove the directory yourself with the method appropriate for your operating system.
13-36
03/01/99
A
Summary: Audience:
StoryServer Process Reference
A quick reference for processes followed by detailed information for each. Administrators and other users of StoryServer 4.2 Managing StoryServer Processes on Windows NT or Solaris on page 8-1
Process Reference admin (CAS) admin (CMS) bob cmd config ctld expire flushcache inboundmail
launch logroller pad setup ss ted tmd transferproject version vhs
03/01/99
A-1
Process Reference
This appendix contains information on the following StoryServer processes (services) and commands:
Process admin (CAS) admin (CMS) bob cm NT cmd S UN config S UN ctld expire flushcache inboundmail launch logroller S UN pad pznd (not discussed here) setup NT ss ted tmd transferproject version vhs CMS process CAS process Component Settings CAS process Task executable Task executable Task executable Task executable Task executable CAS process CAS process Component Settings Task executable CMS process CAS process CLI Task executable CMS process Dispatches all CMS transactions Cache Manager Configures CAS components Page Generator Expires records, files, or templates Clears pages from a specified location Converts e-mail data into multi-part form data and issues a post to a URL Launches records, files, and templates Archives StoryServer.errors log Placement Agent Observation Manager (See Business Center and Open Profile Services Guide) Configures CAS components Starts the launch bar for the UI on the chosen operating system Event Service Template Manager Transfers project info from one CMS to another Creates, names, restores, or deletes versions of files, records, or templates Request Service Type CLI Description Lets you check or change state of a CAS or CMS process
A-2
03/01/99
admin (CAS)
Lets you check or change the state of CAS processes.
Synopsis
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n \host-port- number\admin.bat [start | stop]
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/admin [reset | start | status | stop | verify | updatepe | update_pmcfg]
Description
The CAS admin command-line interface lets you start and stop (on Solaris also reset, verify, and obtain status for) all StoryServer processes associated with host-port-number, which specifies the web server for the CAS. On Solaris, the update subcommands (updatepe and update_pmcfg) let you synchronize configuration files for the CMS and CAS(s). You must have system admin user privileges on the host where the CAS is installed to use the reset, start, stop, updatepe, and update_pmcfg subcommands. For information on file location variables, see Common Path Name Variables on page 1-5.
Subcommands
reset S UN Resets the CAS processes as follows: ctld (Page Generator) - rereads the configuration files tmd (Template Manager) - removes the current template cache and generates a new one.
03/01/99
A-3
start Restarts the processes for the CAS. (It stops and then starts the processes.) status S UN Returns status on all CAS processes. stop Stops all CAS processes. Use /install-path/StoryServer/Rn/conf/host-port-number/admin start or the Start menu options to start the CAS processes again. verify S UN Verifies that the current StoryServer version matches the installed version and returns status, including any files that have been modified since the package was installed. updatepe S UN Updates the CMS with configuration information from the CAS config file:
update_pmcfg S UN Updates the remotely installed CAS with configuration information from the CMSs /install-path/StoryServer/Rn/conf/Production/pm.cfg file. If more than one CAS accessing the same remote CMS are installed on a host, you can run admin update_pmcfg from just one CAS. The new local /conf/Production/pm.cfg file will serve for all the CASs installed on that host and accessing the same CMS. NOTE: Using update_pmcfg on a non-remote CAS has no effect.
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\Production\pm.cfg
CMS configuration file

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\StoryServer.cfg
CAS configuration file
A-4
03/01/99
Solaris

CAS configuration file

/install-path/StoryServer/Rn/bin/solaris/ssde
Internal file
admin (CMS)
Lets you check or change the state of a CMS.
Synopsis
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\Production\admin.bat [start | stop]
Solaris
/install-path/StoryServer/Rn/conf/Production/admin [start | status | stop]
Description
The CMS admin command-line interface lets you start and stop (and obtain status on Solaris) for the CMS, the location of which is noted in the pm.cfg file. To use the start and stop subcommands, you must have system admin user privileges on the host where the CMS is installed. For information on file location variables, see Common Path Name Variables on page 1-5.
03/01/99
A-5
Subcommands
start Starts all processes (services) in the CMS. Enables communication with the StoryServer database. status S UN Returns status on all processes of the CMS. stop Stops all processes in the CMS. Use the CMSs admin start to start the CMS processes and enable communication with the StoryServer database again.
Files
Windows NT

Solaris

/install-path/StoryServer/Rn/bin/solaris/sspm
Internal file
bob
Dispatches all CMS transactions.
Windows NT Service Name

Vignette 4.2 Dispatch Service
A-6
03/01/99
Description
All CMS services communicate through this main CMS process. On Windows NT, if both the CMS and the database are running on the same host, the Dispatch Service must start after the database service. For information on service dependencies, see Establishing Service Dependencies for CMS/CASWindows NT only on page 9-2. For information on file location variables, see Common Path Name Variables on page 1-5.
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\attr.exe
Internal command
\install-path\StoryServer n\Engines\Rn\bin\winnt\auth.exe
Internal command
\install-path\StoryServer n\Engines\Rn\bin\winnt\bblast.exe
Internal command
\install-path\StoryServer n\Engines\Rn\bin\winnt\bsend.exe
Internal command
\install-path\StoryServer n\Engines\Rn\bin\winnt\pmcmd.exe
Internal command
\install-path\StoryServer n\Engines\Rn\bin\winnt\ted.exe
Timed-event service
\install-path\StoryServer n\Engines\Rn\bin\winnt\vhs.exe
Request-handling service
\install-path\StoryServer n\Engines\Rn\conf-n\Production\pm.log
Audit log for the main CMS service
03/01/99
A-7
Solaris
/install-path/StoryServer/Rn/bin/solaris/attr
Internal command
/install-path/StoryServer/Rn/bin/solaris/auth
Internal command
/install-path/StoryServer/Rn/bin/solaris/bblast
Internal command
/install-path/StoryServer/Rn/bin/solaris/bsend
Internal command
/install-path/StoryServer/Rn/bin/solaris/pmcmd
Internal command
/install-path/StoryServer/Rn/bin/solaris/ted
Timed-event process
/install-path/StoryServer/Rn/bin/solaris/vhs
Request-handling process
/install-path/StoryServer/Rn/conf/Production/pm.log
Audit log for the main CMS process
cmd
(cm on Windows NT) The CAS process which maintains cached content.

Vignette 4.2 Cache Manager
Description
The Cache Manager process maintains stable pages or information in a cache so that only dynamic information needs to be generated from the database.
A-8
03/01/99
For information on file location variables, see Common Path Name Variables on page 1-5. There is one Cache Manager process in a CAS.
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\cmd.log
Audit log for Cache Manager service

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\metafiles
Directory where the different variations are stored for templates

Solaris
/install-path/StoryServer/Rn/conf/host-port-number/cmd.log
Audit log for Cache Manager process

/install-path/StoryServer/Rn/conf/host-port-number/cmd.pid
ID file for the Cache Manager

/install-path/StoryServer/Rn/conf/host-port-number/metafiles
Directory where the different variations are stored for templates
config
Configures StoryServer system components (Solaris only).
Synopsis
Description
This interactive script enables you to configure a StoryServer CMS or a StoryServer CAS and update or delete the Vignette demonstration projects on
03/01/99
A-9
Solaris. For more information, see Managing StoryServer on Windows NT and Solaris on page 9-1. An example location would be:
/opt/StoryServer/R4.2/adm/config
For information on file location variables, see Common Path Name Variables on page 1-5. For information on using this command, see Platform Installation & Configuration Guide (printed copy shipped with product). You must have system admin user privileges to run this command.
Files
/install-path/StoryServer/Rn/adm/lastsession.cfg
Internal file
/install-path/StoryServer/Rn/adm/sql/
Directory containing general database files and files used for initialization during configuration
/install-path/StoryServer/Rn/adm/dbfuncs.sh
Internal file
/install-path/StoryServer/Rn/adm/instfuncs.sh
Internal file
/install-path/StoryServer/Rn/adm/modules.sh
Internal file
/install-path/StoryServer/Rn/adm/pmfuncs.sh
Internal file
/install-path/StoryServer/Rn/adm/remfuncs.sh
Internal file
/install-path/StoryServer/Rn/adm/sysfuncs.sh
Internal file
/install-path/StoryServer/Rn/adm/updfuncs.sh
Internal file
A-10
03/01/99
/install-path/StoryServer/Rn/adm/wsfuncs.sh
Internal file
ctld
The CAS process which interprets templates, accesses content, and generates web pages on demand by viewers on the World Wide Web.

Vignette 4.2 Page Generator
Description
The Page Generator process is one of a pool of slave processes that generate page content from the database. The first process controls the slave processes that it spawns. For information on file location variables, see Common Path Name Variables on page 1-5. For this process, the reset option in the Configuration Manager (or the /install-path/StoryServer/Rn/bin/solaris/admin reset command on Solaris) causes this process to reread the following files, but also note that these files are reloaded every time that ctld is called, for example whenever a dynamic or non-cached page is viewed via the web.
NT
\install-path\StoryServer n\Engines\Rn\conf-n\delivery.tcl \install-path\StoryServer n\Engines\Rn\lib\stdlib.tcl \install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\StoryServer.cfg
S UN
/install-path/StoryServer/Rn/conf/delivery.tcl /install-path/StoryServer/Rn/lib/stdlib.tcl /install-path/StoryServer/Rn/conf/host-port-number/StoryServer.cfg
03/01/99
A-11
There is one Page Generator master process in a CAS. By default, the master process can create up to 8 slave processes (for a total of 9 Page Generator processes per CAS). For information on changing the number of slave processes, see one of the following:
Increasing Page Generator Requests on Windows NT on page 11-5 Increasing Page Generator Requests on Solaris on page 12-2
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\lib\stdlib.tcl
Library used by Page Generator

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\ctld.log
LOG command error log for the Page Generator service

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\ctld.log.id
LOG command error log for the slave process with the id number
\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\ctldinfo.log
Audit log for the master process

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\ctldinfo.log.id
Audit log for the slave process with the id number

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\templates\
Template cache that contains files shared by the Template Manager and Page Generator services
Solaris
/install-path/StoryServer/Rn/lib/stdlib.tcl

/install-path/StoryServer/Rn/conf/host-port-number/ctld.log
Database error log for the Page Generator process

/install-path/StoryServer/Rn/conf/host-port-number/ctld.log.id
Database error log for the slave process with the id number
A-12
03/01/99
/install-path/StoryServer/Rn/conf/host-port-number/ctld.pid
Process ID file for the Page Generator

/install-path/StoryServer/Rn/conf/host-port-number/ctldinfo.log.id
Audit log for the slave process with the id number

/install-path/StoryServer/Rn/conf/host-port-number/templates/
Template cache that contains files shared by the Template Manager and Page Generator processes
expire
An executable for expiring records, files, or templates
Synopsis
Windows
\install-path\StoryServer n\Engines\Rn\taskbin\winnt\expire.exe [-r] (project_mgmt_id | ci_mgmt_id)
Solaris
/install-path/StoryServer/Rn/taskbin/solaris/expire [-r] (project_mgmt_id | ci_mgmt_id)
Description
The expire command is used primarily as a program task in the Task Manager or Project Manager. Typically, its used for scheduled expiration of previously launched records, files, and templates, although it can be used to expire items regardless of their state. The expire command is available only at the project task level, and only the project owner can expire records, files, and templates in that project. The owner can expire content in a projects top level, or use the -r flag to expire all subprojects recursively down through an entire project hierarchy. The project owner can also expire individual content or subprojects by specifying the management IDs of the items. When the project task is created,
03/01/99
A-13
the Task Manager or Project Manager lets you schedule one or more times for the expiration to occur. For information on using the Task Manager or Project Manager to create a task to issue the expire command, see the Production Center Guide. For information on file location variables, see Common Path Name Variables on page 1-5.
Options
-r Recursively expires all records, files, and templates through all subprojects and at the top project level. project_mgmt_id | ci_mgmt_id The management ID for the project or content. item. You can find this ID in the Management ID field of the Misc page of the project, record, file, or template Details window.
Example
Almost all the options of the expire command are handled by selections in the Production Center tools. This example, however, specifies individual subprojects (by project_mgmt_id) and templates, records, or files (by ci_mgmt_ids) in a program task for a project-level expiration:
expire /pr/106 /ci/21d /ci/404g /ci/783f
NOTE: The forward slash (/) is part of the id, not a path, and should be used whether specifying the task for a Windows NT or Solaris-based engine. If these were all of the items in the project, the entire project could be expired instead. This example shows how a subset of the items in a project (perhaps even at different levels of the project) can be expired.
flushcache
Clears pages from a specified location.
A-14
03/01/99
Synopsis
Windows NT
\install-path\StoryServer n\Engines\Rn \taskbin\winnt\flushcache.bat host port path ...
Solaris
/install-path/StoryServer/Rn /taskbin/solaris/flushcache host port path ...
Description
The flushcache command is used primarily as a Task Manager or Project manager program task. It clears pages from one or more specified paths within a CAS web servers document cache on a specified host. After you make changes to a set of content that appears in cached pages, you can use the flushcache command to flush (delete or rename) previously generated pages from the cache so users can access the new content. You set the action of the flushcache command (that is, whether it renames the cached pages or removes them from the cache) for each CAS in its StoryServer.cfg file CMD_ACTION variable. The default is RENAME, which provides a renamed, backup file for delivery to the web site if the new page isnt generated for some reason. To have flushcache remove cached pages from the cache, change the value to DELETE. For information on changing values in the configuration file on Windows NT, see Editing the Configuration Files on Windows NT on page 11-2. On Solaris, use your preferred editor to open the CASs StoryServer.cfg file. The Task Manager or Project Manager also lets you repeat the command at intervals you specify. For information on using the Task Manager or Project Manager to issue the flushcache command, see Production Center Guide. For information on file location variables, see Common Path Name Variables on page 1-5. NOTE: The flushcache command works in the same way as the StoryServer template command CLEAR_CACHE. For more information on using CLEAR_CACHE, see Template Fundamentals.
03/01/99
A-15
NOTE: Do not use the flushcache command to clear pages after you expire a template. You must manually delete cached pages related to a template you expire.
Options
host Specifies the host where the web server whose document root you want to clear is running. port Specifies the port number for the Cache Manager in the CAS associated with the web server document root. path Specifies the directory relative to the document root containing the pages you want to clear
Example
The following examples show flushcache used in the Task Manager or Project Manager Program task field. It clears pages from the /OurSite/Books directory in the document root for the web server whose Cache Managers port is 13625, on system sysA.
flushcache sysA 13625 /OurSite/Books
NOTE: The forward slash (/) is part of the id, not a path, and should be used whether specifying the task for a Windows NT or Solaris-based engine.
inboundmail
A task executable which converts e-mail data into multi-part form data and then issues a multi-part form post to a specified URL, after which the mail will be deleted from the mail server if the post succeeds.
A-16
03/01/99
Synopsis
Windows NT
\install-path\StoryServer n\Engines\Rn\taskbin\winnt \inboundmail.exe -mailserver mail-host -mailport port -maillogin account-name -mailpassword password -webserver web-domain -webport port -url target-template -namelist post-section1 [post-section2 ...] -debug
Solaris
/install-path/StoryServer/Rn/taskbin/solaris /inboundmail -mailserver mail-host -mailport port -maillogin account-name -mailpassword password -webserver web-domain -webport port -url target-template -namelist post-section1 [post-section2 ...] -debug
Description
In order to read e-mail, inboundmail communicates with mail servers through POP3 protocol that is supported by popular servers including Microsoft Exchange Server 5.5. Once e-mail is read it converts the e-mail data into multi-part form data and then issue a multi-part form post to a specified URL, after which the mail is deleted from the mail server if the post succeeds. In the current implementation, inboundmail will support only multipart/mixed and plain/text e-mail. Most likely, you will want to schedule inboundmail as a repeating program task. See "Working with Program Tasks" in the Production Center Guide.
03/01/99
A-17
Options
-mailserver mail-host This parameter identifies the address of the mail server. For example, mail.argonaut.com. -mailport port This parameter identifies the port at which the mail server is available. This is an optional parameter and its default value is 110. For example, 6578. -maillogin account-name This parameter identifies the login for the mail account that is present in the mail server. For example, newsbot. -mailpassword password This parameter identifies the password associated with the mail account present in the mail server. The parameter is an encrypted form of the password and not the real one. The user must use the encrypt program that comes with StoryServer to obtain the encrypted form from the actual password. For example, 73^%4a547. -webserver web-domain This parameter identifies the web server associated with the CAS that will execute the template that processes the mail message. For example, www.argonaut.com. -webport port This parameter identifies the port at which the web server is available. This is an optional parameter and its default valuse is 80. For example, 8000. -url target-template This parameter identifies the url corresponding to the template that is the target of the form post. For example, /Jason/Fleece/1,1443,,00.html. -namelist post-section1 [post-section2 ...] This parameter identifies the names corresponding to each of the parts of the multi-part message. Each of the names determine the variable names through which the form data will be available to the target template. For example, "details" "comments".
A-18
03/01/99
If there are more parts than the names specified then the parts that do not have a name will be named part-#. For example if there are 3 parts and only one name was specified, the 2nd and 3rd parts will be named part-2 and part-3 respectively. -debug This parameter determines if debug messages are printed. This is an optional parameter.
Example
inboundmail -mailserver mail.argonaut.com -mailport 6578 -maillogin newsbot -mailpassword 73^%4a547 -webserver www.argonaut.com -webport 443 -url /Jason/Fleece/1,1443,,00.html -namelist \"details\"" \"comments\"" -debug
launch
Launches records, files, and templates, making them visible on all live CASs. (Templates designated for internal use only are not launched.)
Synopsis
Windows NT
\install-path\StoryServer n\Engines\Rn\taskbin\winnt\launch.exe [-r] (project_mgmt_id | ci_mgmt_id)
Solaris
/install-path/StoryServer/Rn/taskbin/solaris/launch [-r] (project_mgmt_id | ci_mgmt_id)
Description
The launch command is used primarily as a Task Manager or Project Manager program task. It launches records, files, and templates to all live
03/01/99
A-19
CASs associated with the CMS. (Internal-use-only templates are not launched, but become available for internal use when their workflow completes.) The launch command is available only at the project task level, and only the project owner can launch records, files, and templates in that project. The project owner can explicitly launch content in only the top level or use the -r flag to launch all subprojects recursively down through the entire project hierarchy. The project owner can also launch individual content or subprojects by specifying the management IDs of the items. The Task Manager or Project Manager lets you set a timed, repeatable launch that operates on all items in Ready to Launch state. For information on using the Task Manager or Project Manager to issue the launch command, see Production Center Guide. For information on file location variables, see Common Path Name Variables on page 1-5.
Options
-r Recursively launches all records, files, and templates that are available to be launched through all subprojects and at the top project level. project_mgmt_id | ci_mgmt_id The management ID for the project or content. You can find this ID in the Management ID field of the Misc page of the project, record, file, or template Details window.
Example
Almost all the options of the launch command are handled by selections in the Task Manager or Project Manager. In this example, you specify individual subprojects (project_mgmt_id) and templates, records, or files (ci_mgmt_ids) in a program task for a project-level launch, where you can also set a Repeat command:
launch /pr/106 /ci/21d /ci/404g /ci/783f
NOTE: The forward slash (/) is part of the id, not a path, and should be used whether specifying the task for a Windows NT or Solaris-based engine.
A-20
03/01/99
If these were all of the items in a single project, the entire project could be launched instead. This example shows how items in different levels of a project can be launched separately from other items in the project.
logroller
Archives the StoryServer.errors log (Solaris only).
Synopsis
/install-path/StoryServer/Rn/taskbin/solaris/logroller [-c] [-s srcdir] [-d destdir] [-f file1 file2 ...]
Description
The /installpath/StoryServer/Rn/taskbin/solaris/logroller command is used primarily as a Task Manager or Project Manager program task. It archives the StoryServer.errors file, updated by the system logger, syslogd, and typically stored in /var/adm. The Task Manager or Project Manager also lets you repeat the command at intervals you specify. For information on using the Task Manager or Project Manager to issue the logroller command, see Production Center Guide. For information on file location variables, see Common Path Name Variables on page 1-5. The syslogd must be running where StoryServer is installed for logroller to work. The logroller command does not interfere with loggingno messages are lost when it runs.
Options
c Specifies that a copy of the log is made in the destination directory and the log is not cleared to 0 (zero) length. The default is to move the log to the destination directory, then clear the original log.
03/01/99
A-21
s Specifies the source directory (srcdir) if other than /var/adm, the default. d Specifies the destination directory (destdir) if other than /var/adm, the default. f Specifies the name for the archived file (file), if other than StoryServer.errors, the default.
Exit Statuses
0 Successful completion 101 Usage error 102 Source directory is invalid. 103 Destination directory is invalid. 104 User must have system admin privileges. 105 No syslogd is running.
Examples
Simply entering logroller in the Task Manager or Project Manager Program task text field uses the logroller defaults. It does the following:
1 2
Renames the /var/adm/StoryServer.errors log file to /var/adm/StoryServer.error.timestamp Reinitializes the /var/adm/StoryServer.errors log file
A-22
03/01/99
Sends a signal to restart syslogd.
The next example, also as entered in a Program task, leaves the original log file untouched and puts the archive copy in the directory /archive/var/StoryServer:
logroller -c -d /archive/var/StoryServer
Files
/usr/sbin/syslogd
System process that transmits error messages and warnings from StoryServer processes to StoryServer log files
/var/adm/StoryServer.errors
Default log file for high-level error messages and warnings from StoryServer processes
/var/adm/syslog
System log file
pad
The CAS process which deploys static content when needed for web page generation.

Vignette 4.2 Placement Agent
Description
The Placement Manager controls a pool of slave processes that deploy static content that cannot be stored in the database and makes it available for use when a web page is generated. For information on file location variables, see Common Path Name Variables on page 1-5. There is one Placement Manager master process in a CAS. By default, the master process can create up to 8 slave processes (for a total of 9 Placement
03/01/99
A-23
Manager processes per CAS). For information on changing the default, see one of the following:
Increasing Request Handling on Windows NT on page 11-11 Increasing Request Handling on Solaris on page 12-8
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\pad.log
Audit log for Placement Manager service

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\pad.log.id
Audit log for Placement Manager slave process having the id number
\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\PadWorkDir
Directory for Placement Manager working files

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\PadArchiveDir
Directory for last version of replaced or deleted static files

Solaris
/install-path/StoryServer/Rn/conf/host-port-number/pad.log
Audit log for Placement Manager process

/install-path/StoryServer/Rn/conf/host-port-number/pad.log.id
Audit log for Placement Manager slave process having the id number
/install-path/StoryServer/Rn/conf/host-port-number/pad.pid
Process ID file for the Placement Manager process

/install-path/StoryServer/Rn/conf/host-port-number/PadArchiveDir
Directory for last version of replaced or deleted static files
setup
StoryServer Platform Configuration Program
A-24
03/01/99
Configures StoryServer system components (Windows NT only).
Synopsis
\install-path\StoryServer n\Engines\Rn\adm\config\setup.exe
Description
This interactive program allows you to add, remove, or update a CAS or CMS and lets you add or remove a Vignette demonstration project. For information on file location variables, see Common Path Name Variables on page 1-5. An example location would be:
D:\Program Files\Vignette\StoryServer n\Engines\Rn\adm\config\setup.exe
For information on using this program, see Platform Installation & Configuration Guide (printed copy shipped with product). You must have system admin user privileges to run this program.
Files
\install-path\StoryServer n\Engines\Rn\bin\isconfig.dll
Internal file
\install-path\StoryServer n\Engines\Rn\adm\sql\
Directory containing general database files and files used for initialization during configuration
ss
Starts the StoryServer launch bar for the user interfaces on the chosen operating system.
03/01/99
A-25
Synopsis
Windows NT
\install-path\StoryServer n\Clients\Rn\bin\ss.exe [-b host[:port] [-u username[:password]] [-s host:port] [-nosplash] [-nolazy] [-homeDir path] [-vgnDir path]
Solaris
/install-path/StoryServer/Rn/ui/bin/ss [-b host[:port] [-u username[:password]] [-s host:port] [-nosplash] [-nolazy] [-homeDir path] [-vgnDir path]
Description
The \install-path\StoryServer n\bin\ss.exe command starts the StoryServer launch bar for the user interfaces on Windows (/install-path/StoryServer/Rn/ui/bin/ss on Solaris). For information on file location variables, see Common Path Name Variables on page 1-5. NOTE: If the StoryServer CMS has Self-registration set to Yes, you can start the StoryServer launch bar without a valid user name. In the Login window, you can enter a new user name and a password that are then maintained in the StoryServer database. The new user name is not associated with any groups, however; an admin user must use the User/Group Manager to add the user name to one or more groups as needed. For information on Self-registration, see Enabling Self-registration on page 5-6. For information on adding a user to groups, see Adding a Group Entry on page 5-13.
Options
-b host[:port] Specifies the name, and optionally the port number, of the host for the CMS you want to access with the StoryServer session. The default value for port
A-26
03/01/99
is 50202. This option overrides the default you may have previously stored in your Preferences file. For example: -b titan:37000 -u username[:password] Specifies a user name and password known to the StoryServer CMS. If you dont specify a password, the StoryServer Login window opens with the user name and a field for the password to be entered. This option overrides the default you may have previously stored in your Preferences file. For example:
-u farley
-s shost:sport Specifies the fully qualified host name and port number of the SOCKS proxy host to be used by the StoryServer session behind a firewall. For example: -s khan.myco.com:8100 -nosplash Opens the application without the splash screen. -nolazy Constructs all primary window panes on application start rather than as raised with tabs. -homeDir path Specifies the directory where the StoryServer session will create a temporary directory and the directory thats listed first when you select files.The default is the home directory of the user who starts the session. The home directory is determined as follows:
S UN %HOME NT %HOME% or %HOMEDRIVE%HOMEPATH%
For example: NT -homeDir D: S UN -homeDir /u/angus/myStory
03/01/99
A-27
NOTE: On Macintosh, temporary files are written to the /Macintosh HD/System Folder/Preference/vgntemp directory. -vgnDir path Specifies the subdirectory of -homeDir where the StoryServer session will write your Preferences file.The default for Windows is Vignette. The default for Solaris is .vgn. For example:
-vgnDir myplace
Examples
Windows NT
For information on changing the StoryServer startup, see the section on starting with options in Running StoryServer Tools.
Solaris
You can start the StoryServer launch bar on Solaris with several options.
To specify the user name and be prompted for the password
/mypath/StoryServer/Rn/ui/bin/ss -u farley
To specify only the CMS you want to access:

/mypath/StoryServer/Rn/ui/bin/ss -b archie:9090
To specify a host, user name, and that StoryServer use a specific directory
for the Preferences file and open without a splash screen (shown as multiple lines, but must be one line on the command line):
/mypath/StoryServer/Rn/ui/bin/ss -b archie -u farley -nosplash -vgnDir /myhome/myVGN
A-28
03/01/99
Files
Windows NT
\install-path\StoryServer n\Clients\Rn\lib \install-path\StoryServer n\Clients\Rn\java\bin \install-path\StoryServer n\Clients\Rn\java\lib
Solaris
/install-path/StoryServer/Rn/ui/lib /install-path/StoryServer/Rn/ui/java/bin /install-path/StoryServer/Rn/ui/java/lib
ted
Tracks timed events for the main CMS process.

Vignette 4.2 Event Service
Description
The ted process tracks scheduled events for the CMS. For information on file location variables, see Common Path Name Variables on page 1-5.
03/01/99
A-29
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\bob.exe
Main CMS service

\install-path\StoryServer n\Engines\Rn\conf-n\Production\ted.log
Audits transactions and errors for the timed event service

\install-path\StoryServer n\Engines\Rn \conf-n\Production\TedTasksWorkingDirsRoot\
Directory for files being processed by ted.exe

Solaris
/install-path/StoryServer/Rn/bin/solaris/bob
Main CMS process

/install-path/StoryServer/Rn/conf/Production/ted.log
Audits transactions and errors for the timed-event process

/install-path/StoryServer/Rn/taskbin/solaris/TasksWorkingDirsRoot\
Directory for files being processed by ted.exe
tmd
The CAS process which manages templates.

Vignette 4.2 Template Manager
Description
The Template Manager checks whether any templates have been revised and updates the Page Generator. You can also tell the Template Manager to make new templates available at any time.
A-30
03/01/99
For information on file location variables, see Common Path Name Variables on page 1-5. There is one Template Manager process in a CAS. For this process, the reset option in the Configuration Manager (or the /install-path/StoryServer/Rn/bin/solaris/admin reset command on Solaris) removes the current template cache and generates a new one.
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\tmd.log
Audit log for the Template Manager process

Solaris
/install-path/StoryServer/Rn/conf/host-port-number/tmd.log

/install-path/StoryServer/Rn/conf/host-port-number/tmd.pid
Process ID file for the Template Manager process

transferproject
Moves project content and project information from one CMS to another.
03/01/99
A-31
Description
If your company has multiple StoryServer Content Management Servers (CMSs), you may need at times to transfercopya project from one CMS to another. The transferproject command, available at the CMS command line, allows you to perform the transfer. See Transferring Projects between Content Management Servers on page 13-1.
Options
-o operation Required. The transfer operation: export, import, delete, exportData, importData, deleteData, exportForm, or importForm. delete Operation that deletes StoryServer project data. deleteData Operation that deletes database content based on the instructions in the .purge file in the project package created by a previous exportData or export -r operation. export Operation that exports StoryServer project data into a project package, putting the data into a file with the extension .attr and a file with the extension .tar or .zip. (Although schema files appear in the project package, the files are empty.) exportData Operation that exports database content (tables specified with the -t option) into a project package, putting the content and schema into a file with the extension .data, a file with the extension .purge, and set of schema files (one for each database type). exportForm Operation that exports one or more form sets (specified with the -t option) from the Content Designer into a project package containing a single file
A-32
03/01/99
with the extension .attr_fs. (For use with StoryServer Development Center.) NOTE: If a form set has been committed in the Content Designer on the source CMS, the same form set will have to be committed again after it is imported into the destination CMS so that new tables and templates can be generated. For more information, see Template Fundamentals. import Operation that imports StoryServer project data from the .attr file and the .tar or .zip file in the project package. importData Operation that imports database content from a project package, taking the content from the schema file that corresponds to the destination projects database type. importForm Operation that imports one or more form sets (from a file with the extension .attr_fs in the project package) into the destination CMS. (For use with StoryServer Development Center.) NOTE: If a form set has been committed in the Content Designer on the source CMS, the same form set will have to be committed again after it is imported into the destination CMS so that new tables and templates can be generated. For more information, see Template Fundamentals. -b destCMhost:port:projID Required with the import operation. The host and port of the CMS into which to import the project, and the StoryServer management ID of the project under which to put the imported project. Example: -b whitman:32000:/pr/65 -b destCMhost:port Required with the importData operation. The host and port of the CMS to which to import the database content. (A project ID, if included, is ignored.) Example: -b whitman:32000 -b sourceCMhost:port:projID Required with the export operation. The host and port of the CMS from which to export the project, and the StoryServer management ID of the project to export. Example: -b thoreau:7623:/pr/24
03/01/99
A-33
-b sourceCMhost:port Required with the exportData operation. The host and port of the CMS from which to export the database content. (A project ID, if included, is ignored.) Example: -b thoreau:7623 -f file-format Optional with the export operation. Specifies the format in which the export operation packages the files that the project contains (that is, content items added to the project as files). If you do not use the -f argument, on Windows NT, the files are saved in zip format by default. On Solaris, the files are saved in tar format by default. Use the -f argument to specify tar on Windows NT, or zip on Solaris. Example: -f tar -k Optional with the importData and deleteData operations. Forces the operation to continue despite any errors that arise when importData processes the schema file or data file or when deleteData processes the purge file. -l SSusername:password Required with all operations. For export operations: StoryServer user name and password that are valid on the source CMS. Example: -l pjames:m1stry7 For import and delete operations: StoryServer user name and password that are valid on the destination CMS (and have the required authorization for the operation). Example: -l codger:gor18dita -p projPackageDir Required. The directory that contains the project package files. Example: -p /opt/ss/xfers -r Optional with the export operation. Exports the database content corresponding to the exported records (that is, the exported tables will contain only the content rows for which records exist in the project). -t "table-list" Required with the exportData operation. The names of one or more tables from which to export rows, separated by spaces. If the list includes
A-34
03/01/99
more than one table, it must be enclosed in double quotation marks. The tables must be in the source CMSs StoryServer system database. -t "form set-list" Required with the exportForm operation. The names of one or more form sets from the Content Designer. Enclose the form set names in quotes, separated by commas. -s Optional with import. If an items status is Live on the source CMS, -s sets the status to Ready to Launch on the destination CMS. -z option Optional with import. Specifies how to handle object conflicts on import:
-z 0 Dont transfer any objects if there is a single conflict (default
behavior).
-z 1 Dont transfer any objects which conflict, but transfer the rest of
the objects in the project package.

-z 2 Replace conflicting target objects with source object data. -z 3 Like -z 2, but version conflicting target objects before updating.
See -n below. -n Optional with the -z 3 option. Specifies the name of the version created if object conflicts occur. -v Optional with any operation. Specifies verbose mode. -? Displays a usage statement.
version
Creates, names, restores, or deletes a version of records, files, or templates
03/01/99
A-35
Synopsis
Windows
\install-path\StoryServer n\Rn\taskbin\winnt\version.exe [-o version operation] [-n version name] [-r] (project_mgmt_id | ci_mgmt_id)
Solaris
/install-path/StoryServer/Rn/taskbin/solaris/version [-o version operation] [-n version name] [-r] (project_mgmt_id | ci_mgmt_id)
Description
The version command is used primarily as a program task in the Task View or Project Manager. The version command is available at the project and workflow task level. Any user authorized to work on a record, file, or template can also version it while performing a task on that asset. A content owner can create versions of her own files, records, or templates at any time. A task owner can do so while performing a task on the specific file, record, or template. A project owner can version assets (content items) in a projects top level, or use the -r flag to version assets in all subprojects recursively down through an entire project hierarchy. The project owner can also version individual assets or subprojects by specifying the management IDs of the items. When the project task is created, the Task View or Project Manager lets you schedule one or more times for the version task to occur. For information on using the Task View or Project Manager to create a task to issue the version command, see the Production Center Guide. For information on file location variables, see Common Path Name Variables on page 1-5.
A-36
03/01/99
Options
-o version operation You must specify targets for these operations using the list of content items from the specified project_mgmt_id, ci_mgmt_id, or recursively by using the -r flag. Supported version operations include: saveAll Create a version for every content item (ci) object found in the list of content items from the specified project_mgmt_ids and ci_mgmt_ids, whether previously versioned or not (-n version name optional). NOTE: Consider the impact before using this option with the -r flag. saveExisting Create a version only for those content items that have already been versioned (-n version name optional). restore Restore the specified version (must also specify -n version name). name Attach the specified name to the current version (must also specify -n version name). A specific name can attached to only one version at a time. If you attach the same name to another version, the name is moved from the version that previously had the name. (maximum 128 characters, including spaces) delete Delete the specified version (must also specify -n version name). -n version name Specifies the name of the version on which you want to operate. If spaces are included in the name, put double quotation marks around the name: for example, "vacation days". Required for the restore, name, and delete operations. -r Recursively performs a version operation all records, files, and templates through all subprojects and at the top project level.
03/01/99
A-37
project_mgmt_id | ci_mgmt_id The management ID for the project or content. You can find this ID in the Management ID field of the Misc page of the project, record, file, or template Details window.
Defaults
StoryServer provides some defaults when you invoke a version program task.
For a Workflow
When you use the simple version program task in a workflow (that is, version or version -r with no arguments), whether a project workflow or a single content item (asset) workflow, StoryServer uses the following implicit information:
The host and port for the CMS to which youre currently connected The authorization that your current login has been given The -o saveAll option, which creates a version for the asset whether it
has been versioned previously or not

The current content item ID is also supplied
When you select or type simply version in a workflow, the program task is expanded internally to this when it is invoked:
version -b host:port -c creds -o saveAll /ci/ci_mgmt_id
For a Project
When you invoke the version program task at the project level (as previously, simply version or version -r with no arguments), StoryServer uses the following implicit information:
The host and port for the CMS to which youre currently connected The authorization that your current login has been given The -o saveExisting option, which creates a version for those
content items in the project which have been versioned previously

The current project ID
A-38
03/01/99
When you select or type simply version in a project-level task, the program task is expanded internally to this:
version -b host:port -c creds -o saveExisting /pr/project_mgmt_id
If you want different operations or targets, you must specify them. For example, if you want to save a version of all the content items in specific subproject and content ID lists, you would enter this:
version -o restore -n "my ver" /pr/project_mgmt_id /ci/ci_mgmt_id
while the internally expanded program task would look like this:
version -b host:port -c creds -o restore -n "my ver" /pr/project_mgmt_id /ci/ci_mgmt_id
When a project owner sets Automatically save a version of content when launched in the Project Details window, the Project Manager creates a version of the records, files, or templates in the project when they are launched, whether they were previously versioned or not.
Example
This example specifies individual projects (by project_mgmt_id) and
templates, records, or files (by ci_mgmt_ids) in a program task for creating a project-level version with the name real stuff:
version -o name -n realstuff /pr/106 /ci/21d /ci/404g /ci/783f
NOTE: The forward slash (/) is part of the id, not a path, and should be used whether specifying the task for a Windows NT or Solaris-based engine. If these were all of the items in the project, the entire project could be versioned instead. This example shows how a subset of the items in a project (perhaps even at different levels of the project) can be versioned.
In the next example, the restore option is applied to the content items
that have the real jazzy name in the /pr/106 project and /ci/783f content items.
version -o restore -n "real jazzy" /pr/106 /ci/783f
In the last example, the -r flag recursively makes a version of each
previously versioned record, file, and template in the /pr/14 project.

version -o saveExisting -r /pr/14
03/01/99
A-39
vhs
Manages requests for the CMS.

Vignette 4.2 Request Service
Description
The vhs process manages requests for the CMS. For information on file location variables, see Common Path Name Variables on page 1-5. There is one master request service in a CMS. By default, the master service can create up to 8 slave processes (for a total of 9 request-handling processes per CMS). For information on changing the default, see one of the following:
Increasing Request Handling on Windows NT on page 11-11 Increasing Request Handling on Solaris on page 12-8
Files
Windows NT
Main CMS service

\install-path\StoryServer n\Engines\Rn\conf-n\Production\vhs.log
Audit log for the request-handling service

\install-path\StoryServer n\Engines\Rn\conf-n\Production\vhs.log.id
Audit log for request-handling slave process having the id number

\install-path\StoryServer n\Engines\Rn\conf-n\Production\VhsProtoDocRoot
Directory for request-handler working copy of the static files that have been processed
A-40
03/01/99
Solaris
Main CMS process

/install-path/StoryServer/Rn/conf/Production/vhs.log
Audit log for the request-handling process

/install-path/StoryServer/Rn/conf/Production/vhs.log.id

Directory for request-handler working copy of the static files that have been processed
03/01/99
A-41
A-42
03/01/99
B
Summary: Audience:
StoryServer File Reference
A quick reference for files and directories followed by detailed information for each. Administrators and other users of StoryServer 4.2 Managing StoryServer Files on Windows NT or Solaris on page 6-1
File Reference cmd.log cmd.pid ctld.log ctld.log.id ctld.pid ctldinfo.log ctldinfo.log.id delivery.tcl docroot lastsession.cfg macrodata metafiles obj.conf PadArchiveDir pad.log pad.log.id
pad.pid PadWorkDir plugin.log pm.cfg pm.log Preferences StoryServer.cfg StoryServer.errors TasksWorkingDirsRoot ted.log templates tmd.log tmd.pid vhs.log vhs.log.id VhsProtoDocRoot
03/01/99
B-1
File Reference
This appendix contains information on StoryServer files. NOTE: Information about executable files can be found in StoryServer Process Reference on page A-1.
File or Directory name cmd.log cmd.pid S UN ctld.log ctld.log.id ctld.pid S UN ctldinfo.log Type Log file Process ID file Log file Log file Process ID file Log file Description Log file for Cache Manager ID for Cache Manager Log file for Page Generator Log file for Page Generator slave process ID for Page Generator Log of transactions and errors for the Page Generator master process Log of transactions and errors for the Page Generator master process Global information for the Page Generator process On-line StoryServer information that your web browser can access Information from the last configuration of a CAS A list of preferred macros to use in the Template Editor, including personal versions of the default macros
ctldinfo.log.id
Log file
delivery.tcl
Configuration file
docroot
Directory
lastsession.cfg S UN
Configuration file
macrodata
Configuration file
B-2
03/01/99
File or Directory name metafiles
Type Directory
Description Binary versions of the browser capabilities of corresponding templates A backup copy of the NSAPI configuration file for a Netscape web server Last version of replaced or deleted static files Log of transactions and errors for the Placement Manager master process Log of transactions and errors for a Placement Manager slave process ID for Placement Manager Placement Manager working files Log of transactions and errors from the StoryServer web server module Configuration information for the CMS Log of transactions and errors for the main CMS process Preferences for the browser to use for previewing templates, and for viewing on-line documentation
obj.conf
Configuration file
PadArchiveDir pad.log
Directory Log file
pad.log.id
Log file
pad.pid S UN PadWorkDir plugin.log
Process ID file Directory Log file
pm.cfg
Configuration file
pm.log
Log file
Preferences
Configuration file
03/01/99
B-3
File or Directory name StoryServer.cfg
Type Configuration file
Description Variable settings for the StoryServer CAS processes Errors in the CAS Timed-event process working files
StoryServer.errors S UN S UN TasksWorkingDirsRoot NT TedTasksWorkingDirsRoot ted.log
Log file Directory
Log file
Transactions and errors for the timed-event process Template cache written by tmd and read by ctld Transactions and errors for the Template Manager process ID for Template Manager Transactions and errors for the CMS requesthandling master process Transactions and errors for a CMS requesthandling slave process Request handler working copies of the static files that it has processed
templates
Directory
tmd.log
Log file
tmd.pid S UN vhs.log
Process ID file Log file
vhs.log.id
Log file
VhsProtoDocRoot
Directory
B-4
03/01/99
cmd.log
Audits transactions and errors for the Cache Manager service (process).
Location
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n \host-port-number\cmd.log
Solaris
Description
The cmd.log file contains the chronological list of transactions and errors for the Cache Manager process. The level of logging is set in the CASs StoryServer.cfg file in the CMD_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\VIgnette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\cmd.log S UN /opt/StoryServer/R4.2/conf/thor-9090-1/cmd.log
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\cm.exe
Cache Manager service
03/01/99
B-5
Solaris
/install-path/StoryServer/Rn/bin/solaris/cmd
Cache Manager executable

/install-path/StoryServer/Rn/conf/host-port-number/cmd.pid
Process ID file for the Cache Manager process
cmd.pid
Contains the process ID for the Cache Manager process (Solaris only)
Description
The /install-path/StoryServer/Rn/conf/host-port-number/cmd.pid file contains the process ID for the Cache Manager process. Other processes use the information in this file to locate the Cache Manager process. For information on file location variables, see Common Path Name Variables on page 1-5. An example location:
/opt/StoryServer/R4.2/conf/thor-9090-1/cmd.pid
Files
Cache Manager executable

Audit log for the Cache Manager process
ctld.log
Tracks errors generated by the StoryServer LOG command for the Page Generator process.
B-6
03/01/99
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctld.log
Solaris
Description
The ctld.log file contains messages generated by the StoryServer LOG command for the Page Generator master process (ctld). For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\ctld.log S UN /opt/StoryServer/R4.2/conf/thor-9090-1/ctld.log
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\ctld.exe
Page Generator process


LOG command error log for the slave process having the id number
03/01/99
B-7
Audit log for the slave process having the id number

Solaris
/install-path/StoryServer/Rn/bin/solaris/ctld


LOG command log for the slave process having the id number

/install-path/StoryServer/Rn/conf/host-port-number/ctldinfo.log


ctld.log.id
Tracks errors generated by the StoryServer LOG command for the Page Generator slave process having the id number.
B-8
03/01/99
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctld.log.id
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/ctldd.log.id
Description
The ctld.log.id file contains the messages generated by the StoryServer LOG command for the Page Generator slave process (ctld) having the id number. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\at.mycompany.com-9090\ctld.log.2 S UN /opt/StoryServer/R4.2/conf/thor-9090-1/ctld.log.3
Files
Windows NT


LOG command error log for the Page Generator service

03/01/99
B-9

Solaris


LOG command log for the Page Generator master process




ctld.pid
Contains the process identification number for the Page Generator process (Solaris only).
B-10
03/01/99
Description
The /install-path/StoryServer/Rn/conf/host-port-number/ctld.pid file contains the process ID for the Page Generator process. Other processes use the information in this file to locate the Page Generator process. For information on file location variables, see Common Path Name Variables on page 1-5. An example location:
/opt/StoryServer/R4.2/conf/thor-9090-1/ctld.pid
Files


LOG command log for the Page Generator process



ctldinfo.log
Audits transactions and errors for the Page Generator master process.
03/01/99
B-11
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctldinfo.log
Solaris
Description
The ctldinfo.log file contains the chronological list of database transactions and errors associated with the Page Generator master process (ctld). The level of logging is set in the CASs StoryServer.cfg file in the CTLD_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompany.com-9090\ctldinfo.log S UN /opt/StoryServer/R4.2/conf/thor-9090-1/ctldinfo.log
Files
Windows NT

B-12
03/01/99
Audit log for the Page Generator slave process having the id number
LOG command log for the Page Generator service

Solaris





ctldinfo.log.id
Audits transactions and errors for the Page Generator slave process having the id number.
03/01/99
B-13
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctldinfo.log.id
Solaris
Description
The ctldinfo.log.id file contains the chronological list of database transactions and errors associated with the Page Generator slave process having the id number. The level of logging is set in the CASs StoryServer.cfg file in the CTLD_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompany.com-9090\ctldinfo.log.4 S UN /opt/StoryServer/R4.2/conf/thor-9090-1/ctldinfo.log.4
Files
Windows NT

B-14
03/01/99
LOG command log for the Page Generator service

Audit log for the Page Generator master process

Solaris





delivery.tcl
Contains global information for the Page Generator processes in a StoryServer installation.
03/01/99
B-15
Location
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\delivery.tc
Solaris
/install-path/StoryServer/Rn/conf/delivery.tcl
Description
The delivery.tcl file lets template developers create additional Tcl commands and set variables for the Page Generator processes in a single StoryServer installation without having to edit the configuration files of each CAS. If you want all CASs that access a single CMS, including those that are installed on a different host than the CMS, to have the same delivery.tcl file, you must copy the delivery.tcl file into each installed location. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\delivery.tcl S UN /opt/StoryServer/R4.2/conf/delivery.tcl
There is one delivery.tcl file for all the CASs that share a single \install-path\StoryServer n\Engines\Rn\conf-n\ (/install-path/StoryServer/Rn/conf/ on Solaris) installation.
File
Windows NT
B-16
03/01/99
Solaris


docroot
Contains on-line StoryServer information that your web browser can access.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn\docroot
Solaris
/install-path/StoryServer/Rn/docroot
Description
The docroot directory contains a web-browsable set of StoryServer documentation and an access point for your web browser. In the web server configuration process, the path name of the docroot is mapped to a specific http location so that the contents of the docroot are accessible to the web server.
03/01/99
B-17
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \docroot S UN /opt/StoryServer/R4.2/docroot
lastsession.cfg
Contains configuration information from the last configuration of a CAS (Solaris only).
Location
/install-path/StoryServer/Rn/adm/lastsession.cfg
Description
The lastsession.cfg file, created by the /install-path/StoryServer/Rn/adm/config script on Solaris, contains configuration information gathered when you add a CAS on a host, such as the database name, etc. StoryServer checks for this file and uses the values stored in it as defaults for the config script during the next configuration. NOTE: The configuration scripts source this file. Deleting all non-comment lines will reset the default environments for those scripts. For information on file location variables, see Common Path Name Variables on page 1-5. An example location:
/opt/StoryServer/R4.2/adm/lastsession.cfg
File
Configuration script
B-18
03/01/99
macrodata
Contains your preferred list of macros to use in one of the template editors, including your version of the default macros.
Location
Windows NT
\install-path\StoryServer n\Clients\lib\macrodata
Solaris
/install-path/StoryServer/Rn/ui/lib/macrodata
Description
StoryServer creates a copy of the installed macrodata file and adds your modifications or additions the first time you save in the Macro Editor tool and updates it with each subsequent save. You can edit this file manually and let other users copy it into their home directories if they want to use your macros in their Macro Editor sessions. For information on using the Macro Editor, see the chapter on editing templates in Template Developer Tool Guide. For information on file location variables, see Common Path Name Variables on page 1-5. By default, StoryServer stores your personal macrodata file in different locations depending on the operating system of the UI host:
On Windows, the default location is the Vignette subdirectory in your
home directory.
On Solaris, the default location is the .vgn subdirectory in your home
directory.
On Macintosh, the default location is the Vignette folder in your
selected installation folder. Example locations include:

NT C:\myHome\Vignette\macrodata S UN /u/henry/.vgn/macrodata
03/01/99
B-19
NOTE: You can revert to the default macros shipped with StoryServer by deleting your version or copying the macrodata file to replace your version: NT \install-path\StoryServer n\Clients\lib\macrodata S UN /install-path/StoryServer/Rn/ui/lib/macrodata
metafiles
Contains binary versions of the browser capabilities of corresponding templates.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\metafiles
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/metafiles
Description
The metafiles directory contains files with names corresponding to template locations. The template ID for each template is represented as a file. Each template path is also represented as a file with %2f (the URL encoding of the ascii character /) being used instead of / in the directory path name, for example:
%2ffoo%2flaff%2fchas
NT D:\Program Files\Vignette\StoryServer n\Rn \conf-n\art.mycompany.com-9090\metafiles\ S UN /opt/StoryServer/R4.2/conf/thor-9090-1/metafiles/
B-20
03/01/99
obj.conf
Contains a backup copy of the NSAPI configuration file for a Netscape web server.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\obj.conf
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/obj.conf
Description
The obj.conf file provides a backup copy of web server mappings before StoryServer modifications. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\obj.conf S UN /opt/StoryServer/R4.2/conf/thor-9090-1/obj.conf
The file is a copy of the \ws-install-path\ws-instance\config\obj.conf (/ws-install-path/ws-instance/config/obj.conf on Solaris) file where ws-install-path Specifies the directory where you installed the Netscape web server software. ws-instance Specifies the directory for the web server instance configured with StoryServer.
03/01/99
B-21
Example locations:
NT \Myinstall\netscape\https-hannibal\config\obj.conf S UN /Myinstall/netscape/https-hannibal/config/obj.conf
PadArchiveDir
Contains the last version of replaced or deleted static files.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\PadArchiveDir
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/PadArchiveDir
Description
The PadArchiveDir directory contains the last version of static files replaced or deleted by the Placement Manager. Only the last deleted or replaced version of a particular file name is archived. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompany.com-9090\PadArchiveDir\ S UN /opt/StoryServer/R4.2/conf/thor-9090-1/PadArchiveDir/
pad.log
Audits transactions and errors for the Placement Manager master process.
B-22
03/01/99
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\pad.log
Solaris
Description
The pad.log file contains the chronological list of transactions and errors for the Placement Manager process. The level of logging is set in the CASs StoryServer.cfg file in the PAD_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\pad.log S UN /opt/StoryServer/R4.2/conf/thor-9090-1/pad.log
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\pad.exe
Placement Manager service

Audit log for Placement Manager slave process having id number
03/01/99
B-23
Solaris
/install-path/StoryServer/Rn/bin/solaris/pad
Placement Manager process


Process ID file for the Placement Manager
pad.log.id
Audits transactions and errors for the Placement Manager slave process having the id number.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\pad.log.id
Solaris
Description
The pad.log.id file contains the chronological list of transactions and errors for the slave process having the id number spawned by the Placement Manager process. The level of logging is set in the CASs StoryServer.cfg file in the PAD_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5.
B-24
03/01/99
Example location would be:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\pad.log.2 S UN /opt/StoryServer/R4.2/conf/thor-9090-1/pad.log.8711
Files
Windows NT


Solaris


pad.pid
Contains the process identification number for the Placement Manager process (Solaris only).
Description
/install-path/StoryServer/Rn/conf/host-port-number/pad.pid contains the process ID for the Placement Manager process. Other processes use the information in this file to locate the Placement Manager process.
03/01/99
B-25
For information on file location variables, see Common Path Name Variables on page 1-5. An example location:
/opt/StoryServer/R4.2/conf/thor-9090-1/pad.pid
Files


PadWorkDir
Contains Placement Manager working files.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\PadWorkDir
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/PadWorkDir
Description
The PadWorkDir directory contains files being processed by the Placement Manager. For information on file location variables, see Common Path Name Variables on page 1-5.
B-26
03/01/99
Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\PadWorkDir\ S UN /opt/StoryServer/R4.2/conf/thor-9090-1/PadWorkDir/
Files
Windows NT



Solaris



plugin.log
Audits transactions and errors from the StoryServer web server module.
03/01/99
B-27
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\plugin.log
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/plugin.log
Description
The plugin.log file contains the chronological list of transactions and errors from the StoryServer web server module. The level of logging is set in the CASs StoryServer.cfg file in the HTTPD_PLUGIN_LOG_LEVEL variable. A value of 2 or above causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. The value of the HTTPD_LOG_BY_PID variable set in the CASs StoryServer.cfg file determines whether all messages are logged in a single plugin.log file or the individual process that writes a message creates a separate plugin.log.id file, with the id extension being the writing process ID. Consult the CASs StoryServer.cfg file for valid values, which vary for different web servers. The maximum size at which the log file will stop, create a backup file, and continue error logging is set for all log files in the StoryServer system in the MAX_LOG_SIZE variable in the CMSs pm.cfg file. For information on file location variables, see Common Path Name Variables on page 1-5. Example location would be:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\plugin.log.2 S UN /opt/StoryServer/R4.2/conf/art-9090-1/plugin.log.8711
B-28
03/01/99
Files
Windows NT
Configuration file for CMS

\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\StoryServer.cfg
Configuration file for CAS

Solaris
Configuration file for CMS

Configuration file for CAS
pm.cfg
Contains configuration information for the CMS.
Location
Windows NT
Solaris
Description
The pm.cfg file contains configuration information such as the name, location, and port number of the StoryServer CMS and the location and type of database it will access. The CMS uses this information to connect and communicate with the StoryServer database.
03/01/99
B-29
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.cfg S UN /opt/StoryServer/R4.2/conf/Production/pm.cfg
There is one complete pm.cfg file for a CMS. If a CAS is configured on a host other than the CMS host, the CAS gets a copy of the pm.cfg file. NOTE: If you change the pm.cfg file, CASs installed on the same host as the CMS can access the changes. For information on transferring the changes to the copies of the pm.cfg file installed with each remote CAS, see one of the following:
Updating a Remotely Installed CASWindows NT only on page 8-9. Updating a Remotely Installed CASSolaris only on page 8-11.
CAUTION: Only literal values should be used for the StoryServer variables in this file. Using other values, such as variable expressions, causes some StoryServer processes to fail. For example, the value for PM_LOG_FILE should be the full path (for example,
"C:\Program Files\Vignette\StoryServern\Engines\Rn \conf-n\Production\pm.log") rather than an expression (for example,
"C:\$MYINSTALL\conf\Production\pm.log").
Files
Windows NT
Main CMS service

Solaris
Main CMS process
B-30
03/01/99
pm.log
Audits transactions and errors for the main CMS process.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\Production\pm.log
Solaris
/install-path/StoryServer/Rn/conf/Production/pm.log
Description
The pm.log file contains the chronological list of transactions and errors for the main CMS process. The level of logging is set in the CMSs pm.cfg file in the PM_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.log S UN /opt/StoryServer/R4.2/conf/Production/pm.log
Files
Windows NT
Main CMS service
03/01/99
B-31
Solaris
Main CMS process
Preferences
Contains preferences for the browser to use for previewing templates and viewing on-line documentation, the web server to use for previewing, and the windows that remained open at the last closing of a StoryServer session.
Description
StoryServer generates and updates the Preferences file when you:
Save your login defaults while logging in the first time to a StoryServer
session.
Save your preferences by using the Preferences option in the File menu of
the StoryServer launcher. The file is updated each time you change your selection. You should not edit this file manually. For more information on using the StoryServer launcher to set your browser preferences, see the section on setting browser preferences in Running StoryServer Tools. NOTE: The location of the on-line documentation is set during configuration of a development CAS. If no development CAS can be found, StoryServer defaults to the Vignette on-line location. By default, StoryServer stores your Preferences file in different locations depending on the operating system of the UI host:
On Windows, the default location is the Vignette subdirectory in your
home directory.
On Solaris, the default location is the .vgn subdirectory in your home
directory.
On Macintosh, the default location is a Vignette folder in the System
Folder->Preferences folder.
B-32
03/01/99
Example locations include:

NT C:\myHome\Vignette\Preferences S UN /u/henry/.vgn/Preferences
StoryServer.cfg
Contains variable settings for the StoryServer CAS processes.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\StoryServer.cfg
Solaris
Description
The \install-path\StoryServer n\Engines\Rn\adm\setup.exe command (/install-path/StoryServer/Rn/adm/config script on Solaris) creates the StoryServer.cfg file when you install a StoryServer CAS. The CAS processes use the information in this file when communicating with the CMS, the database, and each other. NOTE: If you change this file, you must reset the Page Generator and Template Manager processes for the CAS afterwards. For more information, see Resetting CAS Processes on page 8-2. If you change this file, you must also update the CMS with the CASs latest configuration information. For more information, see one of the following:
Editing the StoryServer.cfg File on Windows NT on page 11-3 Notifying the CMS of changes to StoryServer.cfgSolaris only on
page 8-12 For more information on StoryServer.cfg modifications, see one of the following:
03/01/99
B-33
Tuning StoryServer on Windows NT on page 11-1 Tuning StoryServer on Solaris on page 12-1
NT D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\al.mycompany.com-909\StoryServer.cfg S UN /opt/StoryServer/R4.2/conf/thor-9090-1/StoryServer.cfg
CAUTION: Only literal values should be used for the StoryServer variables in this file. Using other values, such as variable expressions, causes some StoryServer processes to fail. For example, the value for TMD_LOG_FILE should be the full path (for example,
Files/Vignette/StoryServern/Engines/R4.2 /conf-n/ti.myco.com-93/tmd.log") rather than an expression example, "C:/$MYINSTALL/conf/ti.myco.com-93/tmd.log").
"C:/Program
(for
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\cm.exe
Cache Manager service

Page Generator service


\install-path\StoryServer n\Engines\Rn\bin\winnt\tmd.exe
Template Manager service

Solaris
Cache Manager process
B-34
03/01/99


/install-path/StoryServer/Rn/bin/solaris/tmd
Template Manager process
StoryServer.errors
Tracks errors in the CAS (Solaris only).
Description
The /var/adm/StoryServer.errors file tracks errors arising from CAS processes. The /usr/sbin/syslogd process manages the StoryServer.errors file.
TasksWorkingDirsRoot
Contains timed-event process working files.
Location
Windows NT
03/01/99
B-35
Solaris
/install-path/StoryServer/Rn/taskbin/solaris/TasksWorkingDirsRoot/
Description
The TasksWorkingDirsRoot/ directory contains files being processed by the timed-event process. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\TedTasksWorkingDirsRoot\ S UN /opt/StoryServer/R4.2/taskbin/solaris/TasksWorkingDirsRoot/
Files
Windows NT
Timed event service

Solaris
Timed-event process
ted.log
Audits transactions and errors for the timed-event process.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn\conf-n\Production\ted.log
B-36
03/01/99
Solaris
/install-path/StoryServer/Rn/conf/Production/ted.log
Description
The ted.log file contains the chronological list of transactions and errors for the timed-event process. The level of logging is set in the CMSs pm.cfg file in the TED_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.log S UN /opt/StoryServer/R4.2/conf/Production/pm.log
Files
Windows NT
Timed-event service
Directory of files being processed by the timed-event service

Solaris
Timed-event process
/install-path/StoryServer/Rn/taskbin/solaris/TasksWorkingDirsRoot/
Directory of files being processed by the timed-event process
03/01/99
B-37
templates
Template cache written by the Template Manager process and read by the Page Generator process.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\templates
Solaris
/install-path/StoryServer/Rn/conf/host-port-number/templates
Description
The templates directory is the template cache written by the Template Manager process and read by the Page Generator process. The cache contains files with names corresponding to template locations. The template ID for each template is represented as a file. Each template path is also represented as a file with %2f (the URL encoding of the ascii character /) being used instead of / in the directory path name, for example,
%2ffoo%2flaff%2fchas
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompnay.com-9090\templates\ S UN /opt/StoryServer/R4.2/conf/thor-9090-1/templates/
B-38
03/01/99
Files
Windows NT
Page Generator service


Solaris

tmd.log
Audits transactions and errors for the Template Manager process.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\tmd.log
Solaris
Description
The tmd.log file contains the chronological list of transactions and errors for the Template Manager process.
03/01/99
B-39
The level of logging is set in the CASs StoryServer.cfg file in the TMD_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompnay.com-9090\tmd.log S UN /opt/StoryServer/R4.2/conf/thor-9090-1/tmd.log
Files
Windows NT

Solaris

/install-path/StoryServer/Rn/conf/host-port-number/tmd.pid
Process ID file for the Template Manager process
tmd.pid
Contains the process ID number for the Template Manager process (Solaris only).
Description
The /install-path/StoryServer/Rn/conf/host-port-number/tmd.pid file contains the process ID for the Template Manager process. Other
B-40
03/01/99
processes use the information in this file to locate the Template Manager process. For information on file location variables, see Common Path Name Variables on page 1-5. An example location:
/opt/StoryServer/R4.2/conf/thor-9090-1/tmd.log
Files

vhs.log
Audits transactions and errors for the CMS request-handling master process.
Location
Windows NT
Solaris
Description
The vhs.log file contains the chronological list of transactions and errors for the CMS request-handling process. The level of logging is set in the CMSs pm.cfg file in the VHS_LOG_LEVEL variable. A value of 3 or 4 causes information to be
03/01/99
B-41
written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\vhs.log S UN /opt/StoryServer/R4.2/conf/Production/vhs.log
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\vhs.exe
\install-path\StoryServer n\Engines\Rn\conf-n\Production\vhs.log.id

Solaris
request-handling process
vhs.log.id
Audits transactions and errors for the slave process having the id number.
B-42
03/01/99
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\Production\vhs.log.id
Solaris
Description
The vhs.log.id file contains the chronological list of transactions and errors for the slave process having the id number spawned by the CMS request-handling process. The level of logging is set in the CMSs pm.cfg file in the VHS_LOG_LEVEL variable. A value of 3 or 4 causes information to be written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\vhs.log.2 S UN /opt/StoryServer/R4.2/conf/Production/vhs.log.1447
Files
Windows NT
\install-path\StoryServer n\Engines\Rn\bin\winnt\vhs
Audit log for the request-handling service
03/01/99
B-43
Solaris
Request-handling process
Audit log for the request-handling process
VhsProtoDocRoot
Contains the request handler working copy of the static files that it has processed.
Location
Windows NT
\install-path\StoryServer n\Engines\Rn \conf-n\Production\VhsProtoDocRoot
Solaris
Description
The VhsProtoDocRoot directory contains files being processed by the request handler. Each time a user adds a static content file (any content that doesnt reside in the database) via the New option of the Project Manager File command, StoryServer creates the file in the CMSs VhsProtoDocRoot directory:
NT \install-path\StoryServer n\Engines\Rn \conf-n\Production\VhsProtoDocRoot S UN /install-path/StoryServer/Rn/conf/Production/VhsProtoDocRoot
The CMS then distributes copies of new files to the docroots of the web servers configured with the development CASs. When a launch occurs, the CMS distributes the associated static files to the live CAS web server docroots.
B-44
03/01/99
When you resubmit a static file through the Project Manager, the file is also propagated to the appropriate web server docroots. When you rename a file (that is, you modify the path name) through the Project Manager, the file is renamed in VhsProtoDocRoot and propagated to development CASs if it has not been launched and also to live CASs if it has already been launched. TIP: If you add static files other than through the Project Manager, StoryServer does not know about them. You should copy these files to the CASs according to the type of the CAS. For example, copy files from the docroot of a development CASs web server to the docroot of another development CASs web server to avoid exposing files in progress on a live CAS. For information on file location variables, see Common Path Name Variables on page 1-5. Example locations:
NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\VhsProtoDocRoot S UN /opt/StoryServer/R4.2/conf/Production/VhsProtoDocRoot
03/01/99
B-45
B-46
03/01/99
C
Summary: Audience:
Remote Operations
Configuring systems with firewalls or proxy servers. Administrators of StoryServer 4.2 Managing StoryServer on Windows NT and Solaris on page 9-1
Overview Connections Inside a Firewall CAS Outside the Firewall StoryServer Sessions Outside the Firewall Outbound Connections via HTTP Proxy StoryServer Sessions Using SOCKS Proxy
03/01/99
C-1
Remote Operations
Overview
You may want to configure a live Content Application Server (CAS) on a host outside your security firewall and allow it to communicate with a Content Management Server (CMS) on a host inside the firewall. Another remote operation might be to run the StoryServer tool session outside the firewall, for example, to allow remote project tracking. In this appendix, the word port refers to the host:port location through which communication occurs. One or more processes may communicate through a single host:port. In addition, content entry templates that require access to a port for the bob process do so because they contain one or more of the commands that require information from the CMS. These include the NEEDS LOGIN, RECORD UPDATE, RECORD DELETE, and GET_PROJECT_LIST commands. NOTE: StoryServer does NOT support CAS communication through SOCKS proxy.
Connections Inside a Firewall

When all of StoryServers elements are within a firewall, the processes communicate across the network as shown in Figure C-1. The circled numbers represent the number of ports that are required for the various requests. The arrows represent the following connections: StoryServer Sessions connect to CMS The Production Center, Template Developer, Business Center, and Admin Center require ports to connect with the bob and vhs processes. (total 2 ports) Admin Center (StoryServer Session) connects to a CAS The Admin Center require ports to connect to the cmd, ctld, pad, pznd, and tmd processes on each CAS. (total 5 ports for each CAS) The Production Center connects to the CAS (for content entry and template preview) via the web browser through the web server and does not require another port.
C-2
03/01/99
Remote Operations
CMS connects to a CAS The CMSs vhs process requires one port to connect to a CASs tmd process. (total 1 port) CMS connects to the database The CMS requires 1 port for its vhs and bob processes to communicate with the database. (total 1 port, the same one used by CASs) CAS connects to the CMS A CAS requires a port to connect to the CMS when it is being configured and for content entry templates needing to connect to the CMS. (total 1 port) CAS connects to the database A CAS requires 1 port for the ctld, pznd, and tmd processes to communicate with the database. (total 1 port for each CAS, the same one used by the CMS)
03/01/99
C-3
Remote Operations
Figure C-1:
Ports required with all StoryServer elements inside firewall
StoryServer sessions 2 5 1 CM Server

saga:7007
5 1
Router/ Firewall
1 StoryServer DB
Development CAS
Live CAS
Web Server
Web Server
I N T E R N E T
/DocRoot
/DocRoot
C-4
03/01/99
Remote Operations
CAS Outside the Firewall

Figure C-2 assumes that outbound connections through the firewall are not restricted. The shaded squares show the number of holes required in the firewall for inbound traffic. The arrows shown in Figure C-2 represent the following connections: Element connections within the firewall Remain the same as in Figure C-1. StoryServer sessions connect to a CAS When a CAS is outside the firewall, assume outbound StoryServer session connections are not restricted. CMS connects to a CAS When a CAS is outside the firewall, assume outbound connections are not restricted. Live CAS connects to the CMS A CAS requires a port to connect to the CMS when it is being configured and for content entry templates needing to connect to the CMS. (total 1 port) When the CAS is outside the firewall, this connection requires a hole in the firewall. CAS connects to the database A CAS requires 1 port for the ctld, pznd, and tmd processes to communicate with the database. (total 1 port for each CAS) When the CAS is outside the firewall, these processes require a single hole in the firewall. Internet connects to the live CASs web server An Internet request requires one port to connect to the web server.
03/01/99
C-5
Remote Operations
Figure C-2:
Request connections required with live CAS outside firewall
Router/ Firewall 5 StoryServer sessions 2 5 1 1 StoryServer DB CM Server

saga:7007
Development CAS
Live CAS
Web Server
Web Server
I N T E R N E T
/DocRoot
/DocRoot
C-6
03/01/99
Remote Operations
StoryServer Sessions Outside the Firewall

Topics include:
Setting the VHS_PORT Variable Working with IP-aliasing Firewalls
Figure C-3 assumes that outbound connections through the firewall are not restricted. The shaded squares show the number of holes required in the firewall. The shaded circle includes the port specified for the vhs process (see Setting the VHS_PORT Variable on page C-10). The arrows shown in Figure C-3 represent the following connections: Element connections within the firewall Remain the same as in Figure C-1. StoryServer session connects to a CAS or CMS When a StoryServer session is outside the firewall, inbound session connections require holes in the firewall.
The Admin Center (StoryServer sessions) requires 5 ports to connect to
the CAS processes inside the firewall. Thus there are 5 holes in the firewall for each inside CAS it must administer. (The Admin Center also requires 5 ports to connect to each CAS outside the firewall.)
The Admin Center, Template Developer, Business Center, and Production
Center (StoryServer sessions) need one port to connect to the bob process and require another, fixed port for vhs. (See Setting the VHS_PORT Variable on page C-10.) (total 2 holes in the firewall) CMS connects to a CAS When a CAS is outside the firewall, assume outbound connections are not restricted. CAS connects to the CMS A CAS requires a port to connect to the CMS when it is being configured and for content entry templates needing to connect to the CMS. (total 1 port) When the CAS is outside the firewall, this connection requires a single hole in the firewall.
03/01/99
C-7
Remote Operations
CAS connects to the database A CAS requires 1 port for the ctld, pznd, and tmd processes to communicate with the database. (total 1 port for each CAS) When the CAS is outside the firewall, these processes require a single hole in the firewall. Internet connects to the Live CASs web server An Internet request requires one port to connect to the web server.
C-8
03/01/99
Remote Operations
Figure C-3:
Request connections required with sessions outside firewall
5 StoryServer sessions 5 2 2 Router/ Firewall 1
VHS_PORT
5 1
CM Server
saga:7007
1 1 StoryServer DB
Development CAS
Live CAS
Web Server
Web Server
I N T E R N E T
/DocRoot
/DocRoot
03/01/99
C-9
Remote Operations
Setting the VHS_PORT Variable

You give the StoryServer session the correct port for the CMSs bob process when you connect to the CMS in the StoryServer Login window. To specify that the vhs process always communicates on a fixed port, you must set the VHS_PORT environment variable in the CMSs pm.cfg file.
I To set the VHS_Port variable: 1 2
Open the CMSs pm.cfg file, as explained in CMS Configuration File (pm.cfg) on page 6-3. Uncomment the following line and add your specified port (use a value greater than 1024):
set VHS_PORT 30211
3 4
Save the change to the file. Stop and restart the CMS to implement the change. See Stopping and Starting the CMS with the admin Command on page 8-4 or Stopping and Starting with the Start Menu OptionsWindows NT only on page 8-8. You can now start the StoryServer session outside the firewall. TIP: The machine on which the StoryServer session operates must be able to reach the CMS host machines IP address. For some kinds of firewalls, (those that remap IP addresses, for example) more is required than simply specifying the VHS_PORT (see Working with IP-aliasing Firewalls on page C-10).
Working with IP-aliasing Firewalls

I To work with IP-aliasing firewalls: 1 2 3 4
Ensure that the Domain Name service (DNS) is configured for the internal host name, not the IP address. Set the attr for the vhs processs host to the hostname rather than the internal IP address. Set the vhs process port to a static number (see Setting the VHS_PORT Variable on page C-10). Create firewall holes for the bob and vhs process ports.
In the following example, assume:

The vhs process server is baxter.myco.com.
C-10
03/01/99
Remote Operations
The internal IP address for baxter.myco.com is 207.8.8.203. The external IP address (from outside the firewall) for
baxter.myco.com is 207.8.7.25. If you set the vhs host attr to 207.8.7.25, requests from outside the firewall will work, but requests from inside will fail. If you set the vhs host attr to 207.8.8.203, requests from inside the firewall will work, but requests from outside will fail.
I To set the vhs host attr: 1
On the CMSs host, change to the bin directory where the CMS is installed. If you installed at the default location, you would enter:
NT cd \Program Files\Vignette\StoryServer n \Engines\Rn\bin\winnt
or
S UN cd /opt/StoryServer/Rn/bin/solaris 2
Run the following command: For example:
pmcmd -b bobHost:bobPort setsubattr /cf/class [\"VHS\"] \"Host\" \"vhsHost\"
pmcmd -b baxter.myco.com:30210 setsubattr /cf/class [\"VHS\"] \"Host\" \"baxter.myco.com\"
Outbound Connections via HTTP Proxy

Figure C-4 assumes that outbound connections through the firewall are restricted and must pass through the http proxy server. The shaded squares show the number of additional holes required in the firewall. The arrows shown in Figure C-4 represent the following connections: Element connections within the firewall Remain the same as in Figure C-1. Admin Center (StoryServer sessions) connects to a CAS The Admin Center requires ports to connect with the cmd, ctld, pad, pznd, and tmd processes on each CAS. (total 5 ports for each CAS) When a CAS is outside a firewall with an http proxy server, the requests must go through the http proxy server.
03/01/99
C-11
Remote Operations
CMS connects to a CAS The CMSs vhs process requires one port to connect to a CASs tmd process. (total 1 port) When the CAS is outside a firewall with an http proxy server, the request must go through the http proxy server. CAS connects to the CMS A CAS requires a port to connect to the CMS when it is being configured and for content entry templates needing to connect to the CMS. (total 1 port) When the CAS is outside the firewall, this connection requires a hole in the firewall. CAS connects to the database A CAS requires 1 port for the ctld, pznd, and tmd processes to communicate with the database. (total 1 port for each CAS) When the CAS is outside the firewall, these processes require a single hole in the firewall. Internet connects to the Live CASs web server An Internet request requires one port to connect to the web server.
C-12
03/01/99
Remote Operations
Figure C-4:
Request connections required with http proxy server
Router/ Firewall 5 StoryServer sessions 2 5 1 1 StoryServer DB CM Server

saga:7007
http proxy server 1
Development CAS
Live CAS
Web Server
Web Server
I N T E R N E T
/DocRoot
/DocRoot
StoryServer 4.2 supports CMS communication through an http proxy server. If you have an http proxy server set up, you can configure a CAS on a host
03/01/99
C-13
Remote Operations
outside the firewall to receive communication from the CMS inside the firewall through the http proxy. You must specify the http proxy hosts fully qualified domain name and the port on which it communicates, for example, harvey.myco.com using port number 1234. You must be a system admin user to perform the following operation.
I To configure a CAS outside the firewall: 1 2
You must have a hole (port) in the firewall through which the CAS can contact the CMS. After the CAS is installed and configured on the host outside the firewall, edit the CASs StoryServer.cfg file to add the following variables after the WEB SERVER SETTINGS section:
set PROXY_HOST harvey.my.com set PROXY_PORT 1234
(For Windows NT, see Editing the StoryServer.cfg File on Windows NT on page 11-3. For Solaris, use your preferred file editor. See StoryServer.cfg on page B-33 for the location of the file.)
3
Depending on the operating system, choose one of the following:

On Windows NT, close the StoryServer.cfg file and select the Test
option.
On Solaris, close the StoryServer.cfg file.
Update the CMS with the StoryServer.cfg changes using admin updatepe. (For more information, see Notifying the CMS of changes to StoryServer.cfgSolaris only on page 8-12.)
4 5
Stop and restart the CMS to read the new information. If no content entry templates need to use the NEEDS LOGIN, RECORD UPDATE, RECORD DELETE, or GET_PROJECT_LIST commands, you can now close the port in the firewall. If a StoryServer session is running, reconnect to the CMS. For more information, see the section on connecting to a CMS in Running StoryServer Tools.
C-14
03/01/99
Remote Operations
StoryServer Sessions Using SOCKS Proxy

Topics include:
StoryServer Sessions and SOCKS on Windows NT StoryServer Sessions and SOCKS on Solaris
Figure C-5 assumes that StoryServer user interface inbound connections through a firewall are restricted and must pass through a SOCKS proxy server. The arrows shown in Figure C-5 represent the following connections: Element connections within the firewall Remain the same as in Figure C-1. User interfaces connect to CMS The Production Center and Admin Center (StoryServer sessions) require ports to connect with the bob and vhs processes. (total 2 ports) When the StoryServer session is outside a firewall with a SOCKS proxy server, the requests must go through the SOCKS proxy server. Admin Center (StoryServer sessions) connects to a CAS The Admin Center requires 5 ports to connect with the cmd, ctld, pad, pznd, and tmd processes on each CAS. (total 5 ports for each CAS) When the StoryServer session is outside a firewall with a SOCKS proxy server, the requests must go through the SOCKS proxy server.
03/01/99
C-15
Remote Operations
Figure C-5:
Connections required with sessions using SOCKS
SOCKS proxy server
StoryServer sessions
2 1
CM Server
saga:7007
Router/ Firewall 1 5
1 StoryServer DB
Development CAS
Live CAS
Web Server
Web Server
I N T E R N E T
/DocRoot
/DocRoot
StoryServer 4.2 supports StoryServer session communication through a SOCKS proxy server. If you have a SOCKS proxy server set up, you can
C-16
03/01/99
Remote Operations
install StoryServer user interface software on a Windows 95, Windows NT, or Solaris host outside a firewall to communicate through the SOCKS proxy with the CMS and CASs. NOTE: StoryServer 4.2 does not support SOCKS proxy connection for the StoryServer session on Macintosh. You must have the SOCKS proxy server configured and the StoryServer tool software installed. For the shost and sport variables, you must know the fully qualified SOCKS host domain and the port on which the SOCKS server listens, for example:
rambo.myco.com:4567
StoryServer Sessions and SOCKS on Windows NT

You can use a SOCKS proxy server for the StoryServer session on Windows NT:
By specifying the server on the command line By changing the StoryServer shortcut button.
Specifying the Server Using Command-line Options

I To specify the SOCKS proxy server using command-line options: 1 2 3
Start a DOS shell. If necessary, change to the drive on which the StoryServer tool software is installed. Change to the bin directory of the StoryServer tools. If you installed at the default location, you would enter:
cd \Program Files\Vignette\StoryServer n\Clients\bin
Start the StoryServer session:

ss -s shost:sport
Changing the StoryServer Shortcut Button

I To specify the SOCKS proxy server by changing the StoryServer shortcut button: 1
On the Windows desktop, right click the StoryServer shortcut icon and select Properties. The StoryServer Properties window opens.
03/01/99
C-17
Remote Operations
Select the Shortcut tab. The Shortcut page opens. The Target text field will look similar to the following:
"C:\Program Files\Vignette\StoryServer n\Clients\java\bin\jrew.exe" -ms4m -mx32m -noverify -classpath .\..\java\lib\rt.jar;ss.jar;vignette.jar;res.jar;images.jar;ifc11.jar; dde.jar StoryServer 3
Append the -s flag and the SOCKS host and port to the Target text field:
-s shost:sport
The Target text field now looks similar to the following:

"C:\Program Files\Vignette\StoryServer n\Clients\java\bin\jrew.exe" -ms4m -mx32m -noverify -classpath .\..\java\lib\rt.jar;ss.jar;vignette.jar;res.jar;images.jar;ifc11.jar; dde.jar StoryServer -s rambo.myco.com:4567 4
Save the changes to the shortcut and run the StoryServer session.
StoryServer Sessions and SOCKS on Solaris

I To use a SOCKS proxy server for the StoryServer session on Solaris, specify the server on the command line: 1
Change to the bin directory of the StoryServer tools. If you installed at the default location, you would enter:
cd /opt/StoryServer/Rn/ui/bin
Start the StoryServer session:

./ss -s shost:sport
C-18
03/01/99
D
Summary: Audience:
Managing GroupLens Express
Information about the management operations you may need to perform for GroupLens Express Administrators of the GroupLens Express software Basic Concepts on page 1-1
Overview Setting Environment VariablesSolaris Only Starting GroupLens Express Stopping GroupLens Express Getting Status Backing Up the Database
03/01/99
D-1
Overview
The Net Perceptions, Inc.s GroupLens Express software adds collaborative filtering technology to StoryServer by storing user preferences and computing recommendations for items a site visitor might like. GroupLens Express is accessed via a set of GL_ template commands that template developers use within StoryServer templates.
Setting Environment VariablesSolaris Only

Before you can use any of the GroupLens commands described in this appendix, you must set a few environment variables. NOTE: You must be the system admin (or super) user to run the GroupLens Express commands on Solaris. If youre using the csh or tcsh shell, source the following file into your user environment: /GLEinstall-path/config/cshprofile. For example:
source cshprofile
If youre using the Bourne or Korn shell, source this file into your user environment: /GLEinstall-path/config/shprofile. For example:
. shprofile
GLEinstall-path is the directory where you installed the GroupLens Express software.
Starting GroupLens Express

Topics include starting GroupLens Express:
On Solaris On Windows NT
On Solaris
I To start GroupLens Express on Solaris: 1
Log in as system admin user to the host where the GroupLens Express software is installed.
D-2
03/01/99
To start the GroupLens Express software, enter:

/GLEinstall-path/bin/glstartup -n
where GLEinstall-path is the directory in which the GroupLens Express software is installed.
On Windows NT
I To start GroupLens Express on Windows NT: 1 2 3
Log in as system admin user to the host where the GroupLens Express software is installed. To start the GroupLens Express software, open the Services dialog (select Start-Settings-Control Panel-Services). Select the GroupLens Startup service and select Start.
Stopping GroupLens Express

Topics include stopping GroupLens Express:
On Solaris
I To perform an orderly shutdown of the GroupLens Express processes on Solaris: 1 2
Log in as system admin user to the host where the GroupLens Express software is installed. At the command line, enter:
/GLEinstall-path/bin/glshutdown -n
where GLEinstall-path is the directory in which the GroupLens Express software is installed.
03/01/99
D-3
On Windows NT
I To perform an orderly shutdown of the GroupLens Express software on Windows NT: 1 2 3
Log in as system admin user to the host where the GroupLens Express software is installed. To start the GroupLens Express Software, open the Services dialog (select Start - Settings - Control Panel - Services). Select the GroupLens Startup service and select Stop.
Getting Status
Topics include getting status:
On Solaris
To determine if the GroupLens Express processes are running on a Solaris system, use the ps(1) command. For example:
# ps -Af|grep gl
On Windows NT
To determine if the GroupLens Express services are running on a Windows NT system, you can check the status for the Start GroupLens service in the Services dialog via the Control Panel.
Backing Up the Database

Topics include backing up the database:
D-4
03/01/99
On Solaris
The GroupLens Express data is stored in the file system on Solaris. The directory where the GroupLens Express data is stored is defined by the GL_DBROOT environment variable. You should regularly back up the contents of the directory named by this variable. The value of the GL_DBROOT variable is listed in either the shprofile or cshprofile file located in /GLEinstall-path/config.
On Windows NT
For the Windows NT platform, you should manage your GroupLens Express database as you would manage any database. We recommend that you perform regular backups to secure your data.
03/01/99
D-5
D-6
03/01/99
E
Summary: Audience:
How to set up virtual hosting for the web servers you use with StoryServer Content Application Servers (CASs) Administrators of StoryServer 4.2
Before you begin:
Managing StoryServer on Windows NT and Solaris on page 9-1 Working with Web Servers on Windows NT or Solaris on page 10-1 Concepts Configuring Web Servers Testing the Virtual Servers Virtual Server Front Doors Virtual Hosting and Development
Topics include:
03/01/99
E-1
Concepts
When you configure StoryServer for virtual hosting, you set up one CAS to serve multiple virtual web servers. Virtual web servers allow you to set up multiple document root (or home) directories served by a single web server process, where each document root responds to a distinct IP address or hostname. Figure E-1 shows an CAS in which the web server has been configured to serve two virtual domains: Domain1 and Domain2, with pages cached in the file system in separate subdirectories of the DocRoot.
Figure E-1: CAS Set Up for Virtual Hosting With Two Domain
Requests for Domain1
Requests for Domain2
http://www.Domain1.com
http://www.Domain2.com
IP 207.8.8.22
Web Server
IP 2 207.8.8.23
.../DocRoot .../DocRoot/Domain1 .../DocRoot/Domain2
How Virtual Hosting Works With StoryServer

Virtual hosting with StoryServer requires that you perform some additional configuration on the web server being used with your CAS. Heres a summary of how you set up virtual hosting with StoryServer:
E-2
03/01/99
Start by configuring your web server and CAS in the default fashion as described in the Platform Installation & Configuration Guide (printed copy shipped with product). Configure IP addresses or hostnames (one for each virtual domain) for the machine on which the web server runs. NOTE: Configuring Web Servers on page E-3 describes one way of setting up virtual web servers and communicating the appropriate information to StoryServer. You should refer to your web server documentation for more thorough instructions.
3 4
Configure the web server to map IP addresses or hostnames to individual document directories within a common document root directory. When working with templates, include the unique path that differentiates the virtual server as a prefix on templates and files you want associated with that server. The CURL command also contains additional keywords for use when referencing a separate virtual domain.
Configuring Web Servers

Topics include:
Netscape Web Servers Microsoft IIS 4 Web Servers Apache Web ServersSolaris Only
I To configure any supported web server for virtual hosting: 1
Configure your web server with a single document root directory. Then, configure the web server as you normally would with a StoryServer CAS. For details, see the Platform Installation & Configuration Guide (printed copy shipped with product). Create separate document root directories for each of your virtual host domains. Locate these directories beneath the document root (or home directory) of the web server configured with the CAS. For example, if the document root directory for your web server is C:\DocRoot and you plan on two virtual hosts, Domain1 and Domain2, create the directories:
C:\DocRoot\Domain1 C:\DocRoot\Domain2
03/01/99
E-3
NOTE: These directory names are case-sensitive.

3
Follow the steps in the following sections for your web server type.
Netscape Web Servers

I To configure a Netscape web server to user virtual hosting with StoryServer: 1
Open the browser-based Netscape Server Administration interface for the web server. NOTE: When you begin work in the interface, be sure to apply the changes StoryServer made to your obj.conf file, the NSAPI configuration file for Netscape web servers.
Make the following changes from within the Netscape Server Administration interface and save and apply your changes:
What Set bind-to address. Set the Primary Document Directory. Set up the hardware virtual server. How Select web server, select Server Preferences then Network Settings, enter your main IP address in Bind To Address field. Select Content Management for the web server. Append the name of the domain directory associated with IP address 1 to the primary directory path. For example, \Domain1. Select Content Management then Hardware Virtual Servers. Enter IP address 2 in the IP Address field. Enter the complete path for the virtual domain document directory associated with IP address 2. For example: C:\DocRoot\Domain2.
Edit the obj.conf file for the web server to make the following changes: Add a new line to the Init section of the file for each virtual domain you want to run on the web server. (Place these after the "load-modules" line that was added by StoryServer.) The format for these lines should be:
Init fn="curl_virtualhost" address="IPaddress" Vgn_TplPrefix="path"
where IPaddress is the numeric IP address for the domain, and where path is the subdirectory in the web server document root associated with that IP address. For example:
Init fn="curl_virtualhost" address="207.8.8.165" Vgn_TplPrefix="/Domain1" Init fn="curl_virtualhost" address="207.8.8.166" Vgn_TplPrefix="/Domain2"
E-4
03/01/99
Apply the manual edits to your obj.conf file in the browser Administration interface. Then, stop and start the web server.
Microsoft IIS 4 Web Servers

After completing the steps in Configuring Web Servers on page E-3, follow these steps to configure a Microsoft IIS web server for virtual hosting with StoryServer: The steps for configuring an IIS 4 web server for virtual hosting include:
1 2 3
Updating IIS Settings Obtaining the Web Site ID Updating the Registry
Updating IIS Settings

I To update IIS settings, from within the Microsoft Management Console (this may be referred to as Internet Service Manager in your menu): 1 2
Open the Properties for the default or primary web server you named when you configured the StoryServer CAS. With WWW Service selected, click the Edit button. Make the following changes and additions:
What Set IP address. How In the Web Site panel, set the IP address you want to associate with the first domain (this may be the primary IP address for the machine). In the Home Directory panel, append the subdirectory path for the first virtual domain to the Local Path value.
Configure the default home directory as a virtual server.
03/01/99
E-5
For each additional virtual domain, add a new web site. When responding to the prompts, use the following values:
What IP address Default directory Value The address you want to associate with the virtual domain. The base directory you used for the primary web site, plus the unique subdirectory for this domain. For example, if the base document root for the primary site is C:\DocRoot and the subdirectory for this domain is Domain2, enter C:\DocRoot\Domain2. Scripting permissions, to handle server-side includes required by StoryServer.
Permissions
Obtaining the Web Site ID
Youll need to use the web site ID later in the configuration process. To determine the ID for your web site, use the C:\install-path\StoryServer 4\Engines\R 4.n\bin\winnt\listiis utility at a DOS command prompt. listiis lists the IIS 4 web sites and their IDs.
Updating the Registry
I To complete configuration for IIS 4 web servers, edit the system registry using the Registry Editor (enter regedit at a command prompt). Make the following changes: 1
Open the definition:
HKEY_LOCAL_MACHINE\SOFTWARE\Vignette\StoryServer Content Management and Application Servers\IIS_Plugin 2
For each web site you created for virtual hosting with StoryServer, create a new key, where the name of the key is the web site ID number. For example, the ID for the default web site is 1. See the Obtaining the Web Site ID on page E-6 section for instructions if you havent already found this ID.
E-6
03/01/99
3 String SS Config File
For each web-site ID key, create the following string-value pairs:

Value Path to StoryServer.cfg for the CAS with which the primary web site is configured. For example: D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\al.mycompany.com-909\StoryServer.cfg
SS Version Vgn_TplPrefix
The version of the StoryServer platform software. For example, 4.2. The subdirectory, in the primary web site home directory, dedicated to this web site (and IP address). For example, \Domain1 or \Domain2.
Stop and start the web server.
Apache Web ServersSolaris Only

To configure an Apache web server to use virtual hosting with StoryServer, you essentially add a Vgn_TplPrefix definition to each VirtualHost segment youve defined in your Apache configuration file.
I To set up Apache virtual hosting with StoryServer: 1 2
Edit the httpd.conf file for the web server configuration. This file is typically in the apache-install-path/apache/conf directory. At the bottom of the file, confirm that the following variable definitions have been added or uncommented:
Vgn_SSConfigFile The location of the StoryServer.cfg
file for the CAS. For example,

/install-path/StoryServer/Rn/conf/host-port-num/StoryServer.cfg
Vgn_ShLibDir The location of the shared library directory of your
StoryServer installation. For example,

/install-path/StoryServer/Rn/lib/solaris
For information on file location variables, see Common Path Name Variables on page 1-5.
3
Add a VirtualHost entry for each virtual domain to be served by the web server using this format:
<VirtualHost hostname> Vgn_SSConfigFile StoryServer.cfg-path Vgn_ShLibDir StoryServer-shared-lib-path
03/01/99
E-7
ServerName hostname DocumentRoot docroot-path/domain-path Vgn_TplPrefix /domain-path </VirtualHost> Argument hostname StoryServer.cfg-path Description Hostname for the virtual web server. Path of the StoryServer.cfg file for the CAS with which the web server is associated. Enter the same value as you did when you included the Vgn_SSConfigFile variable in the main body of the httpd.conf file. See Step 2. Path of the shared library directory of your StoryServer installation. Enter the same value you did when you included the Vgn_ShLibDir variable in the main body of the httpd.conf file. See Step 2. Path to the web server document root directory (which you told to StoryServer during configuration of the CAS). Subdirectory in the document root that is dedicated to hostname.
StoryServer-shared-lib-path
docroot-path
domain-path
This example defines two virtual web servers with hostnames Domain1 and Domain2. The primary web server document root is /opt/httpd/docroot, and it contains two subdirectories, corporate and sales.
<VirtualHost www.Domain1.com> Vgn_SSConfigFile /opt/StoryServer/R4.1/conf/www-8989-1/StoryServer.cfg Vgn_ShLibDir /opt/StoryServer/R4.1/lib/solaris ServerName www.Domain1.com DocumentRoot /opt/httpd/docroot/corporate Vgn_TplPrefix /corporate </VirtualHost> <VirtualHost www.Domain2.com> Vgn_SSConfigFile /opt/StoryServer/R4.1/conf/www-8989-1/StoryServer.cfg Vgn_ShLibDir /opt/StoryServer/R4.1/lib/solaris ServerName www.Domain2.com DocumentRoot /opt/httpd/docroot/sales Vgn_TplPrefix /sales </VirtualHost>
E-8
03/01/99
Stop and start the Apache web server.
Testing the Virtual Servers

We recommend for testing purposes that you create a minimal, unique index or default page in each domain directory. You should be able to view the test HTML pages you created at http://host/, where host is the hostname for the virtual web server. For example:
http://www.Domain1.com/ http://www.Domain2.com/ Delivers the home page for the Domain1 virtual server. Delivers the home page for the Domain2 virtual server.
Virtual Server Front Doors

When you create a front door template for a virtual server, the path for that template should consist of the unique domain-path for that virtual server. For example, \Domain1. (You do not need to use fdcurl to map documentation root of your virtual server to a particular CURL.)
Virtual Hosting and Development

Topics include:
Setting Up Development CASs Creating Templates Submitting Static Files
This section describes ways that virtual hosting impacts StoryServer development. As the administrator who sets up virtual hosting, you should make sure that any template developers and people who submit static files are aware of the requirements caused by virtual hosting.
03/01/99
E-9
Setting Up Development CASs

If you configure your live CAS to use virtual servers, and if you want to mirror your live environment for testing, youll need to configure your development CAS with virtual servers as well. You set up a development CAS with virtual servers as described in the section Configuring Web Servers on page E-3. In addition, if you want to perform development tasks such as preview, login (or any other activity that requires a system template), you need to modify the paths for various system templates in order to have them work within your development environment. System templates include such templates as the Production Engine Login Screen, Profiling and Personalization Stats, and so on, and are located in the System and Applications projects. Youll need to add to the list of paths for each template a new template path for each virtual server. For example, suppose you have two virtual servers with these unique document directories:
C:\DocRoot\Domain1 C:\DocRoot\Domain2
By default, the path for the Production Engine Login Screen template is /vgn/login. To work with the above two virtual servers, you would need to add the following paths for the Login template:
/Domain1/vgn/login /Domain2/vgn/login
You should retain the default path, /vgn/login, in case you set up a development CAS without virtual servers configured.
Creating Templates
When you create templates, you need to be sure to specify the correct template paths for the appropriate virtual web servers youve defined. In addition, the CURL command provides two keywords to enable you to reference across virtual web servers. For more information, see Template Fundamentals, Template Cookbook, or CURL in the Template Command Reference.
Submitting Static Files

Since virtual servers each use a unique subdirectory in the web server document root, its important to specify the correct path when submitting
E-10
03/01/99
static files to a system configured with virtual servers. If you want to use a static file on more than one virtual server, you need to submit that file multiple times, once for each virtual server that will use the file. For example, assume the /Domain1 and /Domain2 virtual servers. If you want to submit the static file logo.gif only for Domain1, youd submit the file once, with a path such as /Domain1/images/logo.gif. If you want to use the file in both domains, youd submit the file twice:
For Domain1, youd use the path /Domain1/images/logo.gif For Domain2, youd use the path /Domain2/images/logo.gif
03/01/99
E-11
E-12
03/01/99
Index
Symbols
%2f (in template path) B-20, B-38 .vgn subdirectory 6-21, B-19, B-32
B
Base Project adding owners 5-6 cant delete 13-26 management ID 13-19 owners 5-3, 5-13 bob process A-6 browser capabilities 10-2 Preferences file 6-20, B-32 Business Center authorizing users and groups 5-17, 5-18 permissions 5-18
A
Active Server Pages 10-8, 10-10 Admin Center closing tools 3-6 concepts 1-2 enabling self-registration 5-6 expanding displays 3-5 getting help 3-6 interfaces 3-4 Preferences file 6-20 sorting entries 3-5 starting tools 3-2 terms 1-2 tool directories 6-17 using tabs 5-2 admin command (CAS) A-3 location 8-4 start subcommand 8-6 stop subcommand 8-6 update_pmcfg subcommand 8-11 updatepe subcommand 8-12 verify subcommand 8-13 admin command (CMS) A-5 location 8-3 start subcommand 8-4 stop subcommand 8-4 administration features setting page generation timeouts 11-7, 12-3 authorizations for transferring projects 13-33
C
Cache Manager cmd process A-8 cmd.log file B-5 cmd.pid file B-6 CMD_POOL_SIZE variable 11-12, 12-10 process id file B-6 CAS adding 9-8, 9-10 admin command location 8-4 allowing IP addresses 11-15, 12-13 Cache Manager A-8 configuration file 6-6 copy of pm.cfg 6-7 copying static files 9-9, 9-10 database information 4-5 deleting demo project 9-16, 9-18 delivery.tcl file 6-7 demo project 9-16 development mirroring live E-10 error logging 6-15 file location 6-2 files and directories 6-8
03/01/99
Index-1
Index
flushing cache 10-8 general information 4-5 information 4-4 log files 6-8 mapping front door CURL 10-2 outside a firewall C-5 Page Generator A-11 Placement Manager A-23 pm.cfg file 6-7 preview preferences file 6-19 process details 4-6 process information 4-6 process name 3-5 removing 9-14 resetting processes 8-2 restoring demo project 9-16 restricting access 11-13, 12-11 setting page generation timeouts 11-6 setting up virtual hosting E-1 setting variables B-33 starting processes 8-6 starting services 8-6 starting using Start menu 8-9 static files B-44 stopping processes 8-6 stopping services 8-6 stopping using Start menu 8-9 StoryServer.cfg file 6-6, 11-4 StoryServer.errors file 6-15 Template Manager A-30 turning off database password encryption 7-7 updating CMS 8-12 updating remote 8-9 updating remote CAS 8-11 verifying process version 8-13 VhsProtoDocRoot directory 9-10 viewing information on 4-4 viewing process information 4-6 ci_mgmt_id A-14, A-20, A-38 CLEAR_CACHE command A-15
cmd process A-8 cmd.log file B-5 cmd.pid file B-6 CMD_ACTION DELETE A-15 RENAME A-15 CMD_POOL_SIZE variable 11-12, 12-10 CMS admin command location 8-3 allowing IP addresses 11-14, 12-12 configuration file 6-3, B-29 details 4-2 dispatcher A-6 file location 6-2 files 6-4 increasing request handling 11-11, 12-8 IP-aliasing firewalls C-10 log file B-31, B-41 pm.cfg file 6-3, 11-2 pm.log file B-31 request handler A-40 request handler directory B-44 restricting access 11-13, 12-11 service dependency 9-2 setting VHS_PORT C-10 slave process id file B-42 starting processes 8-4 starting sequence 9-3 starting services 8-4 starting using Start menu 8-8 stopping processes 8-4 stopping services 8-6 stopping to disconnect 8-5 stopping using Start menu 8-8 ted.log file B-37 timed-event process A-29 timed-event process log B-37 updating 8-12, 11-5 vhs process A-40 vhs.log file B-41
Index-2
03/01/99
Index
vhs.log.id file B-42 VhsProtoDocRoot directory B-44 viewing information on 4-2 commands encrypt 7-8 RESET_TIMEOUT 11-7, 11-8, 12-4, 12-5 transferproject 13-1 common variables 1-5 COMPONENT command 10-3 config script A-9 adding CAS 9-10 deleting demo project 9-18 removing CAS 9-14 restoring demo project 9-19 configuration database password encryption 7-6 of StoryServer platform A-9, A-25 setting page generation timeouts 11-7, 12-3 configuration file influence 6-11 interaction 6-10 interaction on single host 6-12 interaction with multiple hosts 6-14 Content Management Servers transferring projects between 13-1 turning off database password encryption 7-7 contents of transferproject project package 13-35 cshprofile file D-2 ctld process A-11 ctld.log file B-6 ctld.log.id file B-8 ctld.pid file B-10 CTLD_EVAL_TIMEOUT variable, difference from previous releases 11-7, 12-4 CTLD_LOG_LEVEL variable 11-9, 12-6
CTLD_POOL_SIZE variable 11-5, 12-2 ctldinfo.log file B-11 ctldinfo.log.id file B-13 CURL command E-10
D
database adjusting server settings 11-9, 12-7 backing up GroupLens Express D-5 content types 1-3 disabling access 8-13 password encryption 7-5 permissions 7-3 service dependency 9-2 service variables 9-2 tables 7-3 database environment variables for transferproject command 13-17 database password encryption changing the password 7-9 encrypt command 7-8 in templates 7-9 keywords to search for in templates 7-9 overriding configuration in templates 7-10 turning off 7-7 turning on 7-8 deleting database content with transferproject 13-26 deleting project data with transferproject 13-26 delivery.tcl interaction with StoryServer.cfg 6-12 delivery.tcl file 6-7, 9-5, B-15 vdbmsg variable for Solaris 12-8 Demonstration Project deleting 9-16 Demonstration project restoring 9-17
03/01/99
Index-3
Index
Development Center permissions 5-19 dist directory with transferproject command 13-36 docroot directory B-17 setting up for virtual hosting E-3 DOCROOT variable 9-10, 9-11
G
GL_DBROOT variable D-5 group adding entry 5-13 Admin 5-2 attributes 5-4 cloning entry 5-16 deleting entry 5-16 editing entry 5-14 reserved ID 5-2 viewing information 5-2 GroupLens Express getting status D-4 managing D-2 starting D-2 stopping D-3
E
e-mail enabling notifications 5-12 SMTP host 5-11 encrypt command 7-8 encryption database password 7-5 in templates 7-9 environment variables to set for transferproject command on Solaris 13-16 error logging levels 6-15 error messages archiving 6-16 viewing 6-16 errors on Solaris syslogd(1M) 6-15 Event Viewer 6-16 EventLog service 6-15 exporting project data with transferproject 13-19, 13-20
H
Help menu 3-6 host-port-number variable 1-5 HTTP proxy server C-11 HTTPD_COMPONENTSCAN variable 10-4 HTTPD_FDCURL variable 10-2 HTTPD_LOG_BY_PID variable B-28 HTTPD_PLUGIN_LOG_LEVEL variable B-28 HTTPD_TIMEOUT variable, not in this release 11-6, 12-3
F
-f option to transferproject command 13-35 files in transferproject project package 13-12, 13-35 firewall C-2 flushcache command 10-8, A-14 CMD_ACTION variable A-15
I
id variable 1-5 IIS disabling parsing 10-6 importing project data with transferproject command 13-21 importing projects, conflicts 13-18
Index-4
03/01/99
Index
INCLUDE LIB command and transferring projects 13-28 Informix database permissions 7-3 INFORMIXDIR and INFORMIXSERVER environment variables for transferproject command 13-17 install-path variable 1-5 InstallShield platform configuration 9-6 Internal-use-only template launch A-20 IP address, for virtual hosting E-3 IUSR_hostname 10-7
preferences file B-19 macrodata file 6-19, B-19 MAX_LOG_SIZE variable B-28 metafiles directory B-20 Microsoft SQL Server database permissions 7-3 moving the transferproject project package 13-27 Music a la Mode 9-16
N
Net Perceptions GroupLens Express D-2 Netscape NSAPI configuration file B-21 next_id table with transferproject command 13-11, 13-28 nobody reserved id 4-3, 5-2 Notepad 11-3 NSAPI obj.conf file B-21
K
-k option to transferproject command 13-23 when to use 13-24 keywords to find in templates for password encryption 7-9
L
lastsession.cfg file B-18 launch command A-19 LD_LIBRARY_PATH environment variable for transferproject command 13-17 listiis utility E-6 LOG command B-6, B-9 login defaults file B-32 logroller command 6-16, A-21
O
obj.conf file B-21 Observation Manager removing on Solaris 9-12 removing on Windows NT 9-12 online help 3-6 Oracle database permissions 7-3 ORACLE_HOME environment variable for transferproject command 13-17
M
Macro Editor
P
pad process A-23 pad.log file B-22
03/01/99
Index-5
Index
pad.log.id file B-24 pad.pid file B-25 PAD_POOL_SIZE variable 11-11, 12-8 PadArchivesDir directory B-22 PadWorkDir directory B-26 page generation disabling 8-14 enabling 8-15 Page Generator adjusting 11-5 adjusting logging 11-9, 12-6 ctld process A-11 ctld.log file B-6 ctld.log.id file B-8 ctld.pid file B-10 CTLD_POOL_SIZE variable 11-5, 12-2 ctldinfo.log file B-11 ctldinfo.log.id file B-13 delivery.tcl file B-15 HTTPD_TIMEOUT variable not in this release 11-6, 12-3 increasing requests 11-5, 12-2 increasing slave processes 11-5, 12-2 master process log file B-11 process id file B-10 resetting 8-2 setting timeout in StoryServer.cfg 11-7, 12-3 setting timeout in templates 11-8, 12-5 slave process log file B-13 templates directory B-38 timeouts 11-6 parse-html function 10-3 password for database 7-5 setting admin 5-8 PASSWORD variable, encryption 7-9 Placement Manager log file B-22 pad process A-23
pad.log file B-22 pad.log.id file B-24 pad.pid file B-25 PadArchiveDir directory B-22 PadWorkDir directory B-26 process id file B-25 slave process id file B-24 Platform Configuration Program accessing 9-6 adding CAS 9-8 default editor 11-3 editing config files 11-2 removing CAS 9-14 plugin.log B-27 pm.cfg file 6-3, B-29 CAS copy 6-7 database password encryption 7-5 editing on Windows NT 11-2 increasing request handling 11-11, 12-8 SYSTEM_DB_PASSWORD_ENCR YPTED 7-7 SYSTEM_DB_PASSWORD_ENCR YPTED variable 7-6 testing changes 11-2 TEXTSIZE variable 11-9, 12-7 update_pmcfg subcommand 8-11 updating remote CASs 8-9 pm.log file B-31 PM_LOG_LEVEL variable B-31 Preferences file 6-20, B-32 Production Center archiving log files 6-16 enabling self-registration 5-6 flushcache command 10-8, A-14 inboundmail command A-16 launch command A-19 logroller command A-21 macrodata file B-19 Preferences file 6-20 setting e-mail preferences 5-11
Index-6
03/01/99
Index
tool directories 6-17 transferproject command A-31 program task flushcache command A-14 inboundmail command A-16 launch command A-19 logroller command A-21 project IDs with transferproject command 13-18 project package with transferproject command 13-9 contents 13-35 description of files 13-11 dist directory 13-36 moving 13-27 project_mgmt_id A-14, A-20, A-38 projects Base Project management ID 13-19 finding IDs 13-18 StoryServer project data and database content 13-10 transferring between CMSs 13-1 PROXY_HOST variable C-14 PROXY_PORT variable C-14
S
schema restrictions for import with transferproject command, checking 13-25 self-registration enabling 5-6 setting platform variables 9-5 setup program A-25 shprofile file D-2 SMTP host 5-11 SMTP server 4-3 SOCKS proxy server C-15 ss command A-25 static files B-44 copying 9-9, 9-10 status of transferred content items 13-34 StoryServer admin tasks 2-2 configuring CAS A-9, A-25 content types 1-3 database 7-2 database tables 7-3 diasabling database access 8-13 disabling page generation 8-14 documentation B-17 enabling page generation 8-15 enabling self-registration 5-6 file base location 6-2 log files 6-15 managing page generation 8-13 preference files 6-20 session outside a firewall C-7 sessions and SOCKS on Solaris C-18 sessions and SOCKS on Windows NT C-17 setting variables B-33 tool directories 6-17 web server module B-28 StoryServer authorizations for transferring projects 13-33
R
-r option to transferproject command 13-20 remote operations C-2 request handler directory B-44 requirements and restrictions for transferring projects between CMSs 13-2 RESET_TIMEOUT command 11-7, 11-8, 12-4, 12-5 syntax 11-8, 12-5 Rn variable 1-5 root mapping front door 10-2
03/01/99
Index-7
Index
StoryServer platform configuring A-9, A-25 remote operations C-2 setting variables 9-5 tasks 9-1 StoryServer Platform Configuration Program A-25 accessing 9-6 adding CAS 9-8 default editor 11-3 editing config files 11-2 removing CAS 9-14 StoryServer.cfg interaction with delivery.tcl 6-12 StoryServer.cfg file 6-6 adjusting CMD_POOL_SIZE variable 11-12, 12-10 adjusting CTLD_EVAL_TIMEOUT 11-6, 12-3 adjusting CTLD_LOG_LEVEL 11-7, 11-9, 12-6 adjusting CTLD_POOL_SIZE 11-5, 12-2, 12-4 adjusting PAD_POOL_SIZE 11-11, 12-9 adjusting timeouts 11-7, 12-3 database password encryption 7-6 editing on Windows NT 11-4 HTTPD_TIMEOUT variable 11-6, 12-3 testing changes 11-4 updatepe subcommand 8-12 vdbmsg(password_encrypted) variable 7-6, 7-8 StoryServer.errors file 6-15, B-35 StoryServern variable 1-5 Sybase database permissions 7-3 SYBASE environment variable for transferproject command 13-17 syntax of transferproject command 13-13
syslogd(1M) 6-15 system reserved id 5-2 SYSTEM_DB_PASSWORD_ENCRYPT ED variable 7-6, 7-7 setting in templates 7-10
T
tar format with transferproject command 13-35 TasksWorkingDirsRoot directory B-35 ted process A-29 directory B-36 ted.log file B-36 TED_LOG_LEVEL variable B-37 Template Developer Preferences file 6-20 Template Editor macro preferences file B-19 template location B-20, B-38 Template Manager log file B-39 process id file B-40 resetting 8-2 templates directory B-38 tmd process A-30 tmd.log file B-39 tmd.pid file B-40 templates database password encryption 7-9 encryption 7-9 overriding configuration for database password encryption 7-10 setting SYSTEM_DB_PASSWORD_ ENCRYPTED variable 7-10 using RESET_TIMEOUT command 11-8, 12-5
Index-8
03/01/99
Index
vdbmsg(password_encrypted) variable 7-10 templates directory B-38 TEXTSIZE variable 11-9, 12-7 timed-event process A-29 directory B-35 timed-event process log B-36 timeouts for the web server 11-7, 12-5 setting for Page Generator 11-6, 11-7, 12-3 tmd process A-30 tmd.log file B-39 tmd.pid file B-40 TMD_LOG_LEVEL variable B-40 tool directories Macintosh 6-18 Solaris 6-18 Windows 6-17 transferproject command 13-1, A-32 Base Project management ID 13-19 cant delete Base Project 13-26 Content Design Objects 13-13 data collections 13-13 deleting database content 13-26 deleting project data 13-26 dist directory 13-36 environment variables on Solaris 13-16 exporting project data 13-19 exporting project data and database content together 13-20 -f option 13-35 finding project IDs 13-18 form sets 13-13 importing project data with transferproject 13-21 INFORMIXDIR and INFORMIXSERVER environment variables 13-17 -k option 13-23, 13-24 keywords
projects 13-30 records 13-32 templates 13-31 LD_LIBRARY_PATH environment variable 13-17 moving the project package 13-27 next_id table 13-11 options A-32 ORACLE_HOME environment variable 13-17 project data and database content 13-10 project package 13-9 -r option 13-20 requirements and restrictions 13-2 status of transferred content items 13-34 StoryServer authorizations 13-33 SYBASE environment variable 13-17 syntax 13-13, A-32 what project and content item properties are transferred 13-29 transferring projects between CMSs 13-1 contents of project package 13-35 deleting content data 13-26 deleting project data 13-26 environment variables to set on Solaris 13-16 exporting project data 13-19 exporting project data and database content together 13-20 files in project package 13-12 import conflicts 13-18 importing project data 13-21 items that must be unique 13-18 moving the project package 13-27 next_id table 13-11 overview 13-4 permissions, user IDs, and authorizations 13-16 project package 13-9, 13-11 properties that are transferred,
03/01/99
Index-9
Index
inherited, and replaced 13-29 requirements and restrictions 13-2 schema restrictions 13-25 sequence 13-9 statuses of transferred content items 13-34 StoryServer authorizations 13-33 StoryServer project data and database content 13-10 syntax of transferproject command 13-13 tar and zip format 13-35 things to do after transferring 13-28 types of transfer 13-9
U
user adding entry 5-6 admin 5-2 attributes 5-4 cloning entry 5-9 deleting entry 5-10 editing entry 5-8 e-mail preferences 5-11 enabling self-registration 5-6 name guidelines 5-5 reserved IDs 5-2 viewing information 5-2
vgn subdirectory 6-21, B-19, B-32 vhs process A-40 vhs.log file B-41 vhs.log.id file B-42 VHS_LOG_LEVEL B-41 VHS_LOG_LEVEL variable B-43 VHS_POOL_SIZE variable 11-11, 12-8 VHS_PORT variable C-10 VhsProtoDocRoot directory 9-10, B-44 Vignette Cache Manager A-8 Vignette Dispatch Service A-6 Vignette Event Service A-29 Vignette Page Generator A-11 Vignette Placement Agent A-23 Vignette Request Service A-40 Vignette subdirectory 6-21, B-19, B-32 Vignette Template Manager A-30 virtual hosting configuring E-1 virtual server development CAS E-10 front door E-9 static files E-11
W
web browser docroot directory B-17 web server adjusting processes 11-13, 12-11 configuring virtual hosting E-2 disabling IIS parsing 10-6 disabling Netscape parsing 10-3 mapping front door 10-2 parse-html function 10-3 parsing on Apache 10-8 preview preferences file 6-20 setting the timeout 11-7, 12-5 timeout 11-6, 12-3 web server module
V
variable settings 11-1, 12-1 variables for GroupLens Express D-2 variations 10-2 vdbmsg(maxtext) variable 12-8 vdbmsg(password_encrypted) variable 7-6 overriding in templates 7-10 version command A-35 project task defaults A-38 workflow task defaults A-38
Index-10
03/01/99
Index
error log B-28
Z
zip format with transferproject command 13-35
03/01/99
Index-11

Vignette Administartion

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Vignette Administartion

Enviado por

Direitos autorais:

Formatos disponíveis

Administration Guide

Send Us Your Comments

2 Roadmaps for Getting Started

3 Understanding the Admin Center Tools

4 Monitoring StoryServer Servers and Processes

5 Managing StoryServer Users and Groups

6 Managing StoryServer Files on Windows NT or Solaris

7 Working with the Database on Windows NT or Solaris

8 Managing StoryServer Processes on Windows NT or Solaris

9 Managing StoryServer on Windows NT and Solaris

Working with Web Servers on Windows NT or Solaris

Tuning StoryServer on Windows NT

Tuning StoryServer on Solaris

Transferring Projects between Content Management Servers

A StoryServer Process Reference

B StoryServer File Reference

D Managing GroupLens Express

Configuring Virtual Hosting

Before you begin, make sure that:

Using This Book

Admin Center tools and instructions for using:

Concepts and Terms

Web Site team uses StoryServer tools

Common Path Name Variables

NT D:\Program Files\Vignette S UN /opt

Identification number assigned to a slave process when it was spawned.

Roadmaps for Getting Started on page 2-1

Roadmaps for Getting Started

Before you begin:

Roadmaps for Getting Started

Managing StoryServer Users and Groups on page 5-1

Roadmaps for Getting Started

What to do Set StoryServer-wide variables and procedures.

Establishing Service Dependencies for CMS/CASWindows NT only on page 9-2

Authorizing Business Center Users on page 5-17

Authorizing Development Center Users on page 5-18

Removing a CAS on page 9-13

Roadmaps for Getting Started

What to do Manage StoryServer files.

Fine tune your web server.

Manage StoryServer processes.

Understand the StoryServer database.

Delete or restore the Vignette Demonstration Project.

Managing the Demonstration Project on page 9-15

Adjust StoryServer variables.

Transfer projects from one CMS to another.

Configure StoryServer hosts outside the firewall.

Roadmaps for Getting Started

What to do Configure the Observation Manager and GroupLens Express.

For information, see Managing GroupLens Express on page D-1

Set up virtual hosting.

Configuring Virtual Hosting on page E-1

Understanding the Admin Center Tools on page 3-1

Roadmaps for Getting Started

Understanding the Admin Center Tools

Before you begin:

Understanding the Admin Center Tools

Starting StoryServer Admin Center Tools

Understanding the Admin Center Tools

Configuration View primary window

Understanding the Admin Center Tools

User/Group Manager primary window

Using the Tools on page 3-4