Vignette Administartion

Administration Guide

Version 4.2

ii 03/01/99

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 [email protected]. A member of the Publications team will acknowledge your mail as soon as possible.

You can also reach us at the following address:

Vignette Corporation901 South Mo Pac ExpresswayBuilding IIIAustin, TX 78746-5776

03/01/99 iii

Contents

1 Basic ConceptsUsing This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2Concepts and Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2

Content Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3Common Path Name Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5

2 Roadmaps for Getting StartedRoadmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2

3 Understanding the Admin Center ToolsStarting StoryServer Admin Center Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2Using the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4

Sorting Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5Expanding Server Entries in Configuration View . . . . . . . . . . . . . . . . . . . . . .3-5

Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6

4 Monitoring StoryServer Servers and ProcessesViewing CMS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Viewing CAS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

CAS Information in the Primary Window . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4CAS Information in the Details Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

Viewing CAS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6CAS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . . .4-6CAS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . . .4-7

5 Managing StoryServer Users and GroupsOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2Understanding Reserved User IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2Monitoring Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3

Viewing User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4Viewing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5Rules for User Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5

Contents Administration Guide

iv 03/01/99

Enabling Self-registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6Adding a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6Editing a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8Cloning a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9Deleting a User Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10Setting E-mail Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10

Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13Rules for Group Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13Adding a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13Editing a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14Cloning a Group Entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16Deleting a Group Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

Authorizing Business Center Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17Authorizing Development Center Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18

6 Managing StoryServer Files on Windows NT or SolarisOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

Overview of Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3CMS Configuration File (pm.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3Other CMS Files and Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4CAS Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6Other CAS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8Understanding Configuration File Interaction . . . . . . . . . . . . . . . . . . . . . . . .6-10

Viewing StoryServer Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14Viewing the EventLog Event Viewer on Windows NT . . . . . . . . . . . . . . . . .6-16Archiving the StoryServer.errors file on Solaris . . . . . . . . . . . . . . . . . . . . . .6-16

Understanding Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17Windows Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17Solaris Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18Macintosh Tool Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18

Understanding Preference Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19macrodata File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19Preferences File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20File Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-21

Administration Guide Contents

03/01/99 v

7 Working with the Database on Windows NT or SolarisOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2

Database Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3Database Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3

Understanding StoryServer Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3Database Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6Encryption in Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9

8 Managing StoryServer Processes on Windows NT or SolarisResetting CAS Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2Locating admin Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3

CMS admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3CAS admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4

Stopping and Starting the CMS with the admin Command . . . . . . . . . . . . . . . . .8-4Stopping and Starting the CAS with the admin Command . . . . . . . . . . . . . . . . . .8-6Stopping and Starting with the Start Menu Options—Windows NT only . . . . . .8-8

Stopping and Starting a CMS from the Start Menu. . . . . . . . . . . . . . . . . . . . .8-8Stopping and Starting a CAS from the Start Menu . . . . . . . . . . . . . . . . . . . . .8-9

Updating a Remotely Installed CAS—Windows NT only . . . . . . . . . . . . . . . . . .8-9Updating a Remotely Installed CAS—Solaris only . . . . . . . . . . . . . . . . . . . . . .8-11Notifying the CMS of changes to StoryServer.cfg—Solaris only. . . . . . . . . . . .8-12Verifying CAS Processes—Solaris only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13Managing Page Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13

Disabling StoryServer Page Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14Enabling StoryServer Page Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15

9 Managing StoryServer on Windows NT and SolarisEstablishing Service Dependencies for CMS/CAS—Windows NT only . . . . . . .9-2Setting Up StoryServer-wide Variables and Procedures. . . . . . . . . . . . . . . . . . . .9-5Accessing the Platform Configuration Program—Windows NT only . . . . . . . . .9-6

From the Start Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6From the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7From the Command Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7

Adding a CAS and Copying Static Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8Adding a CAS and Copying Static Files on Windows NT . . . . . . . . . . . . . . .9-8


vi 03/01/99

Adding a CAS and Copying Static Files on Solaris . . . . . . . . . . . . . . . . . . . .9-10Removing an Observation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11

Removing an Observation Manager on Windows NT . . . . . . . . . . . . . . . . . .9-12Removing an Observation Manager on Solaris . . . . . . . . . . . . . . . . . . . . . . .9-12

Removing a CAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13Removing a CAS on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14Removing a CAS on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15

Managing the Demonstration Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15Deleting the Vignette Demonstration Project on Windows NT . . . . . . . . . . .9-16Restoring the Vignette Demonstration Project on Windows NT . . . . . . . . . .9-17Deleting the Vignette Demonstration Project on Solaris . . . . . . . . . . . . . . . .9-18Restoring the Vignette Demonstration Project on Solaris . . . . . . . . . . . . . . .9-19

10 Working with Web Servers on Windows NT or SolarisMapping the Root Path (/) to a Front Door CURL . . . . . . . . . . . . . . . . . . . . . . .10-2Working with Web Server Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

StoryServer Changes to obj.conf File on Netscape . . . . . . . . . . . . . . . . . . . .10-3Disabling Parsing on Netscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4Optimizing parse-html on Netscape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6Parsing on IIS 4—Windows NT only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6Parsing on Apache—Solaris only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8

Clearing Pages from a Root Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8Using .asp Scripts in Templates—Windows NT only. . . . . . . . . . . . . . . . . . . .10-10

11 Tuning StoryServer on Windows NTEditing the Configuration Files on Windows NT . . . . . . . . . . . . . . . . . . . . . . . .11-2

Editing the pm.cfg File on Windows NT. . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2Editing the StoryServer.cfg File on Windows NT. . . . . . . . . . . . . . . . . . . . .11-3

Increasing Page Generator Requests on Windows NT . . . . . . . . . . . . . . . . . . . .11-5Adjusting Page Generator Timeouts on Windows NT . . . . . . . . . . . . . . . . . . . .11-6

Changes from Previous Releases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6Setting Page Generation Timeouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7RESET_TIMEOUT Template Command . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8

Adjusting Page Generator Logging on Windows NT. . . . . . . . . . . . . . . . . . . . .11-9Adjusting for Large Database Retrievals on Windows NT. . . . . . . . . . . . . . . . .11-9Increasing Request Handling on Windows NT. . . . . . . . . . . . . . . . . . . . . . . . .11-11


03/01/99 vii

Setting the Thread Pool Size for the Cache Manager on Windows NT . . . . . .11-12Restricting Access to the Servers on Windows NT. . . . . . . . . . . . . . . . . . . . . .11-13

Setting Allowed IP Addresses for the CMS. . . . . . . . . . . . . . . . . . . . . . . . .11-14Setting Allowed IP Addresses for a CAS . . . . . . . . . . . . . . . . . . . . . . . . . .11-15

12 Tuning StoryServer on SolarisIncreasing Page Generator Requests on Solaris . . . . . . . . . . . . . . . . . . . . . . . . .12-2Adjusting Page Generator Timeouts on Solaris . . . . . . . . . . . . . . . . . . . . . . . . .12-3

Changes from Previous Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3Setting Page Generation Timeouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3RESET_TIMEOUT Template Command . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5

Adjusting Page Generator Logging on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . .12-6Adjusting for Large Database Retrievals on Solaris . . . . . . . . . . . . . . . . . . . . . .12-7Increasing Request Handling on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8Setting the Thread Pool Size for the Cache Manager on Solaris. . . . . . . . . . . .12-10Restricting Access to the Servers by IP address on Solaris. . . . . . . . . . . . . . . .12-11

Setting Allowed IP Addresses for the CMS. . . . . . . . . . . . . . . . . . . . . . . . .12-12Setting Allowed IP Addresses for a CAS . . . . . . . . . . . . . . . . . . . . . . . . . .12-13

13 Transferring Projects between Content Management ServersOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2How Transfer Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4

Exporting and Importing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4Typical Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-9StoryServer Project Data and Database Content . . . . . . . . . . . . . . . . . . . . .13-10Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-11Transferring Content Design Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13

transferproject Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13Transferring Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-16

transferproject Permissions and Other Requirements . . . . . . . . . . . . . . . . .13-16Setting Environment Variables on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . .13-16Import Conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18Finding Project IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18Exporting StoryServer Project Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-19Exporting StoryServer Project Data and Database Content Together . . . . .13-20Importing StoryServer Project Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21


viii 03/01/99

Exporting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-22Importing Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-23Deleting StoryServer Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-26Deleting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-26Moving a Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-27

Things to Do after Transferring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-28What’s Transferred and What Isn’t. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-29General Information about Transferring Projects . . . . . . . . . . . . . . . . . . . . . . .13-33

StoryServer Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-33Parent Project and Status of Imported Content Items . . . . . . . . . . . . . . . . .13-34Contents of Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-35

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

B StoryServer File ReferenceFile Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2


03/01/99 ix

cmd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5cmd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6ctld.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6ctld.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8ctld.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10ctldinfo.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11ctldinfo.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13delivery.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15docroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-17lastsession.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18macrodata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19metafiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20obj.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21PadArchiveDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22pad.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22pad.log.id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-24pad.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-25PadWorkDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-26plugin.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-27pm.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-29pm.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-31Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-32StoryServer.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-33StoryServer.errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35TasksWorkingDirsRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35ted.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-36templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-38tmd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-39tmd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-40vhs.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-41vhs.log.id. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-42VhsProtoDocRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-44

C Remote OperationsOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2CAS Outside the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5


x 03/01/99

StoryServer Sessions Outside the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7Setting the VHS_PORT Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10Working with IP-aliasing Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10

Outbound Connections via HTTP Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-11StoryServer Sessions Using SOCKS Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . C-15

StoryServer Sessions and SOCKS on Windows NT . . . . . . . . . . . . . . . . . . C-17StoryServer Sessions and SOCKS on Solaris . . . . . . . . . . . . . . . . . . . . . . . C-18

D Managing GroupLens ExpressOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2Starting GroupLens Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2

On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3

Stopping GroupLens Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4

Getting Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4

Backing Up the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4On Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-5On Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-5

E Configuring Virtual HostingConcepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2

How Virtual Hosting Works With StoryServer . . . . . . . . . . . . . . . . . . . . . . . E-2Configuring Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-3

Netscape Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-4Microsoft IIS 4 Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-5Apache Web Servers—Solaris Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-7

Testing the Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-9Setting Up Development CASs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10Creating Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10Submitting Static Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10

Index

03/01/99 1-1

1 Basic Concepts

Summary: Basic concepts for administering StoryServer and a high-level view of tasks.

Audience: 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

Topics include: • Using This Book• Concepts and Terms

Basic Concepts Administration Guide

1-2 03/01/99

Using This BookThis 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 command-line 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 TermsThis book uses the concepts and terms found in Running StoryServer Tools. It also uses the following concepts and terms to explain StoryServer administration.

Administration Guide Basic Concepts

03/01/99 1-3

Content Types

StoryServer handles content stored in two ways: in the database and in the file system.

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.

Database content Content that you can sort by database queries. Ideally this includes much of your site content.

File system content

Content stored directly in the file system, including such static files as graphics, audio, and HTML files that don’t change or don’t need templates. The web server configured with a CAS delivers these static files in the conventional way.


1-4 03/01/99

Figure 1-1: StoryServer Components

StoryServerDB Live

CAS

http://freya.nd.com:80

WebServer

INTERNET

Router/Firewall

/DocRoot

DevelopmentCAS

http://saga.nd.com:8085

WebServer

/DocRoot

CMServer

saga:7007

Web Site team uses StoryServer tools

Administration Guide Basic Concepts

03/01/99 1-5

Common Path Name Variables

The common file location (path name) variables used in this book include:

Variable Indicates...

install-path The path name of the folder or directory in which the StoryServer CMS or CAS or tools software has been previously installed.

For example:

• NT D:\Program Files\Vignette

• SUN /opt

StoryServer n On Windows NT, the release number of the StoryServer software. For example, StoryServer 4.

Rn The version number of the StoryServer software. For example, R4.2.

NT conf-n

SUN conf

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.

host-port-number 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


1-6 03/01/99

03/01/99 2-1

2 Roadmaps for Getting Started

Summary: Two tables for helping you get underway with the Admin Center.


Before you begin: Basic Concepts on page 1-1

Roadmaps for Getting Started Administration Guide

2-2 03/01/99

RoadmapsThe 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 command-line 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 Description For information, see

Familiarize yourself with the Admin Center Tools.

Take some time to learn the Admin Center interface.

Understanding the Admin Center Tools on page 3-1

Create a password for the admin user ID and (optionally) the guest user ID.

The admin user and members of the Admin group have wide-ranging privileges. Carefully control administrator authorization.

Editing a User Entry on page 5-8

Create user entries and a separate group entry (recommended) for the owners of the Base Project in the Production Center tool set.

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.

Managing StoryServer Users and Groups on page 5-1

Determine whether self- registration should be allowed.

Allow self-registration if users unknown to the database should be able to log in to StoryServer.

Enabling Self-registration on page 5-6

Set electronic mail preferences.

Project owners assign tasks to users, and the users are notified by e-mail. In the Configuration View, an admin user can set e-mail preferences which affect all users listed in the currently connected CMS.

Setting E-mail Preferences on page 5-10

Administration Guide Roadmaps for Getting Started

03/01/99 2-3

The following table is not arranged sequentially. The list represents a variety of procedures that the admin user might perform.

Set StoryServer-wide variables and procedures.

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.

Setting Up StoryServer-wide Variables and Procedures on page 9-5


View and modify configuration information for the CMS, CAS, and CAS processes.

The Configuration View provides a quick source of information about the various servers and processes running on your system.

Monitoring StoryServer Servers and Processes on page 4-1

Create more CASs. 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.

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.

Certain services cannot start correctly unless the database service is already running.

Establishing Service Dependencies for CMS/CAS—Windows NT only on page 9-2

If you are using the Business Center tools, establish authorization for users to operate in the visitor database.

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

If you are using the Development Center tools, establish authorization for users of the Content Designer.

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.

Authorizing Development Center Users on page 5-18

Remove a CAS. Note that if an Observation Manager has been configured, you must remove it before removing the CAS itself.

Removing a CAS on page 9-13



2-4 03/01/99

Manage StoryServer files. When you install and configure the software and toolsets, StoryServer creates directories and files used by the various processes.

Managing StoryServer Files on Windows NT or Solaris on page 6-1 and StoryServer File Reference on page B-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.

Working with Web Servers on Windows NT or Solaris on page 10-1

Manage StoryServer processes.

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.

Managing StoryServer Processes on Windows NT or Solaris on page 8-1 and StoryServer Process Reference on page A-1

Understand the StoryServer database.

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.

Working with the Database on Windows NT or Solaris on page 7-1

Delete or restore the Vignette Demonstration Project.

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.

Managing the Demonstration Project on page 9-15

Adjust StoryServer variables.

You can modify variable settings to increase performance or adjust for different content or products you might be accessing.

Tuning StoryServer on Windows NT on page 11-1 or Tuning StoryServer on Solaris on page 12-1

Transfer projects from one CMS to another.

If your company has multiple StoryServer CMSs, you may need at times to transfer—copy—a project from one CMS to another.

Transferring Projects between Content Management Servers on page 13-1

Configure StoryServer hosts outside the firewall.

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.

Remote Operations on page C-1


Administration Guide Roadmaps for Getting Started

03/01/99 2-5

Configure the Observation Manager and GroupLens Express.

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.

Managing GroupLens Express on page D-1

Set up virtual hosting. Virtual hosting allows you to set up one CAS to serve multiple virtual web servers.

Configuring Virtual Hosting on page E-1

See also Understanding the Admin Center Tools on page 3-1



2-6 03/01/99

03/01/99 3-1

3 Understanding the Admin Center Tools

Summary: Overview of the StoryServer Admin Tools.


Before you begin: • Basic Concepts on page 1-1• Roadmaps for Getting Started on page 2-1

Topics include: • Starting StoryServer Admin Center Tools• Using the Tools• Getting Help• Closing Admin Center Tools

Understanding the Admin Center Tools Administration Guide

3-2 03/01/99

Starting StoryServer Admin Center Tools

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.


Administration Guide Understanding the Admin Center Tools

03/01/99 3-3

Figure 3-2: Configuration View primary window


3-4 03/01/99

Figure 3-3: User/Group Manager primary window

Using the Tools

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

See also Using the Tools on page 3-4


Topics include: • Sorting Entries• Expanding Server Entries in Configuration View

Administration Guide Understanding the Admin Center Tools

03/01/99 3-5

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


3-6 03/01/99

Getting Help

You can access the StoryServer 4.2 on-line manuals from a StoryServer Admin Center tool’s 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.

Closing Admin Center Tools

You can exit an individual Admin Center tool from the File menu Close option in the tool’s primary window. All the tool’s windows close.

You can also close Admin Center tools (and all other StoryServer tools open in the current session) by using the StoryServer launch bar’s 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 Closing Admin Center Tools on page 3-6


See also Managing StoryServer Users and Groups on page 5-1

Monitoring StoryServer Servers and Processes on page 4-1

03/01/99 4-1

4 Monitoring StoryServer Servers and Processes

Summary: How to use the Configuration View to view or change the servers and processes.


Before you begin: Understanding the Admin Center Tools on page 3-1

Topics include: • Viewing CMS Information• Viewing CAS Information• Viewing CAS Process Information

Note: The Configuration View primary window updates dynamically when changes are made to the StoryServer servers’ information.

Monitoring StoryServer Servers and Processes Administration Guide

4-2 03/01/99

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.

■ To view information about the CMS to which the Configuration View is currently connected:

1 In the Configuration View primary window, select the Content Management Server entry.

2 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:


Installation Name 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

SUN nemo.mycompany.com:/opt/StoryServer/Rn

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

• SUN Informix, Oracle, Sybase.

Administration Guide Monitoring StoryServer Servers and Processes

03/01/99 4-3

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.

SMTP Server 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.

E-mail Notifications 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.

Users with full authorization (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.

Users with limited authorization

(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.

Users with Content Designer authorization

(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.


4-4 03/01/99

3 Click OK or Cancel to close the window. (Clicking OK commits any changes made by an admin user.)

Viewing CAS Information

CAS Information in the Primary Window

The columns of the Configuration View primary window display the following information about each CAS:

CAS Information in the Details Window■ To view CAS information in the Configuration View primary window

1 Right-click a CAS entry and select Details from the pop-up menu.

2 Choose the corresponding tab to view General or Database information.

See also Viewing CAS Information on page 4-4

Summary: The Configuration View provides information about each CAS connected to a CMS.


Topics include: • CAS Information in the Primary Window• CAS Information in the Details Window

Name Shows the name of the CAS in host-port-number format:

• host - host name for the CAS’s web server

• port - port number for the CAS’s 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 CAS’s web server.

For example: nemo.myco.com

Port Shows the port number that the CAS’s web server uses.

Type Shows the designation of the CAS, either Development or Live


03/01/99 4-5

CAS General Information

CAS Database 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

SUN 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 server’s front door.

For example:

NT C:/InetPub/wwwroot

SUN /install/nemo/docroot/ourdocs

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

SUN 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


4-6 03/01/99

Viewing CAS Process Information

The Configuration View primary window shows the following processes for each CAS connected to the CMS:

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.

Summary: The Configuration View provides information about each CAS process.


Topics include: • CAS Process Information in the Primary Window• CAS Process Information in the Details Window

Cache Manager Maintains cached content so that only dynamic information needs to be generated from the database. See also cmd on page A-8.

Observation Manager

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.

Page Generator Interprets templates, accesses content, and generates web pages on demand. See also ctld on page A-11.

Placement Manager

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.


03/01/99 4-7

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

SUN 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.

Host Shows the host name and domain of the web server with which the process is associated.

Port Shows the port number on which the process communicates.

Status Shows OK if the process is running. (If the process is not running, an error message opens.)

See also Managing StoryServer Users and Groups on page 5-1


4-8 03/01/99

03/01/99 5-1

5 Managing StoryServer Users and Groups

Summary: You can view and change lists of users and groups through the Admin Center’s User/Group Manager.



Topics include: • Overview• Understanding Reserved User IDs• Monitoring Users and Groups• Managing Users• Managing Groups• Authorizing Business Center Users• Authorizing Development Center Users

Managing StoryServer Users and Groups Administration Guide

5-2 03/01/99

OverviewEach 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 Center’s 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 browser-accessible alternative to the Admin Center’s 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:

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.

Users Shows information about the currently valid users recognized by the StoryServer database. From this page:

• An admin user can add, edit, copy, and delete users.

• A non-admin user can edit his or her own entry.

Groups 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.


Administration Guide Managing StoryServer Users and Groups

03/01/99 5-3

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.

Monitoring Users and Groups

All users can view currently valid users and groups through the User/Group Manager.

See also Monitoring Users and Groups on page 5-3


Topics include: • Viewing User Attributes• Viewing Group Attributes


5-4 03/01/99

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:

Viewing Group Attributes

The User/Group Manager shows the following read-only information about current groups:

User The user’s 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).

Description (Optional) A full name or more descriptive information about the user.

E-mail Address (Optional) The electronic mail address of the user.

Groups (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.

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.

Description (Optional) A full name or more descriptive information about the group.

See also Managing Users on page 5-5


03/01/99 5-5

Managing Users

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.


Topics include: • 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


5-6 03/01/99

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 user’s 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.

■ 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.

2 Toggle Self Registration Allowed for StoryServer Users to Yes or No.

3 Click OK or Apply to submit the change to the database.

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.


03/01/99 5-7

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.

■ 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.

The Add User window opens with the Details page displayed.

2 In the User field, enter the name for the new user.

Follow the guideline described in Rules for User Entries on page 5-5.

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.

The e-mail address is used by the CMS for project notifications.

5 In the Password field, enter a password for the new user.

See Rules for User Entries on page 5-5. For security, only asterisks display instead of the letters you enter.

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

Again, only asterisks display in the window.

7 Choose: Add the user entry without assigning group membership(s) by clicking OK.

The Add User window closes and the user name is added to the Users page of the User/Group Manager primary window.

Continue to the Groups page.

The Groups page opens.

Click Cancel. The Add User window closes without making any changes to the StoryServer database.

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 not a member of list.

The left arrow button becomes available.

10 Click the left arrow button. Repeat as necessary.

Moves one or more entries to the User is a member of list.

11 Click OK or Cancel.


5-8 03/01/99

Editing a User Entry

Admin users can edit any field in the Edit User window pages except the User field; you cannot change the user’s ID. (To change the user’s 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 user’s 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.

■ To edit a user entry:

1 In the Users page of the User/Group Manager primary window, select a user entry.

The Details icon becomes available.

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.

The Edit User window closes and appropriate changes appear in the Users page of the User/Group Manager primary window.

Continue to the Groups page. The Groups page opens.

Click Cancel. The Edit User window closes without making any changes to the StoryServer database.


03/01/99 5-9

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 user’s information.

■ To clone a user entry and create a new entry:

5 To continue and change the user’s 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.


1 In the Users page of the User/Group Manager primary window, select a user entry.

The Clone icon becomes available.

2 Click Clone. The Copy User window opens with the Details page displayed.

3 Add information to the fields. See Adding a User Entry on page 5-6.

4 Choose: Add the user entry without assigning group membership(s) by clicking OK.

The Copy User window closes and the user name is added to the Users page of the User/Group Manager primary window.

Continue to the Groups page. The Groups page opens.

Click Cancel. The Copy User window closes without making any changes to the StoryServer database.


5-10 03/01/99

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 user’s 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 user’s 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.

■ To delete a user from the StoryServer database:

Setting E-mail Preferences

5 To continue and modify the user’s group membership(s), click the Groups tab at the top of the Copy User window.


6 Modify the user’s group(s). See Editing a User Entry on page 5-8.


1 In the Users page of the User/Group Manager primary window, right-click one or more user entries, and select Delete from the pop-up menu.

A confirmation prompt opens.


Topics include: • Setting the SMTP Host• Enabling E-mail Notifications


03/01/99 5-11

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.

■ To set the SMTP server for a StoryServer CMS:

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.

1 In the Configuration View primary window, right-click the Content Management Server entry, and select Details from the pop-up menu.

The Content Management Server Details window opens.

2 Enter the fully qualified domain name and port number of the SMTP server to use when sending e-mail notification.

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 site’s SMTP server. For example: archie.myco.com

port Specifies the server’s port number, usually 25.

3 Click OK to submit the change to the database.


5-12 03/01/99

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:

If a user prefers not to receive e-mail regarding any task, you can delete the e-mail 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.

■ To enable or disable e-mail notification for a StoryServer CMS:

For... The appropriate users are notified...

One-time tasks Immediately when the task is created.

Workflow tasks When the task rises to the top of the workflow (that is, it is the current task).

Recurring tasks (first in the schedule)

When the recurring task is created.

Recurring tasks (subsequent tasks in the schedule)

When the previous task is completed or when the previous task becomes late, whichever comes first.

Failed program tasks (Project owners only)

When a program task in the project or workflow is unsuccessful.



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.


See also Managing Groups on page 5-13


03/01/99 5-13

Managing Groups

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.


Topics include: • Rules for Group Entries• Adding a Group Entry• Editing a Group Entry• Cloning a Group Entry• Deleting a Group Entry


5-14 03/01/99

■ To add a group entry to the StoryServer database:

Editing a Group Entry

Admin users can edit any field in the Edit Group window pages except the Group field; you cannot change the group’s name. (To change the group’s name, you must delete the group and re-enter the information.) You can edit only one group entry at a time.

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

The Add Group window opens with the Details page displayed.

2 In the Group field, enter the name for the new group.

Follow the guideline described in Rules for Group Entries on page 5-13.

3 (Optional) In the Description field, enter a full name or more detail about the group.

4 Choose: Add the group entry without assigning members by clicking OK.

The Add Group window closes and the group name is added to the Groups page of the User/Group Manager primary window.

Continue to the Users page.

The Users page opens.

Click Cancel. The Add Group window closes without making any changes to the StoryServer database.

5 To continue and add users to the groups, click the Users tab at the top of the Add Group window.

The Users page opens.

6 Select one or more entries in the Group does not include Users list.

The left arrow button becomes available.

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



03/01/99 5-15

If you change a group’s 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 user’s 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.

■ To edit a group entry:

1 In the Groups page of the User/Group Manager primary window, select an entry.

The Details icon becomes available.

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.

The Edit Group window closes and appropriate changes appear in the Groups page of the User/Group Manager primary window.

Continue to the Users page. The Users page opens.

Click Cancel. The Edit Group window closes without making any changes to the StoryServer database.

5 To continue and change the group’s member list, click the Users tab at the top of the Edit Group window.

The User page opens.

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.



5-16 03/01/99

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 group’s information.

■ To copy a group entry and create a new entry:

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 user’s 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

1 In the Groups page of the User/Group Manager primary window, select a group entry.

The Clone icon becomes available.

2 Click Clone. The Copy Group window opens with the Details page displayed.

3 Add information to the fields. See Adding a Group Entry on page 5-13.

4 Choose: Add the group entry without changing the members by clicking OK.

The Copy Group window closes and the group name is added to the Groups page of the User/Group Manager primary window.

Continue to the Users page. The Groups page opens.

Click Cancel. The Copy Group window closes without making any changes to the StoryServer database.

5 To continue and modify the group’s member list, click the Users tab at the top of the Copy Group window.


6 Modify the group’s member list. See Editing a Group Entry on page 5-14.



03/01/99 5-17

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.

■ To delete a group from the StoryServer database:

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.

■ To authorize users and groups to use the Report Manager:

1 In the Groups page of the User/Group Manager primary window, right-click one or more group entries, and select Delete from the pop-up menu.

A confirmation prompt opens.


See also Authorizing Business Center Users on page 5-17

Authorizing Development Center Users on page 5-18





5-18 03/01/99

Authorizing Development Center Users

Through the CMS Details window, you designate which users have access to the Content Designer—where 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.

2 Under Business Center 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 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.

• 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.


See also Authorizing Development Center Users on page 5-18



03/01/99 5-19

■ To authorize users and groups to use StoryServer’s Content Designer:



2 Under Development Center Authorization, enter the Users with Content Designer Authorization. You can enter user or group names in the text box or select from users and groups known to the CMS by using the ... button.

Specified users will have authorization to alter info in StoryServer’s Content Designer.


See also Authorizing Business Center Users on page 5-17


5-20 03/01/99

03/01/99 6-1

6 Managing StoryServer Files on Windows NT or Solaris

Summary: How to manage various directories and files that StoryServer creates when you install and configure your servers.

Audience: Administrators of StoryServer 4.2


Topics include: • Overview• Understanding Server Files• Viewing StoryServer Log Files• Understanding Tool Directories• Understanding Preference Files

Managing StoryServer Files on Windows NT or Solaris Administration Guide

6-2 03/01/99

OverviewWhen 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.

Understanding Server Files

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

SUN /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.

See also Appendix B, StoryServer File Reference

Appendix A, StoryServer Process Reference


Topics include: • 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

Administration Guide Managing StoryServer Files on Windows NT or Solaris

03/01/99 6-3

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

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

SUN /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 CMS’s 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.

Name Location Function

pm.cfg CMS & CAS(for path and details, see pm.cfg on page B-29.)

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.

StoryServer.cfg CAS(for path and details, see StoryServer.cfg on page B-33.)

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.

delivery.tcl CAS(for path and details, see delivery.tcl on page B-15.)

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.


6-4 03/01/99

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 CMS’s 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 CMS’s 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:

The program/command contacts the CMS and transfers the information to the remote CAS’s 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

SUN /install-path/StoryServer/Rn

For... Run.. See also:

NT The StoryServer Platform Configuration Program on the remote CAS.

Updating a Remotely Installed CAS—Windows NT only on page 8-9.

SUN The remote CAS command: admin update_pmcfg

Updating a Remotely Installed CAS—Solaris only on page 8-11.

/install-path/StoryServer/Rn/conf/host-port-number/admin update_pmcfg

File or Directory Name

File or Directory Location

Function

NT SUN

admin.bat

\conf-n\Production\

admin

/conf/Production

Program to stop/start CMS

expire.exe

\taskbin\winnt\

expire

/taskbin/solaris

Program to expire records, files, and templates


03/01/99 6-5

flushcache.bat

\taskbin\winnt\

flushcache

/taskbin/solaris

Program to flush cached pages

launch.exe

\taskbin\winnt\

launch

/taskbin/solaris

Program to launch records, files, and templates

logroller

/taskbin/solaris

Program to archive log files

pm.log

\conf-n\Production\

pm.log

/conf/Production

Levels 3 and 4 error log for CMS dispatch service. See Viewing StoryServer Log Files on page 6-14.

ted.log

\conf-n\Production\

ted.log

/conf/Production

Levels 3 and 4 error log for timed event service. See Viewing StoryServer Log Files on page 6-14.

TedTasksWorkingDirsRoot

\conf-n\Production\

TasksWorkingDirsRoot

/conf/Production

Working directory for timed event program tasks.

version.exe

\taskbin\winnt\

version

/taskbin/solaris

Program to version records, files, and templates

vhs.log

\conf-n\Production\

vhs.log

/conf/Production

Levels 3 and 4 error log for master request-handler service. See Viewing StoryServer Log Files on page 6-14.

vhs.log.id

\conf-n\Production\

vhs.log.id

/conf/Production

Levels 3 and 4 error log for request-handler slave processes. See Viewing StoryServer Log Files on page 6-14.



Function

NT SUN


6-6 03/01/99

CAS Configuration Files

Two files affect a CAS’s configuration: StoryServer.cfg and delivery.tcl.

On each remote CAS, there is also a CAS copy of the CMS’s 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.

SUN 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.cfg—Solaris 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

SUN /conf/host-port-number

VhsProtoDocRoot

\conf-n\Production\

VhsProtoDocRoot

/conf/Production

Directory for request handler working copies of the static files that it has processed



Function

NT SUN


03/01/99 6-7

An example location would be

NT D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\farley-9096-2\StoryServer.cfg

SUN /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.

SUN /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 path’s installation.

CAS copy of the CMS’s pm.cfg file

While a CAS installed on the same host as its CMS shares the CMS’s pm.cfg file, a CAS installed on another host has a copy of the CMS’s 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 CMS’s pm.cfg file is included in the directory:

NT \install-path\StoryServer n\Engines\Rn\conf-n\Production

SUN /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 CMS’s original pm.cfg file, but the changes do not propagate to the remote CASs’ copies unless you update them.

host Indicates the name of the web server host for the CAS.

port Indicates the port number for the CAS’s web server.

number 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.)

See also Setting Up StoryServer-wide Variables and Procedures on page 9-5.


6-8 03/01/99

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.

NOTE: A CAS’s 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\

SUN /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.


Location (if other than host-port-number directory)

Use

NT SUN

admin.bat admin Program to stop/start CAS

cmd.log cmd.log Levels 3 and 4 error log for Cache Manager. See Viewing StoryServer Log Files on page 6-14.

cmd.pid Process ID for Cache Manager

ctld.log ctld.log Database error log for Page Generator service (see the LOG template command)

ctld.log.id ctld.log.id Database error log for Page Generator slave process (see the LOG template command)


03/01/99 6-9

ctld.pid Process ID for Page Generator master process

ctldinfo.log ctldinfo.log Levels 3 and 4 error log for Page Generator master process. See Viewing StoryServer Log Files on page 6-14.

ctldinfo.log.id ctldinfo.log.id Levels 3 and 4 error log for Page Generator slave process. See Viewing StoryServer Log Files on page 6-14.

delivery.tcl

..\

delivery.tcl

../

Global Tcl information for all Page Generators installed under the same \install-path\StoryServer n\ Engines\Rn\conf-n

location

docroot

..\..\

docroot

../../

Contains online StoryServer information (development CAS only)

lastsession.cfg

..\..\adm\

lastsession.cfg

../../adm/

Contains last configuration information as defaults for the next CAS configured on the host

metafiles metafiles Contains template variations

obj.conf

Netscape servers only

obj.conf

Netscape servers only

Backup copy of NSAPI configuration file for Netscape server (not present for IIS)

PadArchiveDir PadArchiveDir Contains last version of replaced or deleted static files known to Placement Manager

pad.log pad.log Levels 3 and 4 error log for Placement Manager master service. See Viewing StoryServer Log Files on page 6-14.



Use

NT SUN


6-10 03/01/99

Understanding Configuration File Interaction

Whether on Solaris or Windows NT operating systems, the StoryServer pm.cfg, StoryServer.cfg, and delivery.tcl configuration files interact in several ways.

pad.log.id pad.log.id Levels 3 and 4 error log for Placement Manager slave process. See Viewing StoryServer Log Files on page 6-14.

pad.pid Process ID for Placement Manager

PadWorkDir PadWorkDir Contains information tracking the progress of Placement Manager operations

pznd.log pznd.log Error log for optional Observation Manager

StoryServer.cfg StoryServer.cfg Configuration file for all this CAS’s services

templates templates Template cache shared by Template Manager and Page Generator

tmd.log tmd.log Levels 3 and 4 error log for Template Manager. See Viewing StoryServer Log Files on page 6-14.

tmd.pid Process ID for Template Manager

Topics include: • Configuration File Influence• File Interaction on a Single Host• File Interaction with Multiple Hosts



Use

NT SUN


03/01/99 6-11

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 CAS’s 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.


6-12 03/01/99

Figure 6-1: Configuration files influence on a single host

File Interaction on a Single Host

When CASs are configured on the same host as the CMS, each CAS’s StoryServer.cfg file sources (reads) the CMS’s pm.cfg file at install time. A statement near the end of each CAS’s StoryServer.cfg file causes the CAS’s ctld process (Page Generator) to read this StoryServer system’s 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

StoryServer systemon a single host

A single delivery.tcl affects ctlds on all CASs configured on this host with this CMS

CASwith its own

StoryServer.cfg

ctldprocess

CASwith its own

StoryServer.cfg

ctldprocess

CASwith its own

StoryServer.cfg

ctldprocess

CMSprocesses

pm.cfg influences the whole StoryServer system.


03/01/99 6-13

variable settings and some comments on what process accesses the information.

...most of the StoryServer.cfg file omitted

CAS’s tmd process uses the SYSTEM DATABASE SETTINGS in pm.cfg## SYSTEM DATABASE SETTINGSset STORYSERVER_PMCFG /opt/StoryServer/R4.2/conf/Production/pm.cfgsource $STORYSERVER_PMCFG

CAS’s ctld process uses the CONTENT DATABASE SETTINGS## CONTENT DATABASE SETTINGSset ORACLE_HOME /u/oracle/app/oracle/product/8.0.3set KHAN KHANset DB_CLIENT dbconnectset vdbmsg(rwdblib) librwora_mt.so

set CONTENT_DB_TYPE Oracleset CONTENT_DB_SERVER KHANset CONTENT_DB_DATABASE ""set CONTENT_DB_SID ourID_thingset CONTENT_DB_USERNAME ourID_thingset CONTENT_DB_PASSWORD ourID_thingset CONTENT_DB_RWDBLIB ourID_thing

...some settings omitted

CAS’s ctld process uses the delivery.tcl file for additional instructions## Include external Tcl Files or DLOAD other API modules hereif {[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.


6-14 03/01/99

File Interaction with Multiple Hosts

When CASs are configured on hosts other than the CMS’s, the CASs on each remote host get a copy of the CMS’s pm.cfg file at install time. If the CMS’s pm.cfg file changes, these remote copies are not automatically updated. Because a CAS’s 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 CAS—Windows NT only on page 8-9, or Updating a Remotely Installed CAS—Solaris 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.cfg—Solaris 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).

Viewing StoryServer Log Files



Viewing StoryServer Log Files on page 6-14


Topics include: • Viewing the EventLog Event Viewer on Windows NT• Archiving the StoryServer.errors file on Solaris


03/01/99 6-15

StoryServer provides a mechanism for logging errors and messages:

NT The EventLog service records events, errors, and messages for tools.

SUN 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):

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.

pm.cfg contains log levels for CMS processes.

NT \install-path\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.cfg

SUN /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

SUN /install-path/StoryServer/Rn/conf/host-port-number /StoryServer.cfg

Log Level Message Type

Written to

NT SUN

1 error EventLog service syslogd

2 warning Eventlog service syslogd

3 audit service log file process log file

4 debug service log file process log file


6-16 03/01/99

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

SUN /install-path/StoryServer/Rn/conf/Production/ted.log

Viewing the EventLog Event Viewer on Windows NT■ To view StoryServer errors and messages (levels 1 or 2), use the EventLog

Event Viewer:

1 Using your preferred method, open the Programs\Administrative Tools\Event Viewer.

2 From the Log menu, select Application.

3 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.

4 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 Looks for the files in /var/adm.

2 Copies the log to a file named StoryServer.errors.timestamp and puts the copies in /var/adm.

3 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


03/01/99 6-17

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.

Understanding Tool Directories

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:



Understanding Tool Directories on page 6-17


Topics include: • Windows Tool Directories• Solaris Tool Directories• Macintosh Tool Folders

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.

C:\Program Files\Vignette \StoryServer n\java

Contains Java files and directories for the tools.

C:\Program Files\Vignette \StoryServer n\lib

Contains files used by the tool programs.


6-18 03/01/99

Solaris Tool Directories

For a Solaris installation of the tools, the following directories are installed at the location you specify:

The following files are also installed in the /install-path/StoryServer/Rn/ui/ directory:

Macintosh Tool Folders

For a Macintosh installation of the tools, StoryServer installs the following:

/install-path/StoryServer /Rn/ui/bin

Contains the program for the StoryServer launch bar.

/install-path/StoryServer /Rn/ui/java

Contains Java files and directories for the tools.

/install-path/StoryServer /Rn/ui/lib

Contains files used by the tool programs.

setinfo Stores the tools that are installed.

uninstall.sh Used when the tool set(s) are uninstalled.

/install-path/Vignette Contains the macrodata, copyright, and other tool files.

System Folder/Preferences /Vignette

Contains the Preferences file.

System Folder/Extensions /MRJ Libraries

StoryServer installs some items in this existing folder.



Understanding Preference Files on page 6-19


03/01/99 6-19

Understanding Preference Files

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 user’s home directory.

For the home directory locations of these files, see File Locations on page 6-21.

macrodata File

In the Development Center tool’s 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 sessions—whether with the Template Editor or the Visual Template Editor; both editors will save macro information to the same macrodata file.


Topics include: • macrodata File• Preferences File• File Locations


6-20 03/01/99

The default install version of the macrodata file is stored in the following directories:

NT C:\Program Files\Vignette\StoryServer n\ Clients\lib\macrodata

SUN /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.


03/01/99 6-21

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.

• SUN - 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.




6-22 03/01/99

03/01/99 7-1

7 Working with the Database on Windows NT or Solaris

Summary; How to manage the StoryServer database, which contains templates, content records for web pages, and production management information for tracking templates and content.



Topics include: • Overview• Requirements• Understanding StoryServer Database Tables• Database Password Encryption

Working with the Database on Windows NT or Solaris Administration Guide

7-2 03/01/99

OverviewThe 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

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.


Topics include: • Database Permissions• Database Size

Administration Guide Working with the Database on Windows NT or Solaris

03/01/99 7-3

Database Permissions

The username under which StoryServer operates in the StoryServer database needs the following permissions for the various database types:

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.

Understanding StoryServer Database Tables

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.

For database... The StoryServer database user needs...

NT

Microsoft SQL Server

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. NT/SUN

Sybase

NT/SUN

Oracle

SQL CONNECT and RESOURCE permissions for the table space containing the StoryServer installation.

SUN

Informix

See also Understanding StoryServer Database Tables on page 7-3



7-4 03/01/99

Table Name Type Description

next_id CAS Tracks next identifier to use in a given StoryServer database table when asked for one, for example, by the GET_NEXT_ID StoryServer command

template CAS Stores all templates

template_path CAS Stores template paths

vgn_altcontent CAS Created for user convenience to store graphics, text, other content

vgn_an CMS Stores Vignette users/groups authentication data

vgn_bz CMS & CAS Stores an entry for each authorized Business Center user and all report definitions that the user has created.

vgn_cc CMS & CAS Stores personalization content catalog information

vgn_cf CMS Contains StoryServer configuration information

vgn_ci CMS Production management information for templates, files, content records

vgn_dal_collection CMS & CAS Stores metadata about Forms used by Content Designer ITEM commands

vgn_dal_field CMS & CAS Stores metadata about Fields (columns) in database tables used by Content Designer ITEM commands

vgn_dal_table CMS & CAS Stores metadata about tables managed by Content Designer and used by Content Designer ITEM commands

vgn_dbconfig CMS Holds internal information about CMS classes and objects

vgn_dc CMS Contains the content designs from the Content Designer. See Using the Content Designer.

vgn_dt CMS Stores information about database tables that the Content Designer manages. See Using the Content Designer.

vgn_features CAS Contains the list of browser features

vgn_fs CMS Contains form set information from the Content Designer. See Using the Content Designer.

vgn_kr CMS & CAS Stores personalization keyword registry information

vgn_pr CMS Contains project management information


03/01/99 7-5

NOTE: With the vgn_utn and vgn_uvn tables above, the view number will not necessarily be in sync with the table number.

Database Password Encryption

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 CMS’s 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 CAS’s configuration

vgn_scratch CMS Temporary working area for the CMS

vgn_tk CMS Contains task management information

vgn_uc CAS Stores personalization profile-marker-by-user information

vgn_ur CAS Stores personalization user registry information

vgn_variations_map CAS Maps templates to sets of browser features

vgn_utn CMS & CAS Created by Content Designer to hold content

vgn_uvn CMS & CAS A view of a Content Designer-managed table

vgn_version CMS Stores information on versions of templates, files, and records

vgn_version_tag CMS Stores labels associated with versions of templates, files, and records

See also Database Password Encryption on page 7-5


Topics include: • Configuration• Encryption in Templates

Table Name Type Description


7-6 03/01/99

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

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 don’t 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.)

Topics include: • Turning Off Database Password Encryption• Turning Encryption Back On• Changing the Database Password


03/01/99 7-7

• If any templates include a database password (for example, to connect to a database that’s 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 can’t connect to the database.)

For example, if the vdbmsg(password_encrypted) variable in the development CAS’s StoryServer.cfg file is set to yes and the live CAS’s 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

■ To turn off encryption of the StoryServer system database password:

1 Start editing the CMS’s 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 In the CMS’s pm.cfg file, in the ## DATABASE SERVER SETTINGS section, set SYSTEM_DB_PASSWORD_ENCRYPTED to no.

3 Find the SYSTEM_DB_PASSWORD variable (just above SYSTEM_DB_PASSWORD_ENCRYPTED), and replace the encrypted password with the plain-text password.

4 Save and commit your changes.

Any CASs you configure after setting SYSTEM_DB_PASSWORD_ENCRYPTED to no will also have encryption turned off.

■ To turn off password encryption for the default content database:

1 Start editing the CAS’s 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.)


7-8 03/01/99

2 Find the vdbmsg(password_encrypted) variable in the ## CONTENT DATABASE SETTINGS section of the file, and set it to no.

3 In the same section of the file, find the CONTENT_DB_PASSWORD variable, and replace the encrypted password with the plain-text password.

4 Save and commit your changes.

5 Repeat the procedure for each CAS that’s 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:

• SUN

/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

2 Substitute the encrypted StoryServer system database password for the plain-text password in the CMS’s pm.cfg file. Save and commit the changes.

3 Substitute the encrypted content database password for the plain-text password in each CAS’s StoryServer.cfg file. Save and commit the changes.


03/01/99 7-9

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

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 don’t 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 form—encrypted or not encrypted—that 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

■ 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.

Topics include: • Encrypting the Password in Templates• Overriding the Configuration


7-10 03/01/99

• SUN 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

■ 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 USERNAME storysdb][SET PASSWORD atlas44][SET SERVER barbell][SET DATABASE oramain]


03/01/99 7-11

Or if encryption is turned off in StoryServer.cfg for the content database password:

[SET vdbmsg(password_encrypted) yes]

[SET USERNAME storycdb][SET PASSWORD 2z:HDKsl7HLR][SET SERVER barbell][SET DATABASE oraC2]

NOTE: The template doesn’t 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


7-12 03/01/99

03/01/99 8-1

8 Managing StoryServer Processes on Windows NT or Solaris

Summary: How to manage the CMS and CAS processes (services) through the Configuration View, Start menu options, or a command-line interface.


Before you begin: • Basic Concepts on page 1-1• Monitoring StoryServer Servers and Processes on page 4-1

Topics include: • 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 Options—Windows

NT only• Updating a Remotely Installed CAS—Windows NT only• Updating a Remotely Installed CAS—Solaris only• Notifying the CMS of changes to StoryServer.cfg—Solaris only• Verifying CAS Processes—Solaris only• Managing Page Generation

Managing StoryServer Processes on Windows NT or Solaris Administration Guide

8-2 03/01/99

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 Options—Windows 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.

■ To reset a Page Generator or Template Manager process:

1 In the Configuration View primary window, expand a CAS entry to show the CAS’s processes whose Page Generator or Template Manager process you want to change.

2 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.

3 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


Administration Guide Managing StoryServer Processes on Windows NT or Solaris

03/01/99 8-3

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 When the operation is complete, a notice informs you that Page Generator or Template Manager has been reset.

5 Click OK to continue.

Locating admin Commands

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

SUN /install-path/StoryServer/Rn/conf/Production/admin


Example locations:

NT D:\Program Files\Vignette\StoryServer 4 \Engines\R4.2\conf-2\Production\admin.bat

See also Locating admin Commands on page 8-3


Topics include: • CMS admin• CAS admin


8-4 03/01/99

SUN /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

SUN /install-path/StoryServer/Rn/conf/host-port-number/admin


Example locations:

NT D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\art.myco.com-93-2\admin.bat

SUN /myHost/StoryServer/R4.2/conf/antone-9091-2/admin

For more information on this admin command, see the admin (CAS) reference page.

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.

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



03/01/99 8-5

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:

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 CMS’s 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 Options—Windows NT only on page 8-8.

■ To stop or start a set of CMS Services using the admin command:

1 Log in as system admin user on the host where the CMS is installed.

2 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.

3 Enter the following command at the prompt:

admin stop

or

admin start

NameProcess Name Function Windows NT Service Name

dispatch manager bob Dispatches all CMS transactions

Vignette Production Dispatch Service

timed-event process ted Tracks timed events for the dispatch manager

Vignette Timed Event Service

request handler vhs Manages requests for the dispatch manager

Vignette Production Request Service


8-6 03/01/99

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.

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.

See also Stopping and Starting the CAS with the admin Command on page 8-6



03/01/99 8-7

Each CAS contains the admin executable to stop and start its own processes:.

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.

■ To stop or start a set of CAS processes:

1 Log in as system admin user on the host where the CAS is installed.

2 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.

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.

NameProcess Name Function

Windows NT Service Name

Cache Manager cm Maintains cached content Vignette Cache Manager

Page Generator ctld Interprets templates, accesses content, generates web pages

Vignette Page Generator

Placement Manager

pad Manages deployment of static content to the CAS docroots

Vignette Placement Agent

Template Manager

tmd Manages templates, updates Page Generator regarding new or modified templates.

Vignette Template Manager



8-8 03/01/99

Stopping and Starting with the Start Menu Options—Windows NT only

You can stop and start CMS and CAS processes by using the Start menu options. These menu options execute the Server’s admin.bat program and handle the processes in the correct order and are easier to execute than the command-line options.

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

■ 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 Select Start CMS or Stop CMS, depending on the action you want.

3 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.

Audience: Administrators of StoryServer 4.2 on Windows NT

Topics include: • Stopping and Starting a CMS from the Start Menu• Stopping and Starting a CAS from the Start Menu


Stopping and Starting the CAS with the admin Command on page 8-6


03/01/99 8-9

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

■ 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 From the next menu, select Stop CAS or Start CAS, depending on the action you want.

3 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.

Updating a Remotely Installed CAS—Windows NT only

When you make changes to a CMS’s 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 CAS’s StoryServer Platform

See also Updating a Remotely Installed CAS—Windows NT only on page 8-9

Updating a Remotely Installed CAS—Solaris only on page 8-11

Audience: Administrators of StoryServer 4.2 on Windows NT


8-10 03/01/99

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 CAS’s host to use the StoryServer Platform Configuration Program.

■ To update a remotely installed CAS on Windows NT:

1 Log in as system admin user on the host where the remote CAS is installed.

2 Open the StoryServer Platform Configuration Program using your preferred method. See Accessing the Platform Configuration Program—Windows NT only on page 9-6.

3 In the Welcome window, click Next to continue. A Choose Option window replaces the Welcome message.

4 From the list, select the Configure an existing Content Management Server option. Click Next to continue.

5 From the list, select the CMS with which the CAS you want to update is configured. Click Next to continue.

6 From the list, select the Update or remove the Content Management Server option. Click Next to continue.

7 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 CMS’s pm.cfg file in this StoryServer installation’s \install-path\StoryServer n\Engines\Rn\conf-n\Production\ directory.

The program returns to the main menu when the operation is complete.

8 Select the Exit Setup option. Click Next to end the session.

See also Managing Page Generation on page 8-13


03/01/99 8-11

Updating a Remotely Installed CAS—Solaris only

When you make changes to a CMS’s 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 CAS’s host to use the admin update_pmcfg command.

1 Log in as system admin user to the host where the remote CAS is installed.

2 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 CMS’s pm.cfg to the remote CAS’s 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.

Audience: Administrators of StoryServer 4.2 on Solaris

See also Notifying the CMS of changes to StoryServer.cfg—Solaris only on page 8-12


8-12 03/01/99

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 CAS’s 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 updatepe

For information on the command location, see admin (CAS) reference page.

You must have system admin user privileges on the CAS’s host to use the admin updatepe command.

■ To notify the CMS of changes to StoryServer.cfg:

1 Log in as system admin user to the host where the remote CAS is installed.


/install-path/StoryServer/Rn/conf /host-port-number/admin updatepe

The command contacts the CMS and transfers the information from the remote CAS’s StoryServer.cfg.

The command-line prompt returns when the operation is complete.


See also Verifying CAS Processes—Solaris only on page 8-13


03/01/99 8-13

Verifying CAS Processes—Solaris 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.

■ To verify the CAS processes:

1 Log in to the host where the StoryServer CAS is running that you want to verify.


/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.

Managing 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.


See also Managing Page Generation on page 8-13


Topics include: • Disabling StoryServer Page Generation• Enabling StoryServer Page Generation


8-14 03/01/99

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.

■ To disable StoryServer page generation and enable it when the database is ready to accept connection follow these steps:

1 Disable StoryServer page generation. See directly below.

2 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.

3 Perform database maintenance, as needed.

4 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.

5 Enable StoryServer Page Generation. See below.

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.

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.

3 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.


03/01/99 8-15

4 Click OK to continue. When the cursor returns to normal, the operation is complete.

5 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.

6 Perform the database maintenance.

7 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.

8 Continue to Enabling StoryServer Page Generation on page 8-15.

Enabling StoryServer Page Generation

You can use the Configuration View to enable page generation on all CASs connected to a single CMS.

1 After the CMS services are restarted, start a StoryServer session if one is not already running and log in to the CMS.

2 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.

3 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.

4 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


8-16 03/01/99

03/01/99 9-1

9 Managing StoryServer on Windows NT and Solaris

Summary: Procedures for various management tasks.



Topics include: • Establishing Service Dependencies for CMS/CAS—Windows NT only

• Setting Up StoryServer-wide Variables and Procedures• Accessing the Platform Configuration Program—Windows NT

only• Adding a CAS and Copying Static Files• Removing an Observation Manager• Removing a CAS• Managing the Demonstration Project

Note: For information on removing server software, see Platform Installation & Configuration Guide (printed copy shipped with product).

Managing StoryServer on Windows NT and Solaris Administration Guide

9-2 03/01/99

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 can’t 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.

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 hosts—determines which dependencies you have to set.

Database Type Variable Example

Microsoft SQL Server MSSQLServer MSSQLServer

Oracle OracleServiceINSTANCENAME OracleServiceORCL

Sybase SYBSQL_SERVER SYBSQL_SNOWWHITE

Administration Guide Managing StoryServer on Windows NT and Solaris

03/01/99 9-3

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).

■ To adjust the CMS or CAS start sequence in relation to the specified database service:

1 Determine which dependencies you need to set on the host.

2 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 Open a Command Prompt window and navigate to the drive where the StoryServer software is installed.

4 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

5 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 30210—with one space on each side of 4.2— then the command will fail if you put two spaces on either side.

If the following are on the same host... Set dependencies for...

Database server, CMS, and CAS bob, tmd, pznd

Database server and CMS bob

Database server and CAS tmd, pznd


9-4 03/01/99

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.

service The full identifier of the service; one of the following:

• bob n bobport

• tmd n hostname-webserverport

• pznd n hostname-webserverport

n The StoryServer version number. For example, 4.2.

bobport The port of the Dispatch Service.

hostname-webserverport 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 CAS’s web server.

dbvariable See the table earlier in this section.


03/01/99 9-5

Setting Up StoryServer-wide Variables and ProceduresIn 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

SUN /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.

■ 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

2 Enter a variable of the format:

set variable string

For example:

set myDino "Brontosaurus dog"

3 Save your changes to the file and exit the editor.


9-6 03/01/99

4 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.

From the Start Menu

On host machines running a CAS or CMS, the Start menu includes the StoryServer Platform Configuration Program option.

1 Log in as system admin user on the host where the Platform is installed.

2 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.

3 Click Next to continue to a list of options.

You can access the StoryServer Platform Configuration Program in several ways:

• From the Start Menu • From the Desktop• From the Command Line


03/01/99 9-7

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 Double-click the My Computer icon. The My Computer window opens.

2 Double-click the Control Panel icon. The Control Panel window opens.

3 Double-click the Add/Remove Programs icon. The Add/Remove Programs Properties window opens.

4 Select the StoryServer n StoryServer Platform Configuration Program entry.

5 Click the Add/Remove button.



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 Open a Command Prompt window and navigate to the drive where the CMS software is installed, if necessary.

2 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\

3 Enter the following command at the prompt:

setup




9-8 03/01/99

Adding a CAS and Copying Static Files

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 StoryServer’s 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


■ 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 Program—Windows NT only on page 9-6.


Topics include: • Adding a CAS and Copying Static Files on Windows NT• Adding a CAS and Copying Static Files on Solaris


03/01/99 9-9

3 Select the Configure an existing Content Management Server (CMS) option. Click Next to continue. From the list, select the CMS to configure.

4 Select the Configure, update or remove a Content Application Server option. Click Next to continue.

5 Select the Configure a new Content Application Server option. Click Next to continue.

6 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.

8 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.

9 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.


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 don’t 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


9-10 03/01/99

directory to the docroot of the web server configured with the new CAS. You can find the location of the web server’s docroot in the

\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\StoryServer.cfg file’s DOCROOT

variable, where host-port-number is the new CAS’s 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 CAS’s web server instead of the Production\VhsProtoDocRoot directory to avoid exposing in-progress 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 CAS’s web server to the docroot of a new development CAS’s 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 don’t 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 server’s docroot in the

/install-path/StoryServer/Rn/conf/host-port-number/StoryServer.cfg


03/01/99 9-11

file’s DOCROOT variable, where host-port-number is the new CAS’s 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 CAS’s web server instead of the Production/VhsProtoDocRoot directory to avoid exposing in-progress 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 CAS’s web server to the docroot of a new development CAS’s web server.

Removing an Observation Manager

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 Manager’s 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 CAS’s 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.

Topics include: • Removing an Observation Manager on Windows NT• Removing an Observation Manager on Solaris


9-12 03/01/99

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■ To remove an Observation Manager from a CAS on Windows NT:


2 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.


4 Select the Setup/Remove an Observation Manager option. Click Next to continue.

5 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.

Removing an Observation Manager on Solaris■ 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.


03/01/99 9-13

2 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 Select the number for the Personalize option.

4 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-12 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.

6 Enter y to continue.

7 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.

Removing a CAS

Topics include: • Removing a CAS on Windows NT• Removing a CAS on Solaris

Before you can remove... You must remove...

A CMS All StoryServer CASs from a particular StoryServer system.

A CAS The Observation Manager, if it has been configured. See Removing an Observation Manager on page 9-11.


9-14 03/01/99

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 CAS’s host to remove a CAS.

Removing a CAS on Windows NT■ 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.

2 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.


4 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.



03/01/99 9-15

Removing a CAS on Solaris■ To remove a CAS on Solaris:

1 Log in as system admin user on the host where the CAS you want to remove is installed.




The interactive script begins and displays the Content Application Server Configuration Menu.

3 Select the number for the Remove option. The script responds with an explanation of the removal steps and asks if you want to continue.


A list of CASs set up for this StoryServer system appears. For example:

StoryServer CASs include:1 wallace-8040-12 wallace-8080-1

Choose the StoryServer CAS to remove [?, ??, q]:

5 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.)

6 To confirm the removal, enter y.

7 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


9-16 03/01/99

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 project’s static files and updates the Template Manager for the CAS on that host.

NOTE: You must have system admin user privileges on the CMS’s host or on a remote CAS’s host to run the StoryServer Platform Configuration Program.

■ To delete the Vignette Demonstration Project on Windows NT:



3 From the list, select the Install or remove a project package option. Click Next to continue.


03/01/99 9-17

4 Select the Remove a project package option. Click Next to continue.

5 Select one or more projects to remove. (If you have only the Vignette demonstration project, MusicAlaMode, it is automatically selected.)


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 project’s static files and updates the Template Manager for the CAS on that host.


■ To restore the Vignette Demonstration Project on Windows NT:



3 From the list, select the Install or remove a project package option. Click Next to continue.

4 Select the Install a project package option. Click Next to continue.

5 Select one or more project packages to add. (If the Vignette demonstration project, MusicAlaMode, is the only available project, it is automatically selected.)


9-18 03/01/99


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.


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 they’re 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 project’s static files and updates the Template Manager for the CAS on that host.


■ To delete the Vignette Demonstration Project on Solaris:

1 Log in to the host where the CMS is installed that serves the CAS for which you want to remove the demonstration projects.




The interactive script begins and displays the CAS Configuration Menu.

3 Enter the number for the Delete option. The script responds with a description of the delete operation and asks if you want 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,


03/01/99 9-19

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 project’s static files and updates the Template Manager for the CAS on that host.


■ To restore the Vignette Demonstration Project on Solaris:

1 Log in to the host where the CMS for the CAS you want to update is installed.




The interactive script begins and displays the CAS Configuration Menu.

3 Enter the number for the Update option. The script responds with a description of the update operation and asks if you want to continue.

4 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 CAS’s static files with the project files and publish the project’s templates to the CAS.

5 Enter y if you want to update or publish.


9-20 03/01/99

After updating and publishing, the script again displays the CAS Configuration Menu.

6 Select another operation or enter q to quit.

03/01/99 10-1

10Working with Web Servers on Windows NT or Solaris

Summary: How to modify certain features of the web server.


Before you begin: • Basic Concepts on page 1-1• Monitoring StoryServer Servers and Processes on page 4-1

Topics include: • Mapping the Root Path (/) to a Front Door CURL• Working with Web Server Parsing• Clearing Pages from a Root Path• Using .asp Scripts in Templates—Windows NT only

Working with Web Servers on Windows NT or Solaris Administration Guide

10-2 03/01/99

Mapping the Root Path (/) to a Front Door CURLMapping the root documentation path to a particular CURL for your web site’s 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.

■ 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.

2 Find the commented line under WEB SERVER SETTINGS for HTTPD_FDCURL:

#set HTTPD_FDCURL "your frontdoor"

3 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 Save your changes. See Editing the StoryServer.cfg File on Windows NT on page 11-3.

5 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 4—Windows NT only• Parsing on Apache—Solaris only

Administration Guide Working with Web Servers on Windows NT or Solaris

03/01/99 10-3

StoryServer component templates offer a valuable way to increase your web server performance by taking advantage of StoryServer’s 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: Don’t 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 server’s 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.


10-4 03/01/99

NOTE: If you use the Netscape Administration Server interface to alter the web server’s obj.conf file, ensure that the method="(GET|HEAD|POST)" phrase in this line includes the POST option. If it is missing, submittals (posts) won’t work.

Disabling Parsing on Netscape

NOTE: Don’t 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 CAS’s StoryServer.cfg file and the web server’s 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 4—Windows NT only on page 10-6.

■ To disable your Netscape web server so that it doesn’t 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.

2 Find the line under WEB SERVER SETTINGS for HTTPD_COMPONENTSCAN:

HTTPD_COMPONENTSCAN 1

3 To disable parsing, change the value to 0 (zero):

HTTPD_COMPONENTSCAN 0

4 Save your changes and select a commit option. See Editing the StoryServer.cfg File on Windows NT on page 11-3.

5 Before parsing is completely disabled, you must also change the Netscape web server’s obj.conf file. See Disabling Server-side Includes on Netscape on page 10-5.

Topics include: • Disabling Interpretation of COMPONENT Results• Disabling Server-side Includes on Netscape


03/01/99 10-5

Disabling Server-side Includes on Netscape

■ To disable server-side includes (parse-html) completely, edit the Netscape web server’s obj.conf file:

1 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.

2 Open a command line and navigate to the directory:

NT \ws-install-path\ws-instance\config\

SUN /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

SUN 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

4 To disable server-side includes (parse-html) completely, remove these two lines from the web server’s 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 Save the changes to the web server’s obj.conf file.

7 From the Netscape Administration Server interface, apply the changes with the Apply and Load Configuration Files commands.

8 To make the web server use the new values, stop and restart the web server.


10-6 03/01/99

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.

■ To optimize parse-html on Netscape:

1 Use the Netscape Administration Server to change the Parse HTML setting to the desired type of file (files with the extension .shtml).

2 Edit the web server’s 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 Save the changes to the web server’s obj.conf file.

4 From the Netscape Administration Server interface, apply the changes with the Apply and Load Configuration Files commands.

5 Stop and restart your web server.

6 Change the default extension for templates containing COMPONENT commands to .shtml so the web server will parse them.

Parsing on IIS 4—Windows 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.

■ 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.


03/01/99 10-7

2 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.

3 With WWW Service selected, click the Edit button.

4 Select the Home Directory tab.

5 In the Permissions section, select the Script option field if it isn’t already selected. This option allows scripts to be run on the webserver.

6 Select Configuration. You will see a list of Application Mappings.

7 To enable ssinc.dll for .html and .htm, add two lines to the properties that look similar to this, depending on your configuration:

.htm C:\WINNT\System32\inetsdrv\ssinc.dll

.html C:\WINNT\System32\inetsdrv\ssinc.dll

8 Make sure that no exclusions exist for either .htm or .html file types.

9 Click OK in the Configuration window, then Apply in the Microsoft Management Console.

10 Repeat these steps for each web server instance on this host for which you will configure a CAS.

11 In Windows Explorer, select the web server’s docroot entry and open its Properties window.

12 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 server’s docroot).

a Confirm that the user name Type of access is set to Change (which provides read, write, delete, and execute permissions).

b Select both the Replace Permissions on Subdirectories and Replace Permissions on Existing Files option fields, if they’re not already selected.

13 Click OK in the Directory Permissions window and OK in the Properties window.

14 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


10-8 03/01/99

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 Apache—Solaris only

You can add a handler to the native Apache configuration file (for example, the web server’s 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 PathAfter 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 CAS’s 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


03/01/99 10-9

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 isn’t 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.

■ 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 it’s not already selected. The text field becomes available.

2 In the Program task text field, type flushcache and the options you want. The format is:

flushcache host port path ...

For example, to clear pages from the directory

NT \OurSite\Books

SUN /OurSite/Books

in the document root for the web server whose Cache Manager’s port is 13625 on system farley:

NT flushcache farley 13625 \OurSite\Books

SUN flushcache farley 13625 /OurSite/Books

To flush multiple paths with one command:

NT flushcache farley 13625 \OurSite\Books \OurSite\Magazines

SUN 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.

host Specifies the system where the web server whose document root you want to clear is running.

port Specifies the Cache Manager’s port number on the CAS associated with the web server document root.

path Specifies one or more directories relative to the document root containing the pages you want to clear.


10-10 03/01/99

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. It’s 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 Templates—Windows NT onlySo 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 server’s 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 CAS’s StoryServer.cfg file.

NOTE: An ASP template is required for an asp component to work. ASP templates must have the .asp extension.

■ To configure the StoryServer.cfg file to handle .asp scripts:

1 Access the CAS’s StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3.

2 Find this line:

set CMD_MIMETYPE_EXT

The default value is 0.

3 Set the number to 1. Otherwise, StoryServer interprets a path ending in .asp as a directory and will not find the page.

4 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.

5 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 Options—Windows NT only on page 8-8.


03/01/99 10-11


10-12 03/01/99

03/01/99 11-1

11Tuning StoryServer on Windows NT

Summary: 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.

Audience: 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

Topics include: • 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

Tuning StoryServer on Windows NT Administration Guide

11-2 03/01/99

Editing the Configuration Files 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 CMS’s host to use the StoryServer Platform Configuration Program.

■ 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 Program—Windows NT only on page 9-6.

2 Click through the initial windows.

3 Select the Configure an existing Content Management Server (CMS) option. Click Next to continue.

4 Select the CMS to configure. Click Next to continue.

Topics include: • Editing the pm.cfg File on Windows NT• Editing the StoryServer.cfg File on Windows NT

Administration Guide Tuning StoryServer on Windows NT

03/01/99 11-3

5 Select the Update or remove the Content Management Server option. Click Next to continue. The Choose option window changes to your selection.

6 Select the Update Content Management Server option. Click Next to continue. The Choose editor window opens.

7 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 CMS’s pm.cfg file is opened using your selected file editor.

8 Modify the file as needed. (See other sections in this chapter.)

9 Save your changes and close the file. A confirmation message asks you to confirm that you want to commit the changes to the CMS’s pm.cfg file.

10 Choose one of the following options:

• Yes - Your changes are committed to the pm.cfg file.

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 CAS’s \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.


11-4 03/01/99

The StoryServer Platform Configuration Program lets you open a CAS’s 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.


■ 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 Program—Windows NT only on page 9-6.

2 Click through the initial windows.

3 Select the Configure an existing Content Management Server (CMS) option. Click Next to continue.

4 Select the CMS to configure. Click Next to continue.


6 Select the Update a Content Application Server option. Click Next to continue. A list of CASs configured on this host opens.

7 Select the CAS whose StoryServer.cfg file you want to modify. Click Next to continue. The Choose editor window opens.

8 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 CAS’s StoryServer.cfg file is opened using your selected file editor.

9 Modify the file as needed. (See other sections in this chapter.)

10 Save your changes and close the file. A confirmation message asks you to confirm that you want to commit the changes to the CAS’s StoryServer.cfg file.

11 Choose one of the following options:

• Test changes [recommended] - The program ensures that all services 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


03/01/99 11-5

the CAS’s 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 NTYou 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.

■ To increase Page Generator requests:


2 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.


11-6 03/01/99

4 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

Setting a time limit for page generation prevents a template with a programming error, such as an infinite loop, from tying up a CAS’s 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 CAS’s 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.

Topics include: • Changes from Previous Releases• Setting Page Generation Timeouts• RESET_TIMEOUT Template Command


03/01/99 11-7

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 it’s in, overriding the CTLD_EVAL_TIMEOUT value.

• With the CTLD_EVAL_TIMEOUT variable in the CAS’s 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.

■ To set the Page Generator timeout:



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.

4 Save the changes to the StoryServer.cfg file and restart the web server.


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.


11-8 03/01/99

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. It’s especially useful in library templates. For example, you know a library subroutine takes 10 seconds, but you don’t 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 don’t 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).


03/01/99 11-9

Adjusting Page Generator Logging on Windows NTYou 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 doesn’t 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 CAS’s StoryServer.cfg file.

■ To adjust logging:



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.


Adjusting for Large Database Retrievals on Windows NTIn the DATABASE SERVER SETTINGS section of the CMS’s 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.


11-10 03/01/99

The TEXTSIZE limit applies to database operations as follows:

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.

■ To adjust for large database retrievals:

1 Access the CMS’s pm.cfg file as explained in Editing the pm.cfg File on Windows NT on page 11-2.

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 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.

5 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 CAS’s copy of the pm.cfg file. See Updating a Remotely Installed CAS—Windows NT only on page 8-9.

6 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.

Microsoft SQL Server Applies to read and write operations

Sybase Applies only to read operations

Oracle Does not apply


03/01/99 11-11

Increasing Request Handling on Windows NTThe 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 CMS’s 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 time-consuming operations. There may be some performance cost for increasing the number of requests handled for these operations.

■ To increase request handling:


2 In the PRODUCTION MANAGER SETTINGS section of the file, find this line:

set VHS_POOL_SIZE




5 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 CAS’s copy of the pm.cfg file. See Updating a Remotely Installed CAS—Windows NT only on page 8-9.

6 Access the CAS’s 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.

7 In the PLACEMENT MANAGER SETTINGS section of the file, find this line:

set PAD_POOL_SIZE




11-12 03/01/99


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 Server’s 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 /news/local

2 /news/local

3 /news/local/images


03/01/99 11-13

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.

■ To change the default value for CMD_POOL_SIZE:

1 Start editing the CAS’s StoryServer.cfg file as explained in Editing the StoryServer.cfg File on Windows NT on page 11-3.

2 Find the CMD_POOL_SIZE variable (in the ## CACHE MANAGER SETTINGS section of the file), and change its value.

3 Make the change take effect as explained in Step 11 of Editing the StoryServer.cfg File on Windows NT on page 11-3.

4 Repeat the procedure for each CAS.

Adjusting Web Server Processes on Windows NTMany 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 vendor’s documentation for specific information.

Restricting Access to the Servers on Windows NT

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.

Topics include: • Setting Allowed IP Addresses for the CMS• Setting Allowed IP Addresses for a CAS


11-14 03/01/99

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.

■ To specify allowed IP addresses for the CMS:


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"


4 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 Options—Windows NT only on page 8-8.

5 Change the CASs’ StoryServer.cfg files. See Setting Allowed IP Addresses for a CAS on page 11-15.


03/01/99 11-15

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 couldn’t 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.

■ To set allowed IP addresses for a CAS:


2 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"


4 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 Options—Windows 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 couldn’t connect. Add the IP address to the StoryServer.cfg file. See Viewing StoryServer Log Files on page 6-14.


11-16 03/01/99

03/01/99 12-1

12Tuning StoryServer on Solaris

Summary: 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.


Before you begin: • Monitoring StoryServer Servers and Processes on page 4-1• Managing StoryServer Files on Windows NT or Solaris on

page 6-1

Topics include: • 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

Tuning StoryServer on Solaris Administration Guide

12-2 03/01/99

Increasing Page Generator Requests on SolarisYou 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.

■ To increase Page Generator requests:

1 Open the StoryServer.cfg file:



set CTLD_POOL_SIZE



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 Save the changes to the StoryServer.cfg file.

5 Reset the Page Generator process to read the new configuration file values. See Resetting CAS Processes on page 8-2.

6 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.cfg—Solaris 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.

Administration Guide Tuning StoryServer on Solaris

03/01/99 12-3

Adjusting Page Generator Timeouts on Solaris

Setting a time limit for page generation prevents a template with a programming error, such as an infinite loop, from tying up a CAS’s 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 CAS’s 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 CAS’s 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.

Topics include: • Changes from Previous Releases• Setting Page Generation Timeouts• RESET_TIMEOUT Template Command


12-4 03/01/99

• With a new StoryServer template command, RESET_TIMEOUT. RESET_TIMEOUT resets the timeout value for the template it’s in, overriding the CTLD_EVAL_TIMEOUT value.

■ To set the Page Generator timeout:

1 Open the StoryServer.cfg file:



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.



6 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.cfg—Solaris only on page 8-12.


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.


03/01/99 12-5

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. It’s especially useful in library templates. For example, you know a library subroutine takes 10 seconds, but you don’t 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 don’t 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


12-6 03/01/99

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 SolarisYou 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 doesn’t 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 CAS’s StoryServer.cfg file, you must have system admin user privileges on the host system where the CAS is installed.

■ To adjust logging:

1 Open the StoryServer.cfg file on the CAS:



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.



5 To notify the CMS of the StoryServer.cfg changes, run:


For more information on admin updatepe, see Notifying the CMS of changes to StoryServer.cfg—Solaris only on page 8-12.



03/01/99 12-7

Adjusting for Large Database Retrievals on SolarisIn the DATABASE SERVER SETTINGS section of the CMS’s 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.

■ To adjust settings for large database retrievals:

1 Stop the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.)

2 Open the pm.cfg file for the CMS:

/install-path/StoryServer/Rn/conf/Production/pm.cfg

3 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 Save the changes to the pm.cfg file.

6 Start the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.)

7 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 CAS’s copy of the pm.cfg file. (See Updating a Remotely Installed CAS—Solaris only on page 8-11.)


12-8 03/01/99

8 Open the /install-path/StoryServer/Rn/conf/delivery.tcl file.

9 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 CAS—Solaris 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 SolarisThe 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 CMS’s 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 time-consuming operations. There may be some performance cost for increasing the number of requests handled for these operations.

■ To increase request handling:

1 Stop the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.)

2 Open the pm.cfg file for the CMS:



03/01/99 12-9

3 In the PRODUCTION MANAGER SETTINGS section of the file, find this line:

set VHS_POOL_SIZE




6 Start the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4.)

7 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 CAS’s copy of the pm.cfg file. (See Updating a Remotely Installed CAS—Solaris only on page 8-11.)

8 To adjust the variable for the Placement Manager, open the StoryServer.cfg file for the CAS:


9 In the PLACEMENT MANAGER SETTINGS section of the file, find this line:

set PAD_POOL_SIZE




12 The next time you stop and start the CASs, the Placement Manager process reads the new configuration file values.

13 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.cfg—Solaris only on page 8-12.


12-10 03/01/99

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 Server’s 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 /news/local

2 /news/local

3 /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.


03/01/99 12-11

■ To change the default value for CMD_POOL_SIZE:

1 Start editing the CAS’s 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.

2 Find the CMD_POOL_SIZE variable (in the ## CACHE MANAGER SETTINGS section of the file), and change its value.

3 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.

4 Repeat the procedure for each CAS.

Adjusting Web Server Processes on SolarisMany 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 vendor’s documentation for specific information.

Restricting Access to the Servers by IP address on Solaris

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.

Topics include: • Setting Allowed IP Addresses for the CMS• Setting Allowed IP Addresses for a CAS


12-12 03/01/99

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 CMS’s host.

■ To specify allowed IP addresses for the CMS:

1 Open the pm.cfg file for the CMS: /install-path/StoryServer/Rn/conf/Production/pm.cfg

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"


4 Stop and restart the CMS. (See Stopping and Starting the CMS with the admin Command on page 8-4).

5 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 couldn’t connect. Add the IP address to the pm.cfg file.


03/01/99 12-13

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 CAS’s host.

■ To set allowed IP addresses for a CAS:

1 Open the StoryServer.cfg file for the CAS:


2 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"


4 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 couldn’t connect. Add the IP address to the StoryServer.cfg file.


12-14 03/01/99

03/01/99 13-1

13Transferring Projects between Content Management Servers

Summary: How to transfer projects from one Content Management Server (CMS) to another.


Before you begin: Working with the Database on Windows NT or Solaris on page 7-1

Topics include: • Overview• Requirements, Assumptions, and Restrictions• How Transfer Works• transferproject Syntax• Transferring Projects• Things to Do after Transferring• What’s Transferred and What Isn’t• General Information about Transferring Projects

Transferring Projects between Content Management Servers Administration Guide

13-2 03/01/99

OverviewIf your company has multiple StoryServer CMSs, you may need at times to transfer—copy—a 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 project—including its records, files, and templates, and its subprojects with their records, files, and templates—between CMSs. Both CMSs must be running the StoryServer Platform software, version 4.1 or later.

Requirements, Assumptions, and RestrictionsSome 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.

Administration Guide Transferring Projects between Content Management Servers

03/01/99 13-3

• 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 didn’t 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 projects—especially large ones—at off-peak times.

• transferproject doesn’t 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 What’s Transferred and What Isn’t 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 doesn’t have the autolaunch attribute set: Automatically launch content as soon as workflow completes.


13-4 03/01/99

• 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

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.)

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


03/01/99 13-5

Different operations of the transferproject utility handle both exporting and importing the project:

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 Manager’s 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 project’s 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.

export Exports Project Data

export -r Exports Project Data and any Database Content referenced by records

exportData Exports all Database Content for the project

import Imports Project Data

importData Imports Database Content


13-6 03/01/99

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 CMS’s project hierarchy and imported into different parts of the destination CMS’s 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 sourceCM Server

to destinationCM Server

projectpackage


03/01/99 13-7

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 sourceCM Server

to destinationCM Server

projectpackage


13-8 03/01/99

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 didn’t transfer to the destination project.

Figure 13-3: Project Contents

project on destination CM Server

projectpackage

project on source CM Server


03/01/99 13-9

Typical Transfers

There are three basic situations for project transfer:

• You’re adding a project to a destination CMS, and the project doesn’t already exist on that CMS. For example, you may have added a CMS in another area and want to transfer certain projects to it.

• You’re replacing a project on the destination CMS with some variation of the same project. For example, you may have redesigned the project’s 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.

Here’s a typical sequence for transferring a project. It assumes that you’re importing a project that’s 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.

2 With transferproject’s 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 What’s Transferred and What Isn’t 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 With transferproject’s exportData operation, export the database content for the project from the source CMS.

4 At the destination CMS, check the attributes of the project under which the new project will be imported (the destination parent project). Turn off


13-10 03/01/99

automatic launch if you don’t want the transferred content items to go Live immediately. See transferproject on page A-31.

5 Import the database content to the destination CMS with transferproject’s importData operation.

6 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.

7 Import the StoryServer project data to the destination CMS with transferproject’s import operation. You specify the parent project for the transferred project.

8 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.

9 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, there’s no need to transfer the tables. If the content database isn’t accessible to the


03/01/99 13-11

destination CMS, you may wish to use a database tool, such as Sybase’s bcp, to transfer the tables more efficiently.

Or suppose a project contains templates that reference content (for example, with the SEARCH command), but you haven’t created any records for the content. (A database row requires a record only if you want to manage its production—workflow, launch schedule, and so on—through the StoryServer Production Center.) In that case, there’s 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 project—to 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 doesn’t 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 project’s 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, it’s preferable to import a project’s 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 transferproject’s export operation creates the project package in the directory/opt/ssxfer, the directory will contain this set of files:


13-12 03/01/99

ssxfer.attr(ssxfer.tar) or (ssxfer.zip and ssxfer.exe)ssxfer.datassxfer.purgessxfer.sch.sybssxfer.sch.infssxfer.sch.mssssxfer.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. transferproject’s 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.


03/01/99 13-13

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 SyntaxThe transferproject command resides in the StoryServer operating-system directory below the bin directory. The default locations:

• SUN

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

• NT

\Program Files\Vignette\StoryServer n\Engines\Rn\bin\winnt


13-14 03/01/99

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 performs—export the StoryServer project data, export the database content, import the StoryServer project data, and so on—with 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]


03/01/99 13-15

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 -?


13-16 03/01/99

Transferring Projects

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 you’re exporting, importing, or deleting database content:

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


03/01/99 13-17

• 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 transferproject’s -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 isn’t 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 isn’t 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 don’t 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.


13-18 03/01/99

Import Conflicts

Before importing a project, transferproject’s import operation checks for conflicts between the project data and the StoryServer data for the destination CMS’s 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 you’re importing contains a template named Catalog Insert.If a template with that name already exists on the destination CMS, the transfer won’t 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 doesn’t 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 project’s StoryServer project data, you must know the StoryServer management ID of the project to export. When you import a project’s project data, you need the ID of the project to put the new project under. To delete a project, you need its ID.


03/01/99 13-19

■ To find project IDs through the StoryServer Tools Project Manager:

1 From the StoryServer Tools launch bar, open the Production Center’s Project Manager.

2 Check the project’s management ID in either of these ways:

• Select the project, open its Details window, and go to the Misc page. You’ll see this line: Management ID: /pr/number.

• Select the project’s parent project in the Projects pane. The management ID of the project you’re looking for is probably listed in the Contents pane. If it isn’t, 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 project’s 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 it’s 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.


13-20 03/01/99

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 project’s StoryServer project data and its database content, you can specify the -r option when you execute transferproject’s 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 you’re replacing tables in the destination database, remember that tables created with export -r will contain content rows for the imported project’s 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 project’s 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.


03/01/99 13-21

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 project’s StoryServer project data and its database content:

transferproject -o export -r -b sable:37500:/pr/22 -p /prog/prtransfer -l Admin:Bnutmeg31

If transferproject can’t 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■ 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 aren’t 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 project’s Details window. See transferproject on page A-31.

2 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.


13-22 03/01/99

• 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 isn’t 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.

4 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 you’re importing. See transferproject Syntax on page 13-13 for other argument descriptions.

As transferproject imports the project package, it reports that it’s 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 won’t be available unless they’ve 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


03/01/99 13-23

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.

2 If the project package isn’t 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.

3 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 it’s 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 haven’t 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.)


13-24 03/01/99

The following command imports the project package that’s 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 can’t 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 package’s purge file. With -k, deleteData deletes the remaining tables, even though it couldn’t delete the one you dropped.

• You’re 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 couldn’t create the third.

• You’re 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 couldn’t 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 haven’t specified -k. Take the middle example above—you’re 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 doesn’t occur until after the importData operation has created the two other tables. If the


03/01/99 13-25

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 don’t 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 can’t 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 you’re 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 32k–1 characters. Oracle character columns have a maximum of 2000 characters.


13-26 03/01/99

Deleting StoryServer Project Data

You delete a project’s StoryServer project data with transferproject’s delete operation. The StoryServer project data includes all the project’s contents and the subprojects under it in the project hierarchy.

When you delete projects, be sure you’re 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 it’s 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 project’s 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 can’t delete the Base Project, /pr/a. If you try to delete it, transferproject displays a message that deleting the Base Project isn’t 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 what’s in them.

To see what tables deleteData will drop, check the package-directory-name.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.


03/01/99 13-27

To delete a project’s 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 transferproject’s -o export operation or -o exportData operation, move it if the project package directory isn’t 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:


13-28 03/01/99

1 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).

2 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 TransferringSome 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. (There’s 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 doesn’t already exist. A table requires an entry in the next_id table if it’s 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,


03/01/99 13-29

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.

What’s Transferred and What Isn’tThe 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 aren’t transferred are handled.

The following table shows which project properties transferproject transfers.

Project Property Transferred? Inherited or Replaced?

parent project no replaced with destination parent project

name yes

attributes (final review by owner, automatic launch, automatic versioning on launch)

no inherited from destination parent project

project owners no inherited from destination parent project

authorized users no inherited from destination parent project

default template paths yes

default workflows no inherited from destination parent project

management ID no inherited from destination parent project

history no no


13-30 03/01/99

NOTE: transferproject exports the current copy (last saved copy) of records, files, and templates.

The following table shows which template properties transferproject transfers.

keywords yes/no 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 no no

notes no no

tasks no no

subprojects yes

templates yes

files yes

records yes

rows (database content) yes (with export -r or exportData)

Template Property Transferred? Inherited or Replaced?

name yes

cache setting yes

body yes

internal-use-only setting yes

paths yes

Project Property Transferred? Inherited or Replaced?


03/01/99 13-31

The following table shows which record properties transferproject transfers.

primary table yes

file extension yes

category yes

template ID no replaced with new one

management ID no replaced with new one

workflow no no

status yes/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 no no

versions no no

keywords yes category:keyword information is maintained in transferred templates and the Keyword Manager for the destination CMS is updated with any new information.

notes no no

Record Property Transferred? Inherited or Replaced?

name yes

table name yes

Template Property Transferred? Inherited or Replaced?


13-32 03/01/99

The following table shows which file properties transferproject transfers.

database information (server, database name, primary key name)

no replaced with destination server’s database information

database no replaced with new one


workflow no no

status yes/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

history no no

versions no no

keywords yes category:keyword information is maintained in transferred records, and the Keyword Manager for the destination CMS is updated with any new information

notes no no

File Property Transferred? Inherited or Replaced?

name yes

content yes

path yes


workflow no no

Record Property Transferred? Inherited or Replaced?


03/01/99 13-33

General Information about Transferring Projects

StoryServer Authorizations

The following table shows the required StoryServer authorizations for transferproject operations. Members of the Admin group are authorized for all operations.

status yes/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

history no no

versions no no

notes no no

Topics covered: • StoryServer Authorizations• Parent Project and Status of Imported Content Items• Contents of Project Package

Operation StoryServer Authorization Needed

delete Owner of destination project’s 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)

deleteData Any StoryServer user of the destination CMS

export Any StoryServer user of the source CMS

exportData Any StoryServer user of the source CMS

exportForm Any StoryServer user of the source CMS

import Owner of the parent project on the destination CMS

File Property Transferred? Inherited or Replaced?


13-34 03/01/99

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 aren’t 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:

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.

It’s advisable to set up a “safe” parent project when you first begin working with transferproject: a project that isn’t set to launch content automatically.

importData Any StoryServer user of the destination CMS

importForm User with Content Designer authorization on the destination CMS

Content ItemStatus before Export (on Source CMS)

Status after Import (on Destination CMS)

Record, file, or launchable template

Live Live(unless you use the -s option, in which case Live becomes Ready to Launch)

Record, file, or launchable template

Ready To Launch, Awaiting Final Review, or Working

Ready To Launch

Internal use only template

Ready for Internal Use, Awaiting Final Review, or Working

Ready For Internal Use

Operation StoryServer Authorization Needed


03/01/99 13-35

The autolaunch attribute is set on the General page of the project’s 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.attrpackage-directory-name.file-formatpackage-directory-name.datapackage-directory-name.purgepackage-directory-name.sch.sybpackage-directory-name.sch.infpackage-directory-name.sch.msspackage-directory-name.sch.ora

Two files contain the StoryServer project data: package-directory-name.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 Operation Description

.attr export 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.

.tar export Contains a tar distribution package of the files added to the project as content items. On Solaris, this is the default format.

.zip export Contains a zip distribution package of the files added to the project as content items. On Windows NT, this is the default format.


13-36 03/01/99

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 file’s 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.

.data exportDataexport -rexport

Contains formatted data for the tables identified with exportData or export -r.

.purge exportDataexport -rexport

Contains information for removing the tables specified with exportData or export -r. Empty if export is specified without -r.

.sch.inf exportDataexport -rexport

Contains create table functions in Informix format for installing the tables specified with exportData. Empty if export is specified without -r.

.sch.mss exportDataexport -rexport

Contains create table functions in MS SQLServer format for installing the tables specified with exportData. Empty if export is specified without -r.

.sch.ora exportDataexport -rexport

Contains create table functions in Oracle format for installing the tables specified with exportData. Empty if export is specified without -r.

.sch.syb exportDataexport -rexport

Contains create table functions in Sybase format for installing the tables specified with exportData. Empty if export is specified without -r.

Extension Operation Description

03/01/99 A-1

A StoryServer Process Reference

Summary: A quick reference for processes followed by detailed information for each.


Before you begin: Managing StoryServer Processes on Windows NT or Solaris on page 8-1

Topics include: • Process Reference• admin (CAS)• admin (CMS)• bob• cmd• config• ctld• expire• flushcache• inboundmail

• launch• logroller• pad• setup• ss• ted• tmd• transferproject• version• vhs

StoryServer Process Reference Administration Guide

A-2 03/01/99

Process ReferenceThis appendix contains information on the following StoryServer processes (services) and commands:

Process Type Description

admin (CAS) CLI Lets you check or change state of a CAS or CMS process

admin (CMS)

bob CMS process Dispatches all CMS transactions

cm NTcmd SUN

CAS process Cache Manager

config SUN Component Settings Configures CAS components

ctld CAS process Page Generator

expire Task executable Expires records, files, or templates

flushcache Task executable Clears pages from a specified location

inboundmail Task executable Converts e-mail data into multi-part form data and issues a post to a URL

launch Task executable Launches records, files, and templates

logroller SUN Task executable Archives StoryServer.errors log

pad CAS process Placement Agent

pznd (not discussed here)

CAS process Observation Manager (See Business Center and Open Profile Services Guide)

setup NT Component Settings Configures CAS components

ss Task executable Starts the launch bar for the UI on the chosen operating system

ted CMS process Event Service

tmd CAS process Template Manager

transferproject CLI Transfers project info from one CMS to another

version Task executable Creates, names, restores, or deletes versions of files, records, or templates

vhs CMS process Request Service

Administration Guide StoryServer Process Reference

03/01/99 A-3

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.


Subcommands

reset SUN

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.


A-4 03/01/99

start

Restarts the processes for the CAS. (It stops and then starts the processes.)

status SUN

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 SUN

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 SUN

Updates the CMS with configuration information from the CAS config file:


update_pmcfg SUN

Updates the remotely installed CAS with configuration information from the CMS’s /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


03/01/99 A-5

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.



A-6 03/01/99

Subcommands

start

Starts all processes (services) in the CMS. Enables communication with the StoryServer database.

status SUN

Returns status on all processes of the CMS.

stop

Stops all processes in the CMS. Use the CMS’s 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

bobDispatches all CMS transactions.


Vignette 4.2 Dispatch Service


03/01/99 A-7

DescriptionAll 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/CAS—Windows NT only on page 9-2.


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


A-8 03/01/99

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.

Windows NT Service NameVignette 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.


03/01/99 A-9


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

configConfigures StoryServer system components (Solaris only).

Synopsis/install-path/StoryServer/Rn/adm/config

Description

This interactive script enables you to configure a StoryServer CMS or a StoryServer CAS and update or delete the Vignette demonstration projects on


A-10 03/01/99

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 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


03/01/99 A-11

/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.

Windows NT Service NameVignette 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 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

• SUN

/install-path/StoryServer/Rn/conf/delivery.tcl

/install-path/StoryServer/Rn/lib/stdlib.tcl



A-12 03/01/99

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


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/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


03/01/99 A-13

/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

expireAn 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)

DescriptionThe expire command is used primarily as a program task in the Task Manager or Project Manager. Typically, it’s 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 project’s 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,


A-14 03/01/99

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.


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.

ExampleAlmost 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.


03/01/99 A-15

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 server’s 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 isn’t 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 CAS’s 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.


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.


A-16 03/01/99

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.

Optionshost

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

ExampleThe 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 Manager’s port is 13625, on system sysA.

flushcache sysA 13625 /OurSite/Books


inboundmailA 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.


03/01/99 A-17

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 multi-part/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.


A-18 03/01/99

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".


03/01/99 A-19

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.

Exampleinboundmail -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

launchLaunches 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


A-20 03/01/99

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.


Options-r

Recursively launches all records, files, and templates that are available to be launched through all subprojects and at the top project level.


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.

ExampleAlmost 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



03/01/99 A-21

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.

logrollerArchives the StoryServer.errors log (Solaris only).

Synopsis/install-path/StoryServer/Rn/taskbin/solaris/logroller [-c] [-s srcdir] [-d destdir] [-f file1 file2 ...]

Description

The /install-path/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.


The syslogd must be running where StoryServer is installed for logroller to work. The logroller command does not interfere with logging—no messages are lost when it runs.

Optionsc

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.


A-22 03/01/99

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 Renames the /var/adm/StoryServer.errors log file to /var/adm/StoryServer.error.timestamp

2 Reinitializes the /var/adm/StoryServer.errors log file


03/01/99 A-23

3 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

padThe 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.


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


A-24 03/01/99

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

setupStoryServer Platform Configuration Program


03/01/99 A-25

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.


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

ssStarts the StoryServer launch bar for the user interfaces on the chosen operating system.


A-26 03/01/99

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).


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


03/01/99 A-27

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 don’t 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 that’s 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:

• SUN %HOME

• NT %HOME% or %HOMEDRIVE%HOMEPATH%

For example:

NT -homeDir D:

SUN -homeDir /u/angus/myStory


A-28 03/01/99

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


03/01/99 A-29

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

tedTracks timed events for the main CMS process.


Vignette 4.2 Event Service

DescriptionThe ted process tracks scheduled events for the CMS.



A-30 03/01/99

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.


03/01/99 A-31


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



transferprojectMoves project content and project information from one CMS to another.


A-32 03/01/99

DescriptionIf your company has multiple StoryServer Content Management Servers (CMSs), you may need at times to transfer—copy—a 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


03/01/99 A-33

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 project’s 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


A-34 03/01/99

-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


03/01/99 A-35

more than one table, it must be enclosed in double quotation marks. The tables must be in the source CMS’s 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 item’s 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 Don’t transfer any objects if there is a single conflict (default behavior).

• -z 1 Don’t 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.

versionCreates, names, restores, or deletes a version of records, files, or templates


A-36 03/01/99

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)

DescriptionThe 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 project’s 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.



03/01/99 A-37

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.


A-38 03/01/99


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 you’re 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 you’re 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


03/01/99 A-39

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


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


A-40 03/01/99

vhsManages requests for the CMS.

Windows NT Service NameVignette 4.2 Request Service

Description

The vhs process manages requests for the CMS.


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


03/01/99 A-41

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


A-42 03/01/99

03/01/99 B-1

B StoryServer File Reference

Summary: A quick reference for files and directories followed by detailed information for each.


Before you begin: Managing StoryServer Files on Windows NT or Solaris on page 6-1

Topics include: • 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

StoryServer File Reference Administration Guide

B-2 03/01/99

File ReferenceThis 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 Type Description

cmd.log Log file Log file for Cache Manager

cmd.pid SUN Process ID file ID for Cache Manager

ctld.log Log file Log file for Page Generator

ctld.log.id Log file Log file for Page Generator slave process

ctld.pid SUN Process ID file ID for Page Generator

ctldinfo.log Log file Log of transactions and errors for the Page Generator master process

ctldinfo.log.id Log file Log of transactions and errors for the Page Generator master process

delivery.tcl Configuration file Global information for the Page Generator process

docroot Directory On-line StoryServer information that your web browser can access

lastsession.cfg SUN Configuration file Information from the last configuration of a CAS

macrodata Configuration file A list of preferred macros to use in the Template Editor, including personal versions of the default macros

Administration Guide StoryServer File Reference

03/01/99 B-3

metafiles Directory Binary versions of the browser capabilities of corresponding templates

obj.conf Configuration file A backup copy of the NSAPI configuration file for a Netscape web server

PadArchiveDir Directory Last version of replaced or deleted static files

pad.log Log file Log of transactions and errors for the Placement Manager master process

pad.log.id Log file Log of transactions and errors for a Placement Manager slave process

pad.pid SUN Process ID file ID for Placement Manager

PadWorkDir Directory Placement Manager working files

plugin.log Log file Log of transactions and errors from the StoryServer web server module

pm.cfg Configuration file Configuration information for the CMS

pm.log Log file Log of transactions and errors for the main CMS process

Preferences Configuration file Preferences for the browser to use for previewing templates, and for viewing on-line documentation



B-4 03/01/99

StoryServer.cfg Configuration file Variable settings for the StoryServer CAS processes

StoryServer.errors SUN Log file Errors in the CAS

SUNTasksWorkingDirsRoot

NTTedTasksWorkingDirsRoot

Directory Timed-event process working files

ted.log Log file Transactions and errors for the timed-event process

templates Directory Template cache written by tmd and read by ctld

tmd.log Log file Transactions and errors for the Template Manager process

tmd.pid SUN Process ID file ID for Template Manager

vhs.log Log file Transactions and errors for the CMS request-handling master process

vhs.log.id Log file Transactions and errors for a CMS request-handling slave process

VhsProtoDocRoot Directory Request handler working copies of the static files that it has processed



03/01/99 B-5

cmd.logAudits 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


DescriptionThe cmd.log file contains the chronological list of transactions and errors for the Cache Manager process.

The level of logging is set in the CAS’s 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.


Example locations:

NT D:\Program Files\VIgnette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\cmd.log

SUN /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


B-6 03/01/99

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.pidContains the process ID for the Cache Manager process (Solaris only)

DescriptionThe /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.


An example location:

/opt/StoryServer/R4.2/conf/thor-9090-1/cmd.pid

Files/install-path/StoryServer/Rn/bin/solaris/cmd

Cache Manager executable


Audit log for the Cache Manager process

ctld.logTracks errors generated by the StoryServer LOG command for the Page Generator process.


03/01/99 B-7

Location

Windows NT

\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctld.log

Solaris


DescriptionThe ctld.log file contains messages generated by the StoryServer LOG command for the Page Generator master process (ctld).


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\ctld.log

SUN /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



\install-path\StoryServer n\Engines\Rn\conf-n\host-port-number\ctld.log.id

LOG command error log for the slave process having the id number




B-8 03/01/99


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.idTracks errors generated by the StoryServer LOG command for the Page Generator slave process having the id number.


03/01/99 B-9

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

DescriptionThe ctld.log.id file contains the messages generated by the StoryServer LOG command for the Page Generator slave process (ctld) having the id number.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\at.mycompany.com-9090\ctld.log.2

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/ctld.log.3

Files

Windows NT






LOG command error log for the Page Generator service




B-10 03/01/99





Solaris






LOG command log for the Page Generator master process









ctld.pidContains the process identification number for the Page Generator process (Solaris only).


03/01/99 B-11

DescriptionThe /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.



/opt/StoryServer/R4.2/conf/thor-9090-1/ctld.pid

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





LOG command log for the Page Generator process









ctldinfo.logAudits transactions and errors for the Page Generator master process.


B-12 03/01/99

Location

Windows NT

\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctldinfo.log

Solaris


DescriptionThe 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 CAS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompany.com-9090\ctldinfo.log

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/ctldinfo.log

Files

Windows NT






03/01/99 B-13


Audit log for the Page Generator slave process having the id number


LOG command log for the Page Generator service





Solaris















ctldinfo.log.idAudits transactions and errors for the Page Generator slave process having the id number.


B-14 03/01/99

Location

Windows NT

\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\ctldinfo.log.id

Solaris


DescriptionThe 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 CAS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompany.com-9090\ctldinfo.log.4

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/ctldinfo.log.4

Files

Windows NT






03/01/99 B-15


LOG command log for the Page Generator service




Audit log for the Page Generator master process



Solaris















delivery.tclContains global information for the Page Generator processes in a StoryServer installation.


B-16 03/01/99

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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\delivery.tcl

SUN /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




03/01/99 B-17



Solaris







docrootContains 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

DescriptionThe 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.


B-18 03/01/99


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \docroot

SUN /opt/StoryServer/R4.2/docroot

lastsession.cfgContains 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.



/opt/StoryServer/R4.2/adm/lastsession.cfg

File/install-path/StoryServer/Rn/adm/config

Configuration script


03/01/99 B-19

macrodataContains 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.


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

SUN /u/henry/.vgn/macrodata


B-20 03/01/99

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 SUN /install-path/StoryServer/Rn/ui/lib/macrodata

metafilesContains 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


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Rn \conf-n\art.mycompany.com-9090\metafiles\

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/metafiles/


03/01/99 B-21

obj.confContains 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

DescriptionThe obj.conf file provides a backup copy of web server mappings before StoryServer modifications.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\obj.conf

SUN /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.


B-22 03/01/99

Example locations:

NT \Myinstall\netscape\https-hannibal\config\obj.conf

SUN /Myinstall/netscape/https-hannibal/config/obj.conf

PadArchiveDirContains 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompany.com-9090\PadArchiveDir\

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/PadArchiveDir/

pad.logAudits transactions and errors for the Placement Manager master process.


03/01/99 B-23

Location

Windows NT

\install-path\StoryServer n\Engines\Rn \conf-n\host-port-number\pad.log

Solaris


DescriptionThe pad.log file contains the chronological list of transactions and errors for the Placement Manager process.

The level of logging is set in the CAS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\pad.log

SUN /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


B-24 03/01/99

Solaris

/install-path/StoryServer/Rn/bin/solaris/pad

Placement Manager process




Process ID file for the Placement Manager

pad.log.idAudits 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 CAS’s 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.



03/01/99 B-25

Example location would be:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\pad.log.2

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/pad.log.8711

Files

Windows NT





Solaris







pad.pidContains 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.


B-26 03/01/99



/opt/StoryServer/R4.2/conf/thor-9090-1/pad.pid

Files/install-path/StoryServer/Rn/bin/solaris/pad






PadWorkDirContains 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.



03/01/99 B-27

Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\PadWorkDir\

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/PadWorkDir/

Files

Windows NT







Solaris









plugin.logAudits transactions and errors from the StoryServer web server module.


B-28 03/01/99

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

DescriptionThe 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 CAS’s 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 CAS’s 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 CAS’s 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 CMS’s pm.cfg file.


Example location would be:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompany.com-9090\plugin.log.2

SUN /opt/StoryServer/R4.2/conf/art-9090-1/plugin.log.8711


03/01/99 B-29

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.cfgContains 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.


B-30 03/01/99


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.cfg

SUN /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 CAS—Windows NT only on page 8-9.

• Updating a Remotely Installed CAS—Solaris 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


03/01/99 B-31

pm.logAudits 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 CMS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.log

SUN /opt/StoryServer/R4.2/conf/Production/pm.log

Files

Windows NT


Main CMS service


B-32 03/01/99

Solaris


Main CMS process

PreferencesContains 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.


03/01/99 B-33

Example locations include:

NT C:\myHome\Vignette\Preferences

SUN /u/henry/.vgn/Preferences

StoryServer.cfgContains 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 CAS’s 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.cfg—Solaris only on page 8-12

For more information on StoryServer.cfg modifications, see one of the following:


B-34 03/01/99

• Tuning StoryServer on Windows NT on page 11-1

• Tuning StoryServer on Solaris on page 12-1


Example locations:

NT D:\Program Files\Vignette\StoryServer 4\Engines\R4.2 \conf-2\al.mycompany.com-909\StoryServer.cfg

SUN /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, "C:/Program Files/Vignette/StoryServern/Engines/R4.2/conf-n/ti.myco.com-93/tmd.log") rather than an expression (for example, "C:/$MYINSTALL/conf/ti.myco.com-93/tmd.log").

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

/install-path/StoryServer/Rn/bin/solaris/cmd

Cache Manager process


03/01/99 B-35





/install-path/StoryServer/Rn/bin/solaris/tmd

Template Manager process

StoryServer.errorsTracks 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.

TasksWorkingDirsRootContains timed-event process working files.

Location

Windows NT



B-36 03/01/99

Solaris

/install-path/StoryServer/Rn/taskbin/solaris/TasksWorkingDirsRoot/

DescriptionThe TasksWorkingDirsRoot/ directory contains files being processed by the timed-event process.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\TedTasksWorkingDirsRoot\

SUN /opt/StoryServer/R4.2/taskbin/solaris/TasksWorkingDirsRoot/

Files

Windows NT


Timed event service

Solaris


Timed-event process

ted.logAudits transactions and errors for the timed-event process.

Location

Windows NT

\install-path\StoryServer n\Engines\Rn\conf-n\Production\ted.log


03/01/99 B-37

Solaris

/install-path/StoryServer/Rn/conf/Production/ted.log

DescriptionThe ted.log file contains the chronological list of transactions and errors for the timed-event process.

The level of logging is set in the CMS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\pm.log

SUN /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


B-38 03/01/99

templatesTemplate 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

DescriptionThe 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


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\al.mycompnay.com-9090\templates\

SUN /opt/StoryServer/R4.2/conf/thor-9090-1/templates/


03/01/99 B-39

Files

Windows NT


Page Generator service



Solaris





tmd.logAudits 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.


B-40 03/01/99

The level of logging is set in the CAS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\art.mycompnay.com-9090\tmd.log

SUN /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.pidContains 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


03/01/99 B-41

processes use the information in this file to locate the Template Manager process.



/opt/StoryServer/R4.2/conf/thor-9090-1/tmd.log

Files/install-path/StoryServer/Rn/bin/solaris/tmd




vhs.logAudits 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 CMS’s pm.cfg file in the VHS_LOG_LEVEL variable. A value of 3 or 4 causes information to be


B-42 03/01/99

written to this file. For information on log levels, see Viewing StoryServer Log Files on page 6-14.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\vhs.log

SUN /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.idAudits transactions and errors for the slave process having the id number.


03/01/99 B-43

Location

Windows NT

\install-path\StoryServer n\Engines\Rn \conf-n\Production\vhs.log.id

Solaris


DescriptionThe 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 CMS’s 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.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\vhs.log.2

SUN /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


B-44 03/01/99

Solaris


Request-handling process


Audit log for the request-handling process

VhsProtoDocRootContains 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


DescriptionThe VhsProtoDocRoot directory contains files being processed by the request handler.

Each time a user adds a static content file (any content that doesn’t reside in the database) via the New option of the Project Manager File command, StoryServer creates the file in the CMS’s VhsProtoDocRoot directory:

NT \install-path\StoryServer n\Engines\Rn \conf-n\Production\VhsProtoDocRoot

SUN /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.


03/01/99 B-45

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 CAS’s web server to the docroot of another development CAS’s web server to avoid exposing files in progress on a live CAS.


Example locations:

NT D:\Program Files\Vignette\StoryServer n\Engines\Rn \conf-n\Production\VhsProtoDocRoot

SUN /opt/StoryServer/R4.2/conf/Production/VhsProtoDocRoot


B-46 03/01/99

03/01/99 C-1

C Remote Operations

Summary: Configuring systems with firewalls or proxy servers.


Before you begin: Managing StoryServer on Windows NT and Solaris on page 9-1

Topics include: • Overview• Connections Inside a Firewall• CAS Outside the Firewall• StoryServer Sessions Outside the Firewall• Outbound Connections via HTTP Proxy• StoryServer Sessions Using SOCKS Proxy

Remote Operations Administration Guide

C-2 03/01/99

OverviewYou 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 FirewallWhen all of StoryServer’s 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.

Administration Guide Remote Operations

03/01/99 C-3

CMS connects to a CAS

The CMS’s vhs process requires one port to connect to a CAS’s 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)


C-4 03/01/99

Figure C-1: Ports required with all StoryServer elements inside firewall

StoryServerDB Live

CAS


WebServer

INTERNET

Router/Firewall

/DocRoot

DevelopmentCAS


WebServer

/DocRoot

CMServer

saga:7007

StoryServer sessions

1 1 1

1

11

2

55


03/01/99 C-5

CAS Outside the FirewallFigure 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.


When a CAS is outside the firewall, assume outbound connections are not restricted.

Live CAS connects to the CMS


When the CAS is outside the firewall, this connection requires a hole in the firewall.


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 CAS’s web server

An Internet request requires one port to connect to the web server.


C-6 03/01/99

Figure C-2: Request connections required with live CAS outside firewall

StoryServerDB Live

CAS


WebServer

INTERNET

Router/Firewall

/DocRoot

DevelopmentCAS


WebServer

/DocRoot

CMServer

saga:7007


1 1 1

111

2

5

1

1

5


03/01/99 C-7

StoryServer Sessions Outside the Firewall

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:



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)


When a CAS is outside the firewall, assume outbound connections are not restricted.



When the CAS is outside the firewall, this connection requires a single hole in the firewall.

Topics include: • Setting the VHS_PORT Variable• Working with IP-aliasing Firewalls


C-8 03/01/99




Internet connects to the Live CAS’s web server



03/01/99 C-9

Figure C-3: Request connections required with sessions outside firewall

StoryServerDB Live

CAS


WebServer

INTERNET

Router/Firewall

/DocRoot

DevelopmentCAS


WebServer

/DocRoot

CMServer

saga:7007


1 1 1

111

2

5

1

1

5

25VHS_PORT


C-10 03/01/99

Setting the VHS_PORT Variable

You give the StoryServer session the correct port for the CMS’s 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 CMS’s pm.cfg file.

■ To set the VHS_Port variable:

1 Open the CMS’s pm.cfg file, as explained in CMS Configuration File (pm.cfg) on page 6-3.

2 Uncomment the following line and add your specified port (use a value greater than 1024):

set VHS_PORT 30211

3 Save the change to the file.

4 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 Options—Windows 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 machine’s 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■ To work with IP-aliasing firewalls:

1 Ensure that the Domain Name service (DNS) is configured for the internal host name, not the IP address.

2 Set the attr for the vhs process’s host to the hostname rather than the internal IP address.

3 Set the vhs process port to a static number (see Setting the VHS_PORT Variable on page C-10).

4 Create firewall holes for the bob and vhs process ports.

In the following example, assume:

• The vhs process server is baxter.myco.com.


03/01/99 C-11

• 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.

■ To set the vhs host attr:

1 On the CMS’s 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

SUN cd /opt/StoryServer/Rn/bin/solaris

2 Run the following command:

pmcmd -b bobHost:bobPort setsubattr /cf/class [\"VHS\"] \"Host\" \"vhsHost\"

For example:

pmcmd -b baxter.myco.com:30210 setsubattr /cf/class [\"VHS\"] \"Host\" \"baxter.myco.com\"

Outbound Connections via HTTP ProxyFigure 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:



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.


C-12 03/01/99


The CMS’s vhs process requires one port to connect to a CAS’s 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.



When the CAS is outside the firewall, this connection requires a hole in the firewall.




Internet connects to the Live CAS’s web server



03/01/99 C-13

Figure C-4: Request connections required with http proxy server

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

StoryServerDB Live

CAS


WebServer

INTERNET

Router/Firewall

/DocRoot

DevelopmentCAS


WebServer

/DocRoot

CMServer

saga:7007


1 1 1

11

2

5

1

1

httpproxyserver

1

5


C-14 03/01/99

outside the firewall to receive communication from the CMS inside the firewall through the http proxy.

You must specify the http proxy host’s 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.

■ To configure a CAS outside the firewall:

1 You must have a hole (port) in the firewall through which the CAS can contact the CMS.

2 After the CAS is installed and configured on the host outside the firewall, edit the CAS’s StoryServer.cfg file to add the following variables after the WEB SERVER SETTINGS section:

set PROXY_HOST harvey.my.comset 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.cfg—Solaris only on page 8-12.)

4 Stop and restart the CMS to read the new information.

5 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.

6 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.


03/01/99 C-15

StoryServer Sessions Using SOCKS Proxy

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:



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.

Topics include: • StoryServer Sessions and SOCKS on Windows NT• StoryServer Sessions and SOCKS on Solaris


C-16 03/01/99

Figure C-5: Connections required with sessions using SOCKS

StoryServer 4.2 supports StoryServer session communication through a SOCKS proxy server. If you have a SOCKS proxy server set up, you can

StoryServerDB Live

CAS


WebServer

INTERNET

Router/Firewall

/DocRoot

DevelopmentCAS


WebServer

/DocRoot

CMServer

saga:7007


1 1 1

1

11

5 2

5

SOCKSproxyserver


03/01/99 C-17

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

Specifying the Server Using Command-line Options

■ To specify the SOCKS proxy server using command-line options:

1 Start a DOS shell.

2 If necessary, change to the drive on which the StoryServer tool software is installed.

3 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

4 Start the StoryServer session:

ss -s shost:sport

Changing the StoryServer Shortcut Button

■ 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.

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.


C-18 03/01/99

2 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■ 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

2 Start the StoryServer session:

./ss -s shost:sport

03/01/99 D-1

D Managing GroupLens Express

Summary: Information about the management operations you may need to perform for GroupLens Express

Audience: Administrators of the GroupLens Express software


Topics include: • Overview• Setting Environment Variables—Solaris Only• Starting GroupLens Express• Stopping GroupLens Express• Getting Status• Backing Up the Database

Managing GroupLens Express Administration Guide

D-2 03/01/99

OverviewThe 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 Variables—Solaris OnlyBefore 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 you’re using the csh or tcsh shell, source the following file into your user environment: /GLEinstall-path/config/cshprofile. For example:

source cshprofile

If you’re 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

On Solaris■ To start GroupLens Express on Solaris:

1 Log in as system admin user to the host where the GroupLens Express software is installed.

Topics include starting GroupLens Express:

• On Solaris• On Windows NT

Administration Guide Managing GroupLens Express

03/01/99 D-3

2 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■ To start GroupLens Express on Windows NT:


2 To start the GroupLens Express software, open the Services dialog (select Start-Settings-Control Panel-Services).

3 Select the GroupLens Startup service and select Start.

Stopping GroupLens Express

On Solaris■ To perform an orderly shutdown of the GroupLens Express processes on

Solaris:


2 At the command line, enter:

/GLEinstall-path/bin/glshutdown -n

where GLEinstall-path is the directory in which the GroupLens Express software is installed.

Topics include stopping GroupLens Express:



D-4 03/01/99

On Windows NT■ To perform an orderly shutdown of the GroupLens Express software on

Windows NT:


2 To start the GroupLens Express Software, open the Services dialog (select Start - Settings - Control Panel - Services).

3 Select the GroupLens Startup service and select Stop.

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 getting status:


Topics include backing up the database:


Administration Guide Managing GroupLens Express

03/01/99 D-5

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.


D-6 03/01/99

03/01/99 E-1

E Configuring Virtual Hosting

Summary: How to set up virtual hosting for the web servers you use with StoryServer Content Application Servers (CASs)


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

Topics include: • Concepts• Configuring Web Servers• Testing the Virtual Servers• Virtual Server Front Doors• Virtual Hosting and Development

Configuring Virtual Hosting Administration Guide

E-2 03/01/99

ConceptsWhen 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

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. Here’s a summary of how you set up virtual hosting with StoryServer:

http://www.Domain1.com

WebServer

.../DocRoot

Requests for Domain1

http://www.Domain2.com

Requests for Domain2

IP207.8.8.22

IP 2207.8.8.23

.../DocRoot/Domain1 .../DocRoot/Domain2

Administration Guide Configuring Virtual Hosting

03/01/99 E-3

1 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).

2 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 Configure the web server to map IP addresses or hostnames to individual document directories within a common document root directory.

4 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

■ 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).

2 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

Topics include: • Netscape Web Servers• Microsoft IIS 4 Web Servers• Apache Web Servers—Solaris Only


E-4 03/01/99

NOTE: These directory names are case-sensitive.

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

Netscape Web Servers■ 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.

2 Make the following changes from within the Netscape Server Administration interface and save and apply your changes:

3 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"

What How

Set bind-to address. Select web server, select Server Preferences then Network Settings, enter your main IP address in Bind To Address field.

Set the Primary Document Directory.

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.

Set up the hardware virtual server.

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.


03/01/99 E-5

4 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 Updating IIS Settings

2 Obtaining the Web Site ID

3 Updating the Registry

Updating IIS Settings

■ To update IIS settings, from within the Microsoft Management Console (this may be referred to as Internet Service Manager in your menu):

1 Open the Properties for the default or primary web server you named when you configured the StoryServer CAS.

2 With WWW Service selected, click the Edit button. Make the following changes and additions:

What How

Set IP address. 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).

Configure the default home directory as a virtual server.

In the Home Directory panel, append the subdirectory path for the first virtual domain to the Local Path value.


E-6 03/01/99

3 For each additional virtual domain, add a new web site. When responding to the prompts, use the following values:

Obtaining the Web Site ID

You’ll 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

■ 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 haven’t already found this ID.

What Value

IP address The address you want to associate with the virtual domain.

Default directory 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.

Permissions Scripting permissions, to handle server-side includes required by StoryServer.


03/01/99 E-7

3 For each web-site ID key, create the following string-value pairs:

4 Stop and start the web server.

Apache Web Servers—Solaris Only

To configure an Apache web server to use virtual hosting with StoryServer, you essentially add a Vgn_TplPrefix definition to each VirtualHost segment you’ve defined in your Apache configuration file.

■ To set up Apache virtual hosting with StoryServer:

1 Edit the httpd.conf file for the web server configuration. This file is typically in the apache-install-path/apache/conf directory.

2 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


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

String Value

SS Config File 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 The version of the StoryServer platform software. For example, 4.2.

Vgn_TplPrefix The subdirectory, in the primary web site home directory, dedicated to this web site (and IP address). For example, \Domain1 or \Domain2.


E-8 03/01/99

ServerName hostname DocumentRoot docroot-path/domain-path Vgn_TplPrefix /domain-path</VirtualHost>

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>

Argument Description

hostname Hostname for the virtual web server.

StoryServer.cfg-path 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.

StoryServer-shared-lib-path 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.

docroot-path Path to the web server document root directory (which you told to StoryServer during configuration of the CAS).

domain-path Subdirectory in the document root that is dedicated to hostname.


03/01/99 E-9

4 Stop and start the Apache web server.

Testing the Virtual ServersWe 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:

Virtual Server Front DoorsWhen 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

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.

http://www.Domain1.com/ Delivers the home page for the Domain1 virtual server.

http://www.Domain2.com/ Delivers the home page for the Domain2 virtual server.

Topics include: • Setting Up Development CASs• Creating Templates• Submitting Static Files


E-10 03/01/99

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, you’ll 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.

You’ll 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\Domain1C:\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 you’ve 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, it’s important to specify the correct path when submitting


03/01/99 E-11

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, you’d submit the file once, with a path such as /Domain1/images/logo.gif. If you want to use the file in both domains, you’d submit the file twice:

• For Domain1, you’d use the path /Domain1/images/logo.gif

• For Domain2, you’d use the path /Domain2/images/logo.gif


E-12 03/01/99

03/01/99 Index-1

Index

Symbols%2f (in template path) B-20, B-38.vgn subdirectory 6-21, B-19, B-32

AActive Server Pages 10-8, 10-10Admin Center

closing tools 3-6concepts 1-2enabling self-registration 5-6expanding displays 3-5getting help 3-6interfaces 3-4Preferences file 6-20sorting entries 3-5starting tools 3-2terms 1-2tool directories 6-17using tabs 5-2

admin command (CAS) A-3location 8-4start subcommand 8-6stop subcommand 8-6update_pmcfg subcommand 8-11updatepe subcommand 8-12verify subcommand 8-13

admin command (CMS) A-5location 8-3start subcommand 8-4stop subcommand 8-4

administration featuressetting page generation timeouts 11-7,

12-3authorizations for transferring projects

13-33

BBase Project

adding owners 5-6can’t delete 13-26management ID 13-19owners 5-3, 5-13

bob process A-6browser

capabilities 10-2Preferences file 6-20, B-32

Business Centerauthorizing users and groups 5-17,

5-18permissions 5-18

CCache Manager

cmd process A-8cmd.log file B-5cmd.pid file B-6CMD_POOL_SIZE variable 11-12,

12-10process id file B-6

CASadding 9-8, 9-10admin command location 8-4allowing IP addresses 11-15, 12-13Cache Manager A-8configuration file 6-6copy of pm.cfg 6-7copying static files 9-9, 9-10database information 4-5deleting demo project 9-16, 9-18delivery.tcl file 6-7demo project 9-16development mirroring live E-10error logging 6-15file location 6-2files and directories 6-8

Index Administration Guide

Index-2 03/01/99

flushing cache 10-8general information 4-5information 4-4log files 6-8mapping front door CURL 10-2outside a firewall C-5Page Generator A-11Placement Manager A-23pm.cfg file 6-7preview preferences file 6-19process details 4-6process information 4-6process name 3-5removing 9-14resetting processes 8-2restoring demo project 9-16restricting access 11-13, 12-11setting page generation timeouts 11-6setting up virtual hosting E-1setting variables B-33starting processes 8-6starting services 8-6starting using Start menu 8-9static files B-44stopping processes 8-6stopping services 8-6stopping using Start menu 8-9StoryServer.cfg file 6-6, 11-4StoryServer.errors file 6-15Template Manager A-30turning off database password

encryption 7-7updating CMS 8-12updating remote 8-9updating remote CAS 8-11verifying process version 8-13VhsProtoDocRoot directory 9-10viewing information on 4-4viewing process information 4-6

ci_mgmt_id A-14, A-20, A-38CLEAR_CACHE command A-15

cmd process A-8cmd.log file B-5cmd.pid file B-6CMD_ACTION

DELETE A-15RENAME A-15

CMD_POOL_SIZE variable 11-12, 12-10CMS

admin command location 8-3allowing IP addresses 11-14, 12-12configuration file 6-3, B-29details 4-2dispatcher A-6file location 6-2files 6-4increasing request handling 11-11,

12-8IP-aliasing firewalls C-10log file B-31, B-41pm.cfg file 6-3, 11-2pm.log file B-31request handler A-40request handler directory B-44restricting access 11-13, 12-11service dependency 9-2setting VHS_PORT C-10slave process id file B-42starting processes 8-4starting sequence 9-3starting services 8-4starting using Start menu 8-8stopping processes 8-4stopping services 8-6stopping to disconnect 8-5stopping using Start menu 8-8ted.log file B-37timed-event process A-29timed-event process log B-37updating 8-12, 11-5vhs process A-40vhs.log file B-41

Administration Guide Index

03/01/99 Index-3

vhs.log.id file B-42VhsProtoDocRoot directory B-44viewing information on 4-2

commandsencrypt 7-8RESET_TIMEOUT 11-7, 11-8, 12-4,

12-5transferproject 13-1

common variables 1-5COMPONENT command 10-3config script A-9

adding CAS 9-10deleting demo project 9-18removing CAS 9-14restoring demo project 9-19

configurationdatabase password encryption 7-6of StoryServer platform A-9, A-25setting page generation timeouts 11-7,

12-3configuration file

influence 6-11interaction 6-10interaction on single host 6-12interaction with multiple hosts 6-14

Content Management Serverstransferring projects between 13-1turning off database password

encryption 7-7contents of transferproject project package

13-35cshprofile file D-2ctld process A-11ctld.log file B-6ctld.log.id file B-8ctld.pid file B-10CTLD_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-2ctldinfo.log file B-11ctldinfo.log.id file B-13CURL command E-10

Ddatabase

adjusting server settings 11-9, 12-7backing up GroupLens Express D-5content types 1-3disabling access 8-13password encryption 7-5permissions 7-3service dependency 9-2service variables 9-2tables 7-3

database environment variables for transferproject command 13-17

database password encryptionchanging the password 7-9encrypt command 7-8in templates 7-9keywords to search for in templates 7-9overriding configuration in templates

7-10turning off 7-7turning on 7-8

deleting database content with transferproject 13-26

deleting project data with transferproject 13-26

delivery.tclinteraction with StoryServer.cfg 6-12

delivery.tcl file 6-7, 9-5, B-15vdbmsg variable for Solaris 12-8

Demonstration Projectdeleting 9-16

Demonstration projectrestoring 9-17


Index-4 03/01/99

Development Centerpermissions 5-19

dist directory with transferproject command 13-36

docroot directory B-17setting up for virtual hosting E-3

DOCROOT variable 9-10, 9-11

Ee-mail

enabling notifications 5-12SMTP host 5-11

encrypt command 7-8encryption

database password 7-5in templates 7-9

environment variables to set for transferproject command on Solaris 13-16

error logging levels 6-15error messages

archiving 6-16viewing 6-16

errors on Solarissyslogd(1M) 6-15

Event Viewer 6-16EventLog service 6-15exporting project data with transferproject

13-19, 13-20

F-f option to transferproject command 13-35files

in transferproject project package 13-12, 13-35

firewall C-2flushcache command 10-8, A-14

CMD_ACTION variable A-15

GGL_DBROOT variable D-5group

adding entry 5-13Admin 5-2attributes 5-4cloning entry 5-16deleting entry 5-16editing entry 5-14reserved ID 5-2viewing information 5-2

GroupLens Expressgetting status D-4managing D-2starting D-2stopping D-3

HHelp menu 3-6host-port-number variable 1-5HTTP proxy server C-11HTTPD_COMPONENTSCAN variable

10-4HTTPD_FDCURL variable 10-2HTTPD_LOG_BY_PID variable B-28HTTPD_PLUGIN_LOG_LEVEL variable

B-28HTTPD_TIMEOUT variable, not in this

release 11-6, 12-3

Iid variable 1-5IIS

disabling parsing 10-6importing project data with transferproject

command 13-21importing projects, conflicts 13-18


03/01/99 Index-5

INCLUDE LIB command and transferring projects 13-28

Informixdatabase permissions 7-3

INFORMIXDIR and INFORMIXSERVER environment variables for transferproject command 13-17

install-path variable 1-5InstallShield

platform configuration 9-6Internal-use-only template

launch A-20IP address, for virtual hosting E-3IUSR_hostname 10-7

K-k option to transferproject command

13-23when to use 13-24

keywords to find in templates for password encryption 7-9

Llastsession.cfg file B-18launch command A-19LD_LIBRARY_PATH environment

variable for transferproject command 13-17

listiis utility E-6LOG command B-6, B-9login defaults file B-32logroller command 6-16, A-21

MMacro Editor

preferences file B-19macrodata file 6-19, B-19MAX_LOG_SIZE variable B-28metafiles directory B-20Microsoft SQL Server

database permissions 7-3moving the transferproject project package

13-27Music a la Mode 9-16

NNet Perceptions’ GroupLens Express D-2Netscape

NSAPI configuration file B-21next_id table with transferproject

command 13-11, 13-28nobody

reserved id 4-3, 5-2Notepad 11-3NSAPI

obj.conf file B-21

Oobj.conf file B-21Observation Manager

removing on Solaris 9-12removing on Windows NT 9-12

online help 3-6Oracle

database permissions 7-3ORACLE_HOME environment variable

for transferproject command 13-17

Ppad process A-23pad.log file B-22


Index-6 03/01/99

pad.log.id file B-24pad.pid file B-25PAD_POOL_SIZE variable 11-11, 12-8PadArchivesDir directory B-22PadWorkDir directory B-26page generation

disabling 8-14enabling 8-15

Page Generatoradjusting 11-5adjusting logging 11-9, 12-6ctld process A-11ctld.log file B-6ctld.log.id file B-8ctld.pid file B-10CTLD_POOL_SIZE variable 11-5,

12-2ctldinfo.log file B-11ctldinfo.log.id file B-13delivery.tcl file B-15HTTPD_TIMEOUT variable not in

this release 11-6, 12-3increasing requests 11-5, 12-2increasing slave processes 11-5, 12-2master process log file B-11process id file B-10resetting 8-2setting timeout in StoryServer.cfg

11-7, 12-3setting timeout in templates 11-8, 12-5slave process log file B-13templates directory B-38timeouts 11-6

parse-html function 10-3password

for database 7-5setting admin 5-8

PASSWORD variable, encryption 7-9Placement Manager

log file B-22pad process A-23

pad.log file B-22pad.log.id file B-24pad.pid file B-25PadArchiveDir directory B-22PadWorkDir directory B-26process id file B-25slave process id file B-24

Platform Configuration Programaccessing 9-6adding CAS 9-8default editor 11-3editing config files 11-2removing CAS 9-14

plugin.log B-27pm.cfg file 6-3, B-29

CAS copy 6-7database password encryption 7-5editing on Windows NT 11-2increasing request handling 11-11,

12-8SYSTEM_DB_PASSWORD_ENCR

YPTED 7-7SYSTEM_DB_PASSWORD_ENCR

YPTED variable 7-6testing changes 11-2TEXTSIZE variable 11-9, 12-7update_pmcfg subcommand 8-11updating remote CASs 8-9

pm.log file B-31PM_LOG_LEVEL variable B-31Preferences file 6-20, B-32Production Center

archiving log files 6-16enabling self-registration 5-6flushcache command 10-8, A-14inboundmail command A-16launch command A-19logroller command A-21macrodata file B-19Preferences file 6-20setting e-mail preferences 5-11


03/01/99 Index-7

tool directories 6-17transferproject command A-31

program taskflushcache command A-14inboundmail command A-16launch command A-19logroller command A-21

project IDs with transferproject command 13-18

project package with transferproject command 13-9

contents 13-35description of files 13-11dist directory 13-36moving 13-27

project_mgmt_id A-14, A-20, A-38projects

Base Project management ID 13-19finding IDs 13-18StoryServer project data and database

content 13-10transferring between CMSs 13-1

PROXY_HOST variable C-14PROXY_PORT variable C-14

R-r option to transferproject command 13-20remote operations C-2request handler

directory B-44requirements and restrictions for

transferring projects between CMSs 13-2

RESET_TIMEOUT command 11-7, 11-8, 12-4, 12-5

syntax 11-8, 12-5Rn variable 1-5root

mapping front door 10-2

Sschema restrictions for import with

transferproject command, checking 13-25

self-registrationenabling 5-6

setting platform variables 9-5setup program A-25shprofile file D-2SMTP host 5-11SMTP server 4-3SOCKS proxy server C-15ss command A-25static files B-44

copying 9-9, 9-10status of transferred content items 13-34StoryServer

admin tasks 2-2configuring CAS A-9, A-25content types 1-3database 7-2database tables 7-3diasabling database access 8-13disabling page generation 8-14documentation B-17enabling page generation 8-15enabling self-registration 5-6file base location 6-2log files 6-15managing page generation 8-13preference files 6-20session outside a firewall C-7sessions and SOCKS on Solaris C-18sessions and SOCKS on Windows NT

C-17setting variables B-33tool directories 6-17web server module B-28

StoryServer authorizations for transferring projects 13-33


Index-8 03/01/99

StoryServer platformconfiguring A-9, A-25remote operations C-2setting variables 9-5tasks 9-1

StoryServer Platform Configuration Program A-25

accessing 9-6adding CAS 9-8default editor 11-3editing config files 11-2removing CAS 9-14

StoryServer.cfginteraction with delivery.tcl 6-12

StoryServer.cfg file 6-6adjusting CMD_POOL_SIZE variable

11-12, 12-10adjusting CTLD_EVAL_TIMEOUT

11-6, 12-3adjusting CTLD_LOG_LEVEL 11-7,

11-9, 12-6adjusting CTLD_POOL_SIZE 11-5,

12-2, 12-4adjusting PAD_POOL_SIZE 11-11,

12-9adjusting timeouts 11-7, 12-3database password encryption 7-6editing on Windows NT 11-4HTTPD_TIMEOUT variable 11-6,

12-3testing changes 11-4updatepe subcommand 8-12vdbmsg(password_encrypted) variable

7-6, 7-8StoryServer.errors file 6-15, B-35StoryServern variable 1-5Sybase

database permissions 7-3SYBASE environment variable for

transferproject command 13-17syntax of transferproject command 13-13

syslogd(1M) 6-15system

reserved id 5-2SYSTEM_DB_PASSWORD_ENCRYPT

ED variable 7-6, 7-7setting in templates 7-10

Ttar format with transferproject command

13-35TasksWorkingDirsRoot

directory B-35ted process A-29

directory B-36ted.log file B-36TED_LOG_LEVEL variable B-37Template Developer

Preferences file 6-20Template Editor

macro preferences file B-19template location B-20, B-38Template Manager

log file B-39process id file B-40resetting 8-2templates directory B-38tmd process A-30tmd.log file B-39tmd.pid file B-40

templatesdatabase password encryption 7-9encryption 7-9overriding configuration for database

password encryption 7-10setting

SYSTEM_DB_PASSWORD_ENCRYPTED variable 7-10

using RESET_TIMEOUT command 11-8, 12-5


03/01/99 Index-9

vdbmsg(password_encrypted) variable 7-10

templates directory B-38TEXTSIZE variable 11-9, 12-7timed-event process A-29

directory B-35timed-event process log B-36timeouts

for the web server 11-7, 12-5setting for Page Generator 11-6, 11-7,

12-3tmd process A-30tmd.log file B-39tmd.pid file B-40TMD_LOG_LEVEL variable B-40tool directories

Macintosh 6-18Solaris 6-18Windows 6-17

transferproject command 13-1, A-32Base Project management ID 13-19can’t delete Base Project 13-26Content Design Objects 13-13data collections 13-13deleting database content 13-26deleting project data 13-26dist directory 13-36environment variables on Solaris 13-16exporting project data 13-19exporting project data and database

content together 13-20-f option 13-35finding project IDs 13-18form sets 13-13importing project data with

transferproject 13-21INFORMIXDIR and

INFORMIXSERVER environment variables 13-17

-k option 13-23, 13-24keywords

projects 13-30records 13-32templates 13-31

LD_LIBRARY_PATH environment variable 13-17

moving the project package 13-27next_id table 13-11options A-32ORACLE_HOME environment

variable 13-17project data and database content 13-10project package 13-9-r option 13-20requirements and restrictions 13-2status of transferred content items

13-34StoryServer authorizations 13-33SYBASE environment variable 13-17syntax 13-13, A-32what project and content item

properties are transferred 13-29

transferring projects between CMSs 13-1contents of project package 13-35deleting content data 13-26deleting project data 13-26environment variables to set on Solaris

13-16exporting project data 13-19exporting project data and database

content together 13-20files in project package 13-12import conflicts 13-18importing project data 13-21items that must be unique 13-18moving the project package 13-27next_id table 13-11overview 13-4permissions, user IDs, and

authorizations 13-16project package 13-9, 13-11properties that are transferred,


Index-10 03/01/99

inherited, and replaced 13-29requirements and restrictions 13-2schema restrictions 13-25sequence 13-9statuses of transferred content items

13-34StoryServer authorizations 13-33StoryServer project data and database

content 13-10syntax of transferproject command

13-13tar and zip format 13-35things to do after transferring 13-28types of transfer 13-9

Uuser

adding entry 5-6admin 5-2attributes 5-4cloning entry 5-9deleting entry 5-10editing entry 5-8e-mail preferences 5-11enabling self-registration 5-6name guidelines 5-5reserved IDs 5-2viewing information 5-2

Vvariable settings 11-1, 12-1variables for GroupLens Express D-2variations 10-2vdbmsg(maxtext) variable 12-8vdbmsg(password_encrypted) variable 7-6

overriding in templates 7-10version command A-35

project task defaults A-38workflow task defaults A-38

vgn subdirectory 6-21, B-19, B-32vhs process A-40vhs.log file B-41vhs.log.id file B-42VHS_LOG_LEVEL B-41VHS_LOG_LEVEL variable B-43VHS_POOL_SIZE variable 11-11, 12-8VHS_PORT variable C-10VhsProtoDocRoot directory 9-10, B-44Vignette Cache Manager A-8Vignette Dispatch Service A-6Vignette Event Service A-29Vignette Page Generator A-11Vignette Placement Agent A-23Vignette Request Service A-40Vignette subdirectory 6-21, B-19, B-32Vignette Template Manager A-30virtual hosting

configuring E-1virtual server

development CAS E-10front door E-9static files E-11

Wweb browser

docroot directory B-17web server

adjusting processes 11-13, 12-11configuring virtual hosting E-2disabling IIS parsing 10-6disabling Netscape parsing 10-3mapping front door 10-2parse-html function 10-3parsing on Apache 10-8preview preferences file 6-20setting the timeout 11-7, 12-5timeout 11-6, 12-3

web server module


03/01/99 Index-11

error log B-28

Zzip format with transferproject command

13-35

Documents

Vignette Administartion