vignette content management server v6 administration guide

Vignette Content Management Server V6

Administration Guide

Version 6.0

ii Vignette Confidential August 2001

Version

Administration Guide, version 6.0 (August 2001)

Stock Number

SSM-0600-302

Copyrights

Copyright © 1996-2001 Vignette Corporation. All rights reserved. This documentation is an unpublished work and trade secret of Vignette, and distributed only under restriction. This documentation (or any part of it) may not be used, reproduced, stored on a retrieval system, distributed, or transmitted without the express written consent of Vignette. Violation of the provisions contained herein may result in severe civil and criminal penalties, and any violators will be prosecuted to the maximum extent possible under the law.

Disclaimer

Vignette does not warrant, guarantee, or make representations concerning the contents or applicability of the contents of this manual. Vignette reserves the right to change the contents of this manual at any time without obligation to notify anyone of such updates.

Trademarks

Vignette, the V Logo, www.vignette.com, VGM, VPS, Vignette Village, StoryServer, netcustomer, CenterStage and Captivate your Customers are trademarks or registered trademarks of Vignette Corporation in the United States and foreign countries.

Resonate is a registered trademark of Resonate, Inc.

All other referenced marks are those of their respective owners.

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

Contents

1 VCMS Software Basic ConceptsUsing This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2Concepts and Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

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

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

3 Understanding the Admin Center ToolsStarting the VCMS Admin Center Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2Using the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5

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

Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7Closing the Admin Center Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7

4 Viewing VCMS Servers and ProcessesViewing Servers and Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Viewing CMS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

CMS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Viewing CMS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

CMS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . . .4-3CMS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . . .4-4

Viewing CDS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5CDS Information in the Primary Window . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5CDS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5

Viewing CDS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7CDS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . . .4-8CDS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . . .4-8

August 2001 Vignette Confidential iii

Contents Administration Guide

Viewing OMS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14OMS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14

Viewing OMS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15OMS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . .4-15OMS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . .4-16

Viewing VMCS Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18MCS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18

Viewing VMCS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19MCS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . .4-19VMCS Process Information in the Details Window . . . . . . . . . . . . . . . . . . .4-20

5 Managing VCMS Users, Groups, and RolesOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2Managing Users for a New Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4Roles Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5

The VCMS Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5Monitoring Users, Groups, and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6

Viewing User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7Viewing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7Viewing Role Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8

Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8Rules for User Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9Adding, Cloning, Editing, or Deleting Users . . . . . . . . . . . . . . . . . . . . . . . . . .5-9Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10Enabling Self-registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12Setting E-mail Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12

Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15Rules for Group Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15Adding, Cloning, Editing, or Deleting Groups . . . . . . . . . . . . . . . . . . . . . . .5-15Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

Managing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18Rules for Role Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19Adding, Cloning, Editing, or Deleting Roles . . . . . . . . . . . . . . . . . . . . . . . . .5-19Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19

iv Vignette Confidential August 2001

Administration Guide Contents

6 Managing VCMS FilesOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2Understanding Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

Overview of Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3Initialization Files for the Tcl Interpreter. . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5

log Files and pid Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8log and pid File Names and Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8Viewing VCMS Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10

Debugging Templates with the LOG Template Command . . . . . . . . . . . . . . . . .6-12Other Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13

Other CMS Files and Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13Other CDS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14

Understanding Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16Understanding Preference Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16

The security.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17Preferences File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17

7 Managing System and Content DatabasesOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2System Database Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

Database Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4Database Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5

Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5Database Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6Content Databases of Different Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7Configuring a Second Login for the Template Environment . . . . . . . . . . . . . .7-8Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-11Database Access Through Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13

Configuring One or More Content Databases Separate From the System Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13

Performance and Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-15Records and Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16Database Content with or without Production Management . . . . . . . . . . . . .7-17GET_NEXT_ID with Multiple Content Databases . . . . . . . . . . . . . . . . . . . .7-18Setting Database Variables in Tcl Templates . . . . . . . . . . . . . . . . . . . . . . . .7-19

August 2001 Vignette Confidential v


Changing the Default Content Database . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-26The Dispatch Service (bob) and Separate Content Databases . . . . . . . . . .7-31

Handling Legacy Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-33Using the Legacy Record Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-34Modifying the Legacy Save Template for a Nondefault Database . . . . . . . .7-35Creating the Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-36Making the Record Content Live. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-37

8 Managing VCMS ProcessesOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2Using the admin Command to Stop and Start Processes . . . . . . . . . . . . . . . . . . . .8-3

CMS Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5CDS Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5

Using the admin Command to Reset the Template Manager . . . . . . . . . . . . . . . .8-5Refreshing Referenced Configuration Variables. . . . . . . . . . . . . . . . . . . . . . . . . .8-6Obtaining Process Status—Solaris Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7Checking Page Generator Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8Stopping and Starting a CMS from the Start Menu—Windows Only . . . . . . . . .8-8Starting and Stopping with the Platform Manager—Windows Only . . . . . . . . . .8-9

9 Managing the VCMS SiteAccessing the Platform Manager—Windows Only . . . . . . . . . . . . . . . . . . . . . . .9-2Loading or Removing a Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3Synchronizing a Docroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6Gathering Tcl Template Performance Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7

10 Working with Web ServersMapping the Root Path (/) to a Front Door CURL . . . . . . . . . . . . . . . . . . . . . . .10-2Working with Web Server Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3

VCMS Software Changes to the obj.conf File on iPlanet . . . . . . . . . . . . . . .10-4Disabling Parsing on iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4Optimizing the parse-html Function on iPlanet . . . . . . . . . . . . . . . . . . . . . . .10-6Parsing on IIS—Windows Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7Parsing on Apache (Solaris Only) or IHS (AIX Only) . . . . . . . . . . . . . . . . .10-8

Clearing Pages from a Root Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9Using ASP Scripts in Templates—Windows Only . . . . . . . . . . . . . . . . . . . . . .10-11

vi Vignette Confidential August 2001


11 Tuning Your VCMS InstallationOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2Increasing Tcl Page Generator (ctld) Requests . . . . . . . . . . . . . . . . . . . . . . . . . .11-2Adjusting Page Generator Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3

Setting Page Generation Timeouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3Using the RESET_TIMEOUT Template Command . . . . . . . . . . . . . . . . . . .11-4

Accommodating Large Database Retrievals . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5Increasing Request Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6Setting the Thread Pool Size for the Cache Manager . . . . . . . . . . . . . . . . . . . . .11-6Enabling the Cache Manager to Regenerate Cached Pages . . . . . . . . . . . . . . . .11-8Adjusting the Number of Concurrent Web Server Processes . . . . . . . . . . . . . . .11-9Restricting Access to the Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10Enabling VCMS Status Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-11

12 Transferring Projects and Tables between CMSsOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2Requirements, Assumptions, and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . .12-3How to Transfer Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5

Exporting and Importing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5Typical Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10VCMS Project Data and Database Content . . . . . . . . . . . . . . . . . . . . . . . . .12-11Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13

transferproject Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14Transferring Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16

transferproject Permissions and Other Requirements . . . . . . . . . . . . . . . . .12-16Setting Environment Variables on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . .12-17Import Conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18Finding Project IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19Exporting Project Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20Exporting VCMS Project Data and Database Content Together . . . . . . . . .12-21Importing VCMS Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-23Exporting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25Importing Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25Deleting Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29Deleting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-30Moving a Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-31

August 2001 Vignette Confidential vii


Things to Do after Transferring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-32What Is Transferred and What Isn’t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-33General Information about Transferring Projects . . . . . . . . . . . . . . . . . . . . . . .12-38

VCMS Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-38Parent Project and Status of Imported Content Items . . . . . . . . . . . . . . . . .12-39Contents of Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-41

A VCMS Process ReferenceProcess Reference Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5admin (CDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6admin (CMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8admin (VMCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9admin (OMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10admin cfgedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12admin chlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13admin refreshfromdb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16bob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18campadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19cgutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19cld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21ctld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22expire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23flushcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25gencert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-27inboundmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-29launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-32mcd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34omd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34pad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34pzndelete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35reseteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-37sgutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39

viii Vignette Confidential August 2001


ted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39tmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-40transferproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-40version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-49vhs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-54vrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-54vwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-55wscfg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-55

B VCMS File ReferenceFile Reference Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2adminutil.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6asp-id.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7bob.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8bob.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9cds.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10cfgpassword.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11cld-id.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12cld-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13cld-id-timestamp.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14cmd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15cmd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16cms.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16cmscppapi.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-17config.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18ctld-id.#.infolog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19ctld-id.#.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20ctld-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21ctld.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21delivery.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22docroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-23host.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-23insts.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-24jsp-id.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-25jsp-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-26manifest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-27

August 2001 Vignette Confidential ix


mcd-id.deliver.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-28mcd-id.#.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-29mcd-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-30mcs.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-30messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-31metafiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-32metatemplates-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-32obj.conf.vgnbak. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-33omd-id.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-34omd-id.pid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-35oms.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-36pad.#.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-37pad.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-38Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-38security.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-39staticfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-40ted.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-41ted.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-42tedtasksworkingdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-43templates-id. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-43tmd-id.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-44tmd-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-45upgrade.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-46UsrMacroData.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-46vhs.#.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-47vhs.pid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-48vrd-id.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-48vrd-id.pid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-49vwd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-50vwd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-51ws.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-52ws.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-53ws.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-53

x Vignette Confidential August 2001


C System Database TablesVCMS System Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

D Configuring the VCMS Software to Use an LDAP User RepositoryOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3Understanding How the VCMS Software Integrates with LDAP . . . . . . . . . . . . D-5

Using the VCMS Software without LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . D-5Using the VCMS Software with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-6Making a Non-secure Connection to LDAP . . . . . . . . . . . . . . . . . . . . . . . . . D-7Making a Secure Connection to LDAP without Client Authentication . . . . . D-9Making a Secure Connection to LDAP with Client Authentication . . . . . . D-10Security Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-11

Setting up LDAP SSL Certificates and Keys . . . . . . . . . . . . . . . . . . . . . . . . . . D-12Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-12Getting a Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-14Accepting a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-16Installing a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-16

Making LDAP Schema and Database Changes . . . . . . . . . . . . . . . . . . . . . . . . D-17Schema Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-17Database Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-18Index Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-19

Making Configuration Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-20LDAP and Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-21Configuring the VCMS Software to Use LDAP . . . . . . . . . . . . . . . . . . . . . . . . D-22Using LDAP Configuration (for Windows Users) . . . . . . . . . . . . . . . . . . . . . . D-25

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-25Step 1: Starting the LDAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . D-26Step 2: Setting up the Connection between the VCMS software and LDAP D-28Step 3: Specifying SSL Certificate Information . . . . . . . . . . . . . . . . . . . . . D-28Step 4: Choosing Client Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . D-29Step 5: Specifying Client Authentication Information. . . . . . . . . . . . . . . . . D-29Step 6: Setting up LDAP Access Information . . . . . . . . . . . . . . . . . . . . . . . D-31Step 7: Setting up the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-33Step 8: Setting up User Query Information . . . . . . . . . . . . . . . . . . . . . . . . . D-33Step 9: Setting up User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-34Step 10: Setting up Group Query Information . . . . . . . . . . . . . . . . . . . . . . . D-35

August 2001 Vignette Confidential xi


Step 11: Setting up Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-36Step 12: Performing Repository Verification. . . . . . . . . . . . . . . . . . . . . . . . D-36

Using the config Command (for Windows and Solaris Users) . . . . . . . . . . . . . D-39Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-39Step 1: Starting the LDAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . D-41Step 2: Setting up the Connection between the VCMS and LDAP . . . . . . . D-42Step 3: Specifying SSL Certificate Information . . . . . . . . . . . . . . . . . . . . . D-43Step 4: Choosing Client Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . D-44Step 5: Specifying Client Authentication Information. . . . . . . . . . . . . . . . . D-44Step 6: Setting up LDAP Access Information . . . . . . . . . . . . . . . . . . . . . . . D-46Step 7: Setting up the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-47Step 8: Setting up User Query Information . . . . . . . . . . . . . . . . . . . . . . . . . D-47Step 9: Setting up User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-48Step 10: Setting up Group Query Information . . . . . . . . . . . . . . . . . . . . . . . D-49Step 11: Setting up Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-50Step 12: Performing Repository Verification. . . . . . . . . . . . . . . . . . . . . . . . D-50

Things to Do After Configuring the VCMS Software to Use LDAP . . . . . . . . D-52

E Remote OperationsOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2Enabling Communication between VCMS Components . . . . . . . . . . . . . . . . . . E-3Enabling Communication between VCMS Tools and Components . . . . . . . . . . E-7CDS File System Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-9Working with IP Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10Outbound Connections through HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . E-11VCMS Tools Sessions Using SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-12

Specifying the SOCKS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-12

xii Vignette Confidential August 2001


F Configuring Virtual HostingOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-2

How Virtual Hosting Works with the VCMS Software . . . . . . . . . . . . . . . . . .F-3Configuring Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-4

iPlanet Web Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-5Microsoft IIS Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-6Apache Web Servers (Solaris Only) and IHS Web Servers (AIX Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-11

Testing the Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-13Virtual Server Front Doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-14Virtual Hosting and Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-14

Setting up Development CDSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-14Creating Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-15Submitting Static Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-16

Index

August 2001 Vignette Confidential xiii


xiv Vignette Confidential August 2001

1 VCMS Software Basic Concepts

Summary: Basic concepts for administering the Vignette® Content Management Server V6 (VCMS) software and a high-level view of tasks.

Audience: Administrators and other users of the VCMS software

Before you begin, make sure that:

• The VCMS software is installed• A Content Management Server (CMS) component is configured• At least one development Content Delivery Server (CDS)

component is configured for the CMS• (optional) Any Observation Management Server (OMS) and/or

Vignette Multi-Channel Communication Server V6 (VMCS) components are configured

• The VCMS Production Center and Admin Center client tools are installed

Topics include: • Using This Book• Concepts and Terms

August 2001 Vignette Confidential 1-1

VCMS Software Basic Concepts Administration Guide

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 VCMS software Admin Center tools and instructions for using:

— Configuration View to view information about the CMS, CDS(s), VMCS, and OMS components.

— User Manager to view and manage information about VCMS 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 11) provides more detailed information to allow the admin user, usually a system administrator with the System role, to administer the VCMS software through both the Admin Center tools and the command-line interfaces. Chapter 11 explains how to adjust variables to increase performance.

• Part III (Chapter 12) provides complete information about the transferproject utility, which enables you to transfer projects from one CMS to another.

• Appendixes provide:

— Reference pages for processes and files

— Procedural information for using LDAP with the VCMS

— Additional information for optional configurations (including configuring hosts outside the firewall)

— An explanation of virtual hosting

1-2 Vignette Confidential August 2001

Administration Guide VCMS Software Basic Concepts

Concepts and TermsThis book uses the concepts and terms found in Running the Vignette Content Management Tools. It also uses the following concepts and terms to explain VCMS administration.

Content Types

The VCMS 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 the Vignette Content Management Server Overview.

Basic Configuration

Figure 1-1 shows a basic VCMS configuration in which the CMS, development and live CDSs, OMS, and VMCS are installed on different host systems. Typically, all hosts are behind a firewall, with the Docroot Manager and web servers outside the firewall.

For examples of other common configurations, see the VCMS Installation and Configuration Guide (printed copy shipped with product).

The VCMS also allows you to run hosts outside of your firewall. See Appendix E, 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 graphic, audio, and HTML files that don’t change or don’t need templates. The web server configured with a CDS delivers these static files in the conventional way.



Figure 1-1: VCMS components

Host 3 Host 4 Host 5

Development CDScds-a

Host 6

OMS

Host 1

Web Serverfor

Development CDScds-a

Host 2

Web Serverfor

Live CDScds-b

. . . Multiple Web Servers for cds-b on Multiple Hosts

Docroot Manager

Host 7

cmd pad

Application Engineape-1

tmd-1

jsp-1

ctld-1

Live CDScds-b

Live CDScds-b

Docroot Manager

cmd pad

Application Engineape-1

tmd-1

jsp-1

ctld-1

vrd-1 omd-1

cld-1vwd-host6

vwd-host7

CMS

bob ted

vhs

MCS

mcd-1

plug-in

asp-1

asp-1


Administration Guide VCMS Software Basic Concepts

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 VCMS or tools software is installed.

For example:

• WINDOWS C:\Vignette• SOLARIS /opt

inst-name The name of the VCMS installation, entered at initial installation. Each installation has:

• One CMS• One or more CDSs and web server modules• One OMS (optional)• One VMCS (optional)

cds-name The name of a CDS, entered when the CDS is configured.

oms-name The name of an OMS, entered when the OMS is configured.

mcs-name The name of a VMCS, entered when the VMCS is configured

ws-name The name of a web server module, entered when the web server module is configured.

See also: Chapter 2, Roadmaps for Getting Started


2 Roadmaps for Getting Started

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

Audience: Administrators and other users of the Vignette® Content Management Server V6 (VCMS) software

Before you begin: See Chapter 1, VCMS Software Basic Concepts

Topics include: • Roadmaps


Roadmaps for Getting Started Administration Guide

RoadmapsThe two roadmaps below will help you to get underway with the VCMS Admin Center.

The first roadmap provides descriptions for the various tasks, and directs you to background and how-to information.

The admin user controls VCMS users and groups through the User Manager. (See Chapter 5, Managing VCMS Users, Groups, and Roles.) Additional features of the Configuration View and some command-line interfaces let the admin user manage VCMS servers and processes. (See Chapter 4, Viewing VCMS Servers and Processes.)

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

What to do Description See

1 Familiarize yourself with the Admin Center Tools.

Take some time to learn the Admin Center interface.

Chapter 3, Understanding the Admin Center Tools

2 Change the 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-11

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

Chapter 5, Managing VCMS Users, Groups, and Roles

4 Determine whether self- registration should be allowed.

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

Enabling Self-registration on page 5-12

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


Administration Guide Roadmaps for Getting Started

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

6 Set VCMS-wide variables and procedures.

You can define VCMS-wide variables and procedures to identify information used by all the Tcl Page Generator processes in a single set of installed VCMS files. After you define the procedures, they are available to all Tcl templates managed by the CDSs configured on that host.

Initialization Files for the Tcl Interpreter on page 6-5


View configuration information for the CMS, CDS, OMS, VMCS, and their processes.

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

Chapter 4, Viewing VCMS Servers and Processes

If you are running the CMS or CDS on the same Windows host as the database, adjust the sequence in which the services start.

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

VCMS Installation and Configuration Guide (printed copy shipped with product)

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

Running reports on visitor data can consume system processing resources. Limit the number of users who can create, run, and edit reports.

Roles Authorization on page 5-5

Manage VCMS files. When you install and configure the software and tool sets, the VCMS software creates directories and files used by the various processes.

Chapter 6, Managing VCMS Files and Appendix B, VCMS File Reference

Fine tune your web server. Each CDS provides pages through a web server. Modifications you can make include: setting up web server parsing, clearing pages from the root path, and (for Windows) using .asp scripts in templates.

Chapter 10, Working with Web Servers



Roadmaps for Getting Started Administration Guide

Manage VCMS processes. The CMS, CDS, OMS, and VMCS run several processes (also called “services” on Windows) that you can manage either through the Configuration View or a command-line interface.

Chapter 8, Managing VCMS Processes and Appendix A, VCMS Process Reference

Understand the VCMS database.

The VCMS database contains templates, the content records for the web pages generated by the CDS(s), and production management information for tracking both templates and content in the Production Center.

Chapter 7, Managing System and Content Databases

Delete or restore project packages created with the transferproject utility.

You can add sets of templates and content that make up project packages. To save space, you can remove project packages, including their static files.

Loading or Removing a Project Package on page 9-3

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

Chapter 11, Tuning Your VCMS Installation

Transfer projects from one CMS to another.

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

Chapter 12, Transferring Projects and Tables between CMSs

Configure VCMS hosts outside the firewall.

You may want to configure a live CDS 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 VCMS tool session outside the firewall, for example, to allow remote project tracking.

Appendix E, Remote Operations

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

Appendix F, Configuring Virtual Hosting

See also: Chapter 3, Understanding the Admin Center Tools



3 Understanding the Admin Center Tools

Summary: Overview of the Vignette® Content Management Server V6 (VCMS) Admin Tools.


Before you begin: • See Chapter 1, VCMS Software Basic Concepts• See Chapter 2, Roadmaps for Getting Started

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


Understanding the Admin Center Tools Administration Guide

Starting the VCMS Admin Center ToolsYou must have the basic VCMS tools software installed to use the Admin Center tools.

The Admin Center consists of two tools:

• Configuration View

• User Manager

You start the Configuration View and the User Manager from the VCMS Tools launch bar window, an example of which is shown in Figure 3-1. (For information on starting the VCMS Tools, see Running the Vignette Content Management Tools.)

NOTE: To use some of the Admin Center functions, you must log in as an admin user or a user with the System role when you start the VCMS Tools.

Figure 3-1: Vignette VCMS Tools 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 Manager primary window.


Administration Guide Understanding the Admin Center Tools

Figure 3-2: Configuration View primary window



Figure 3-3: User Manager primary window



Using the Tools

All users of the Admin Center tools can view information about the VCMS, including the Content Management Server (CMS), Content Delivery Servers (CDSs), the Observation Management Server (OMS), the Vignette Multi-Channel Communication Server (VMCS), and VCMS users, groups, and roles. System role users can use options that change the servers, but these options are unavailable for other users.

NOTE: A non-System role user may be able to change his or her own user password, description, or e-mail address. See Editing a User Entry on page 5-11.

Sorting Entries

In the primary window pages (Configuration View or the Users, Groups, or Roles page of the User 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 the column head 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 Tools session is connected appears on the first line. If the CMS’s associated processes are not already shown, you can expand the entry to show the CMS’s constituent processes and any CDSs already installed and connected to the CMS. You can further expand CDSs to show their processes.

Similarly, you can view the processes for the OMS, VMCS, and associated web servers.

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

See also: • Chapter 4, Viewing VCMS Servers and Processes• Chapter 5, Managing VCMS Users, Groups, and Roles



The entries are prefaced by an expandable icon (see Figure 3-2). You can click the icon to show information about the processes running on each CMS, CDS, OMS, and VMCS.

CMS processes:

• Dispatch Service• Timed Event Service• Request Service

CDS subcomponents and processes:

• Docroot Manager– Cache Manager– Placement Agent

• Application Engine(s)– Template Manager– Page Generator

• any web servers associated with the CDS

OMS processes:

• Campaign Logging Agent• Dispatcher(s)• Observation Manager(s)• Watchdog• associated CDSs

MCS processes:

• Multi-Channel Delivery Agent• Watchdog• Delivery Channel Plug-in(s)



Getting HelpYou can access the VCMS 6.0 on-line manuals from the VCMS Tools’ Help menu or from your web browser.

In order to view the installed on-line manuals, you must:

• Have a CMS and at least one development CDS configured• Specify a default browser• Have the development CDS selected in the Preferences window

For more information on setting preferences and accessing on-line information, see the section on getting help in Running the Vignette Content Management Tools.

Closing the Admin Center ToolsYou 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 VCMS tools open in the current session) by using the 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 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 them.


4 Viewing VCMS Servers and Processes

Summary: How to use the Configuration View to view more information about CMS, CDS, OMS, and VMCS servers, and associated software processes.


Before you begin: See Chapter 3, Understanding the Admin Center Tools

Topics include: • Viewing Servers and Processes• Viewing CMS Information• Viewing CMS Process Information• Viewing CDS Information• Viewing CDS Process Information• Viewing OMS Information• Viewing OMS Process Information• Viewing VMCS Information• Viewing VMCS Process Information

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

Note: The same information available through the Configuration View appears in the Platform Manager. See Accessing the Platform Manager—Windows Only on page 9-2.


Viewing VCMS Servers and Processes Administration Guide

Viewing Servers and Processes A Configuration View session provides information about one Content Management Server (CMS) and its Content Delivery Servers (CDSs), other optional servers (OMS and VMCS), the processes for these servers, and also about the web server modules. The status field in the VCMS Tools launch bar shows the CMS that you are accessing.

NOTE: When the Configuration View displays variable values, it is reading those values from the database, and is not reading the values from the specific process or the associated configuration file. If you have changed configuration settings in the configuration files, those changes will not appear in the Configuration View until you commit your changes to the database.

To switch the Platform Tools session to a CMS other than the one you are currently viewing, see the section on connecting to a different CMS in Running the Vignette Content Management Tools.

To view more or less information, expand or collapse the Configuration View entries. See Expanding Server Entries in Configuration View on page 3-5.

Viewing CMS Information

CMS Information in the Details Window

■ 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 menu. The CMS Details window opens with the following fields:

Installation: Shows the host and path name where the CMS is installed.

For example:

WINDOWS isis.example.com:d:\Vignette\

SOLARIS isis.example.com:/opt/vignette/6.0/


Administration Guide Viewing VCMS Servers and Processes

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

Viewing CMS Process Information

CMS Process Information in the Primary Window

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

Name: Shows the name of this component, which is Content Management Server (CMS).

SMTP Server: Shows the current host name (the fully qualified domain name: for example, pan.vignette.com) and port number (usually 25) for the SMTP (Simple Mail Transfer Protocol) server to use for VCMS e-mail notifications. Admin users can change the values in this field.

See also Setting E-mail Preferences on page 5-12.

E-mail Notifications: Shows whether e-mail notifications are enabled (On) or disabled (Off). The enabled setting allows the VCMS software to send e-mail notifications of tasks set in the Production Center tools. Admin users can change this setting.

See also Setting E-mail Preferences on page 5-12.

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

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

Name Shows the name of the CMS process (Dispatch Service, Timed Event Service, Request Service)

Host Shows the host and domain that the process is executing on.

For example: isis.example.com

Port Shows the port number that the process uses on the host that it is executing on.

For example: 30200



CMS Process Information in the Details Window

The Configuration View primary window shows three processes for the CMS:

To view CMS process information: in the Configuration View primary window, right-click a CMS process entry and select Details from the pop-up menu.

Dispatch Service (bob) Dispatches all CMS transactions.

Timed Event Service (ted) Tracks timed events for the Dispatch Service.

Request Service (vhs) Manages requests for the Dispatch Service.

Installation: Shows the path to the CMS that this process belongs to.

For example: isis.example.com/C:/Vignette

Name Shows the type of process. Valid types include Dispatch Service, Timed Event Service, and Request Service.

Configuration Identifier:

Shows the configuration identifier for each CMS process.

For example:

/cms/bob for Dispatch Service/cms/ted for Timed Event Service/cms/vhs for Request Service

Version: Shows which version of the process is present.

For example: 6.0

Host: Shows the host name and domain that this process executes on.


Port: Shows the port number that this process uses (on the host).

For example: 30200

(For the Timed Event Service process, the port is always unknown.)

Working Directory:

For the Timed Event Service process only

Shows the path to the Timed Event Service’s working directory.

For example:

C:/Vignette/inst-kallisto0826 /working/cms/tedtasksworkingdir/



Viewing CDS Information

CDS Information in the Primary Window

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

CDS Information in the Details Window

■ To view CDS information in the Configuration View primary window:

1 In the Configuration View primary window, select a CDS entry.

Proto-Docroot:

For the Request Service process only

Shows where the static files are stored.

For example:

C:/Vignette/inst-kallisto0826/working/cms/staticfiles/

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

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

Name Shows the name of the CDS in cds-hostname format.

For example: cds-dev_osiris

Type Shows the designation of the CDS, either Development (inaccessible from the web) or Live (accessible from the web).



2 With the cursor on the selected entry, click the right mouse button, and select Details from the pop-up menu. The CDS Details window opens with the following fields:

Installation: Shows the host and path name where the CMS for the CDS is installed.

For example:

WINDOWS isis.example.com/C:/Vignette/

SOLARIS isis.example.com:/opt/vignette/6.0/

Name: Shows the name of the CDS in cds-hostname format.



Shows the configuration identifier for this CDS.

For example: /cds-dev_osiris

Docroot Path: Shows the location of the directory mapped to the web server’s front door.

For example:

WINDOWS c:\kallisto

SOLARIS /install/isis/docroot/ourdocs

Type: Shows the designation of the CDS, either Development (inaccessible from the web) or Live (accessible from the web).

Observation Management Server:

Shows the Observation Management Server (OMS) that is associated with this CDS.

For example: /oms-osiris

Database Name: Shows the name of the database accessed by the VCMS CDS.

For example: vignsysdb

Database Server: Shows the name of the server for the database.

For example: isis

Database Type: Shows the type of database being accessed. Valid types include:

WINDOWS DB2, MSSqlServer, Oracle, Sybase

SOLARIS DB2, Oracle, Sybase

AIX DB2

Database User: Shows the user login for accessing this database.

For example: kallisto2



Viewing CDS Process Information

A CDS has several processes associated with it: Cache Manager, Page Generator, Template Manager, Placement Manager, and Web Server.

The Configuration View primary window shows the following subcomponents and processes for each CDS connected to the CMS:

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

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

Docroot Manager (dm) Contains the cmd (Cache Manager) and pad (Placement Agent) for a CDS instance.

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

Placement Agent (pad) Manages the deployment of static content (content that does not reside in the database) to the CDS docroots. See also pad on page A-34.

Application Engine (ape) Contains the tmd (Template Manager) and page generator processes. There can be one or more Application Engines associated with a CDS.

Template Manager (tmd) Manages templates and updates the page generator concerning new or modified templates. See also tmd on page A-40.

Page Generator (ctld) Interprets templates, accesses content, and generates web pages on demand. There can be one of each type of page generator (Tcl, ASP, or JSP) within a Application Engine. See also ctld on page A-21.

Web Server (ws) Delivers the VCMS-generated pages to the web site visitors. This is a web server associated with this CDS. There can be one or more web servers associated with a CDS.



CDS Process Information in the Primary Window

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

In the Configuration View primary window, any OMS instance listed under the CDS is actually an alias for an OMS listed below and at the same hierarchical level as the CDS.

CDS Process Information in the Details Window

To view CDS process information in the Configuration View primary window, right-click a CDS process entry and select Details from the menu.

Cache Manager Details

Name: Shows the name of the process: Cache Manager, Page Generator, Template Manager, Placement Manager, Web Server (for example, ws-isisnet451).

Host: Shows the host and domain on which the process runs.


Port: Shows the port number that the process uses.

For example: 3740

Installation: Shows the pathname to the CMS with which this CDS is associated.

For example: isis.example.com:C:/Vignette/

Content Delivery Server (CDS):

Specifies the CDS of which this process is a part.


Process: Shows the name of this process, which is Cache Manager.


Shows the configuration identifier for this CDS process.

For example: /cds-dev_osiris/dm/cmd


For example: 6.0

Host: Shows the host name and domain of the web server with which this process is associated. For example: isis.example.com



Placement Agent Details

Port: Shows the port number over which this process communicates.

For example: 3741


For example:

WINDOWS C:\kallisto


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






Process: Shows the name of this process, which is Placement Agent.



For example: /cds-dev_osiris/dm/pad


For example: 6.0

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



For example: 3739

Docroot Path: Shows the location of the directory mapped to the web server’s front door. For example:

WINDOWS c:\kallisto

SOLARIS /install/nemo/docroot/ourdocs




Application Engine Details

Template Manager Details

Name: Shows the name of this component, which is Application Engine.

COM Extensions Enabled:

If true, template developers can access Windows COM objects from their Tcl templates. See the Tcl: COM Extension Programmer’s Guide and Reference for more information.

Java Extensions Enabled:

If true, template developers can include Java within their Tcl templates. See the Tcl: Java Extension Programmer’s Guide and Reference for more information.






Process: Shows the name of this process, which is Template Manager.



For example: /cds-dev_osiris/ape/tmd/tmd-1


For example: 6.0




For example: 3740




Tcl Page Generator Details






Process: Shows the name of this process, which is TCL Page Generator.



For example: /cds-dev_osiris/ape/pg/ctld/ctld-1


For example: 6.0




For example: 3738

Writes Cached Pages:

Shows true if this process is configured to write cached pages to the web server docroot; false otherwise. Use the PG_WRITES_CACHED_PAGES configuration variable to control this functionality. The variable is set to false by default. See the Configuration Reference for more information.




JSP Page Generator Details

Installation: Shows the pathname of the VCMS installation.

For example: C:/Vignette/




Process: Shows the name of this process, which is JSP Page Generator.



For example: /cds-dev_osiris/ape/pg/jsp/jsp-1


For example: 6.0

Host: Shows the host name where the JSP Page Generator process runs.


Port: Shows the web server port number over which this process communicates.

For example: 7001

Writes Cached Pages:

false—A JSP Page Generator never writes cached pages to the web server docroot; the web server associated with the JSP Page Generator does.

Template Cache: The path to the docroot of the JSP web application.

For example: c:\weblogic\myserver\vignwebapps\dev

NOTE: Because the web application docroot serves as a template cache for JSP Page Generators, each JSP Page Generator must have its own unique docroot.

Notification Port: The port used by the VCMS software to notify the Servlet Engine of JSP template changes. For example: 4680

Context Prefix: The Servlet Engine path prefix; that is, the root Uniform Resource Identifier (URI) of requests. For example, samples is the context prefix in the following URI:

http://isis.example.com:7001/samples/HelloWorld.jsp




Web Server Details

Name: Shows the name of this web server.

For example: ws-isisnet709

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


Port: Shows the port number over which the process communicates.

For example: 8080


For example:

WINDOWS c:\isis\home


Type: Shows what type of web server this is: iPlanet, Apache, Microsoft Internet Information Server (IIS), or IBM HTTP Server (IHS):

• NSAPI for iPlanet• APACHE for Apache • ISAPI for IIS• IBMHTTP for IHS

Instance: Shows the name of the instance of the web server.

For example: https-isis

Plugin Install Path:

Shows where the web server plug-in is installed.

For example: C:/Vignette/



Viewing OMS Information

OMS Information in the Details Window

To view OMS information, right-click the OMS entry in the Configuration View primary window, and select Details from the pop-up menu. The OMS Details window opens with the following fields:

Name: Shows the name of this component, which is Observation Management Server (OMS).



For example: /oms-osiris

Host: Shows the host name and domain on which this OMS runs.


Port: Shows the port number that the OMS uses.

For example: 3746

Associated CDS(s):

Shows a list of the CDSs with which this process is associated. An OMS can have more than one associated CDS.



Viewing OMS Process Information

An OMS has several processes associated with it: Campaign Logging Agent, Router, Observation Manager, and Watchdog.

The Configuration View primary window shows the following processes for each OMS associated with the CMS:

OMS Process Information in the Primary Window

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

In the Configuration View primary window, any OMS instance listed under the CDS is actually an alias for an OMS listed below and at the same hierarchical level as the CDS.

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

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

Campaign Logging Agent (cld) Logs visitor, visitor context, and profile mark information that is used as feedback data for campaigns.

Observation Manager (omd) Manages visitor records and visitor context objects.

Router (vrd) Routes external messages to the other OMS processes.

Watchdog (vwd) Monitors the other OMS processes.

Name: Shows the name of the process: Campaign Logging Agent, Router, Observation Manager, Watchdog (for example, vwd-isis.example.com).

Host: Shows the host and domain on which the process runs.



For example: 3740



OMS Process Information in the Details Window

To view information about specific OMS processes, right-click the OMS process instance in the Configuration View primary window, and select Details from the pop-up menu.

Campaign Logging Agent Details

Name: Shows the name of this process, which is Campaign Logging Agent.


Shows the configuration identifier for this process.

For example: /oms-dev_osiris/cld

Version: Shows which version of this process is present.

For example: 6.0

Host: Shows the host name and domain on which this process runs.



For example: 3741




Router Details

Observation Manager Details

Name: Shows the name of this process, which is Router.



For example: /oms-dev_osiris/vrd/vrd-1


For example: 6.0

Host: Shows the host name and domain on which this process runs. For example: isis.example.com


For example: 3741


Name: Shows the name of this process, which is Observation Manager.



For example: /oms-dev_osiris/omd/omd-1


For example: 6.0



For example: 3741




Watchdog Details

Viewing VMCS Information

MCS Information in the Details Window

To view VMCS information in the Configuration View primary window, right-click the VMCS entry and select Details from the pop-up menu. The VMCS Details window opens with the following fields:

Name: Shows the name of this process, which is Watchdog.



For example: /oms-dev_osiris/vwd/vwd-isis.example.com


For example: 6.0



For example: 3741

Name: Shows the name of this component, which is Multi-Channel Server (VMCS).


Shows the configuration identifier for the VMCS.

For example: /mcs-1

Host: Shows the host name and domain on which the VMCS runs.


Port: Shows the port number that the VMCS uses.

For example: 3746



Viewing VMCS Process Information

A VMCS has several processes associated with it: Multi-Channel Delivery Agent, Delivery Channel Plug-in, and Watchdog.

The Configuration View primary window shows the following processes for each VMCS associated with the CMS:

MCS Process Information in the Primary Window

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

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

Topics include: • MCS Process Information in the Primary Window• VMCS Process Information in the Details Window

Multi-Channel Delivery Agent (mcd)

Delivers delivery documents generated by style templates to the Delivery Channel Plug-ins.

Delivery Channel Plug-in (dcp) Delivers delivery documents via multiple delivery channels.

Watchdog (vwd) Monitors the other VMCS processes.

Name: Shows the name of the process: Multi-Channel Delivery Agent, Delivery Channel Plug-in, Watchdog (for example, vwd-isis.example.com).

Host: Shows the host and domain on which this process runs.



For example: 3740



VMCS Process Information in the Details Window

To view VMCS process information: in the Configuration View primary window, right-click a VMCS process entry and select Details from the pop-up menu.

Multi-Channel Delivery Agent

Watchdog Details

Name: Shows the name of this process, which is Multi-Channel Delivery Agent.



For example: /mcs-1/mcd/mcd-1


For example: 6.0



For example: 3741


Name: Shows the name of this process, which is Watchdog.



For example: /mcs-1/vwd/vwd-isis.example.com


For example: 6.0



Delivery Channel Plug-in Details

Name: Shows the name of this process, which depends on the plugin that is installed.

For example: Email (SMTP)



For example: /mcs-1/plugins/plugin-1



For example: 25


5 Managing VCMS Users, Groups, and Roles

NOTE: The following discussion assumes that your installation of the VCMS software uses the VCMS system database as a repository for user information. If you are using LDAP to store and maintain users, the VCMS disables much of the functionality of the User Manager. See Appendix D, Configuring the VCMS Software to Use an LDAP User Repository.

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



Topics include: • Overview• Managing Users for a New Installation• Roles Authorization• Monitoring Users, Groups, and Roles• Managing Users• Managing Groups• Managing Roles


Managing VCMS Users, Groups, and Roles Administration Guide

OverviewEach Content Management Server (VCMS) component maintains a list of users who can operate within the VCMS. This list is also organized into groups and into roles. A group is a collection of users, maintained strictly for organizational purposes such as sending e-mail to the whole group rather than to each user individually. By contrast, a role is one of several predefined authorization schemes which you will assign to a user in order to authorize the user to perform certain operations.

You can view and change information about users, groups, and roles through the Admin Center’s User Manager.

NOTE: You can also create, manage, and delete users and groups by using CMS commands in your templates. These provide a browser-accessible alternative to the Admin Center’s User Manager. For more information, refer to the VCMS documentation for your template environment (Tcl, COM, or Java).

Project owners can assign users and groups to projects and tasks using the VCMS Tools. Only users or groups authorized by the project owner and authenticated by the VCMS database can operate on a given project or task.

By contrast, roles are not project-specific. They determine what users can do regardless of projects. The VCMS software uses a combination of roles and project-based authorization to determine who can perform which actions on which content. For example, a user with the Developer role has authorization to edit templates, but this user must also be an authorized user for a particular project in order to edit templates in that project.

The VCMS software provides predefined roles. See Roles Authorization on page 5-5.


Administration Guide Managing VCMS Users, Groups, and Roles

The User Manager primary window contains information for these aspects of VCMS, each contained in a page with a tab at the top:

The lists in the User Manager’s primary window update dynamically so that they remain current.

To view the details for a user, group, or role, right-click the item and choose Details from the pop-up menu.

Users Shows information about the currently valid users recognized by the VCMS database. From this tab:

• A System role user can add, edit, copy, and delete users. • A System role user can add or remove users to and from groups or roles.• Any user can edit his or her own user entry.• Any user can view a list of all current users and details for each user.

Groups Shows information about the currently valid groups recognized by the VCMS database. From this tab:

• A System role user can add, edit, copy, and delete groups.• A System role user can add or remove users to and from groups.• Any user can view a list of all current groups and details for each group.

Roles Shows information about the currently valid roles recognized by the VCMS database. From this tab:

• A System role user can add, edit, copy, and delete roles.• A System role user can add or remove users to and from roles.• Any user can view a list of all current roles and details for each role.



Managing Users for a New InstallationAt installation, the VCMS software creates these reserved entries: the admin and guest user ID. The System user role is assigned by default to the admin user ID.

The admin user and other users with the System role are fully authorized to operate throughout the VCMS installation. In general, non-System role users can only use the Admin Center tools in read-only mode. However, a valid user may be able to change the password, description, or e-mail address for his or her own user entry, depending on the configuration settings for the system. (See the user chapter of the Security Guide.)

After the VCMS installation, a System role user will create new user entries in the VCMS database for the users who will work within the VCMS installation. The System role user will also create groups of users where necessary. For example, Editors or Managers. (Typically, it is not necessary to create new roles. See Roles Authorization on page 5-5.)

The first user entries should be new owners of the Base Project in the Production Center. The admin user owns the Base Project by default, but a new group should be created for the real owners. Include at least one System role user in the group.

If self-registration is enabled, a user can create her own user ID when logging in to the VCMS for the first time. The VCMS software will prompt the user for a description and password information. (See the discussion of self-registration in the Security Guide.) Even if self-registration is enabled, only a System role user can add or remove user IDs from groups or roles.

TIP: We recommend that you also create a project (for example, “sandbox”) with one or more System role users specified as the project owners 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 System role users can launch anything to the web.

See also: Monitoring Users, Groups, and Roles on page 5-6



Roles AuthorizationThe VCMS software uses roles to determine who can perform certain actions in a VCMS installation. Roles limit certain actions to certain users, and have nothing to do with determining which content those users can manipulate. For example, a user with the Developer role is authorized to create and edit templates, but he or she must also be an authorized user in the project where those templates reside.

NOTE: You cannot remove the System role association from the predefined admin user and you cannot delete the admin user. This restriction guarantees that your VCMS installation has at least one System role user.

The VCMS software provides predefined roles, each of which is described in the following section.

For a full discussion of project-level authorization, see the Production Center Guide.

The VCMS Roles

Roles are authorization schemes that limit who can perform certain privileged functions in the VCMS installation. The VCMS software provides predefined roles. You may want to establish additional roles to designate authorization for your own custom functionality, but the VCMS software only recognizes and uses the following roles:

Role Enables the user to

System Perform all actions in the VCMS installation.

Besides authorizing a user to perform operations that are not allowed by the other roles, the System role encompasses the authorization of all other roles. For example, you do not need the Developer role to create and edit templates if you already have the System role.

Developer Create and edit templates.

Authorized project users and owners must also be assigned the Developer role to create and edit templates within specific projects. See the Production Center Guide.



By default a new user has no roles. Users without roles can only perform actions based on their project-level authorization. If a user is a project owner or an authorized user for a project, he or she can perform any actions specific to those authorizations, but no actions specific to a particular role.

Monitoring Users, Groups, and Roles

All users can view currently valid users, groups, and roles through the User Manager.

To view the current lists of users, groups, or roles, click on the Users, Groups, or Roles tab in the User Manager primary window.

Business Center Full Use the Keyword Manager tool to create and delete content categories and keywords used for tracking the preferences of visitors to your website. Authorized users can assign new keywords to projects, templates, and records.

Note that a user must be a project owner and have the Business Center Full role to perform the above tasks.

With the Report Manager tool, a user with the Business Center Full role can also create, edit, and delete reports both in their personal folders and in shared folders.

See the Business Center Guide.

Business Center Partial Create, edit, and delete reports in their personal folders in the Report Manager tool of the Business Center.

See the Business Center Guide.

Topics include: • Viewing User Attributes• Viewing Group Attributes• Viewing Role Attributes

Role Enables the user to



Viewing User Attributes

The columns of the User Manager show the following read-only information about current users:

Viewing Group Attributes

The columns of the User Manager show the following read-only information about current groups:

User The user’s VCMS login name (ID). The VCMS establishes and maintains this ID within the database. By default, the VCMS software establishes two reserved user IDs at installation time: admin and guest.

Description (Optional) The user’s full name, or more descriptive information about the user.

E-mail Address (Optional) The user’s e-mail address.

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 The VCMS software establishes and maintains the group name within the database.

Description (Optional) Descriptive information about the group.



Viewing Role Attributes

The columns of the User Manager show the following read-only information about current roles:

Managing Users

System role users manage the users of a VCMS installation. They add, edit, and delete users, as well as adding and deleting them from groups and roles. System role users also determine whether a user can register himself or herself in the VCMS installation and whether to use e-mail to notify users of tasks.

Role Name The VCMS software establishes and maintains the role name within the database. These roles are established by default when you install the VCMS software:

• Business Center Full• Business Center Partial• Developer• System• (Any custom roles added to your installation)

Description Descriptive information about the role.

Topics include: • Rules for User Entries• Adding, Cloning, Editing, or Deleting Users• Additional Information• Enabling Self-registration• Setting E-mail Preferences



Rules for User Entries

The following rules govern new VCMS user names (user IDs):

• Must be unique within the VCMS installation. Also, the name of a user cannot be the same as the name of a group or a role.

• Can include characters, numbers, hyphens (ASCII character code 45), and underscores (ASCII character code 95)

• Can include upper- and lowercase characters

• Are case-sensitive

• Cannot have spaces (ASCII character code 32) or apostrophes (ASCII character code 39)

• Cannot have more than 16 characters

TIP: We recommend the convention of using lowercase for user names and initial capitals for group names: for example, diane and Editors.

Adding, Cloning, Editing, or Deleting Users

From the User tab of the User Manager primary window, System role users can do the following:

• Add users by selecting the New User icon in the toolbar.

• Clone, edit, and delete users by right-clicking a user and choosing: Clone, Delete, or Details.

When adding, cloning, or editing a user, the appropriate dialog opens, containing the following fields:

User The user name. Also referred to as the user ID. To add a user, follow the guidelines described in Rules for User Entries on page 5-9.

Description A full name or more detail about the user.

E-mail Address (Optional) The e-mail address that is used by the CMS for project notifications.

Password Expires (Optional) On the date specified, the password will become invalid. If you do not check the box, the password can still expire if the global password expiration variable is set. See the PW_MAX_LIFETIME variable in the Configuration Reference.



Continue to the Groups or Roles tab to add or edit the groups or roles for the user.

Additional Information

The following miscellaneous information may be helpful when adding, editing, cloning, or deleting a user entry.

Adding a User Entry

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. The same tip applies to assigning users to roles.

Cloning a User Entry

A System role user can clone an existing user entry to create a new entry. The new entry inherits group and role membership as well as password and account restrictions. The User, Description, and E-mail Address fields are blank for you to enter the new user’s information. You will also need to enter new password information.

User can modify password

(Optional) This option inherits its default setting from the PW_CHANGE_PASSWORD_DEFAULT configuration variable. See the Configuration Reference.

Password valid only once

(Optional) If checked, the user will be prompted to enter his or her own password after the first login. This option is disabled if the User can modify password option is not checked.

Account enabled (Optional) Uncheck this box if you want to disable the user. All user settings will be maintained so that you can re-enable the user as necessary.

New password For security, only asterisks display instead of the characters you enter. A box below the text fields displays the restrictions currently in place for passwords. If your new password does not meet the restrictions, the VCMS software will prompt for a different one. For information about the restrictions, see the PW_* variables in the Configuration Reference.

Confirm password Again, only asterisks display in the window.



Editing a User Entry

System role users can edit any field in the Details for User window pages except the User field; you cannot change the userID. (To change the userID, you must delete the user and re-enter the information.)

If authorized, a non-System role user can change the Description, E-mail Address, New Password, and Confirm Password fields for his or her own entry, but not the:

• User field• Password and account restrictions• Groups and Roles memberships

TIP: When you start the User Manager for the first time, edit the admin user entry to change the default password (admin). Limit the number of users who know the password. To grant other users admin authentication, add them to the System role. Delete them from the role when they no longer need full authentication. Optionally, you can also change the password for the guest user entry. By default, the guest login password is guest.

NOTE: Use caution when editing user entries. If you modify the entry for a user who is currently working in a VCMS 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 available only to that group, the user may not be able to continue.

Deleting a User Entry

System role users can delete user entries from the VCMS database. When you delete a user entry, it is also deleted from any groups and roles of which it was a member.

Deleting a user entry in the User Manager does not automatically remove the user 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: Use caution when editing user entries. If you delete the user entry for a user who is currently working in a VCMS tool connected to this database, you will 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.



Enabling Self-registration

A System role user can set the self-registration feature to allow a user to log in to the VCMS without requiring a user name that is already known to the database. The user enters a user ID and password in the VCMS 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. The VCMS software then adds the user ID to the database.

Self-registration is disabled by default for new installations of the VCMS software. For upgrade installations, self-registration is enabled or disabled depending on its setting at the time of the upgrade.

When self-registration is enabled, it remains in effect for all interactions requiring logins to the CMS or its CDSs until the setting is disabled.

The new user has no group memberships or role associations; a System role user must edit the user’s entry in the User Manager to add the new user to groups or roles.

■ To enable self-registration:

Use the Platform Variable Editor to set the EUR_ENABLE_AUTO_REGISTRATION configuration variable to true.

See the Configuration Reference.

NOTE: For VCMS installations configured to use LDAP, EUR_ENABLE_AUTO_REGISTRATION must be set to false. See Appendix D, Configuring the VCMS Software to Use an LDAP User Repository.

Setting E-mail Preferences

Project owners assign tasks to users, and the users are notified by e-mail. A System role user can set e-mail preferences in the Configuration View that affect all users listed in the current CMS.

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



Setting the SMTP Server

You can set the name and port of the Simple Mail Transfer Protocol (SMTP) server to be used for VCMS e-mail notifications from the CMS. The initial default is localhost:25.

■ To set the SMTP server for a CMS:

NOTE: There is no native SMTP server in the Windows environment. You must specify the host and port of an SMTP server for the VCMS servers to use.

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 assignments according to the following criteria:

1 In the Configuration View primary window, right-click the Content Management Server entry, and select Details from the 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: pan.example.com:25.

The entry must be in the format: host:port

host Specifies the fully qualified domain name of the local site’s SMTP server. For example: pan.example.com

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

3 Click OK to submit the change to the database.

For The appropriate users are notified

One-time tasks Immediately after the task is created.

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

Recurring tasks (first in the schedule)

When the recurring task is created.



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-11). You cannot configure a user to receive e-mail for some tasks and not others.

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

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.

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 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 VCMS user entries) when a task satisfies one of the previously defined criteria.

• Off - Does not send e-mail notification for any task assigned in this CMS.

3 Click OK to submit the change to the database.

For The appropriate users are notified



Managing GroupsGroup entries allow project owners to assign tasks and project 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 for Group Entries

There are rules governing VCMS group names. Group names:

• Must be unique within the VCMS installation. Also, the name of a group cannot be the same as the name of a user or role.

• Can include characters, numbers, hyphens (ASCII character code 45), and underscores (ASCII character code 95)


• Cannot have spaces (ASCII character code 32) or apostrophes (ASCII character code 39)


We recommend the convention of using lowercase for user names and initial capitals for group names, for example, diane and Editors.

NOTE: A group cannot be a member of another group.

Adding, Cloning, Editing, or Deleting Groups

From the Groups tab of the User Manager primary window, System role users can:

• Add groups by selecting the New Group icon in the toolbar.

• Clone, delete, and edit groups by right-clicking a group and choosing: Clone, Delete, or Details.

Topics include: • Rules for Group Entries• Adding, Cloning, Editing, or Deleting Groups• Additional Information



When adding, cloning, or editing a group, the appropriate dialog opens, containing the following fields:

Continue to the User tab to edit the list of users for the group.


The following miscellaneous information may be helpful when adding, editing, cloning, or deleting a group entry.

Adding a Group Entry

System role users can add group entries to the VCMS installation. By default, the admin user is the owner of the Base Project in the Production Center. After adding user entries on the Users tab 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 users to the System role. Include a member of the System role 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.

Cloning a Group Entry

A System role user can clone an existing group entry to create a new entry. The new entry has only the members of the copied entry. The Group and Description fields are blank for you to enter the new group’s information.

Group The group name. To add a group, follow the guidelines described in Rules for Group Entries on page 5-15.

Description Details about the group.



Editing a Group Entry

System role users can change a group’s description in the Details for Group window, but they cannot alter the Group field. The group’s name cannot be changed. (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.

NOTE: If you modify a group entry for a user who is currently using a VCMS 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 available only to that group, the user may not be able to continue.

Deleting a Group Entry

System role users can delete group entries from the VCMS database. Removing a group entry does not remove its members from the database.

When 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: Use caution when deleting group entries. If you delete the group entry for a user who is currently working in a VCMS 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 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.



Managing RolesManaging roles is significantly simpler than managing users and groups. Because roles are built into the VCMS software, you simply decide which users to assign to which roles. You will not typically need to add, edit, clone, or delete roles. For an overview of roles, see Roles Authorization on page 5-5.

You may want to add roles to your VCMS installation if you need to verify authorization for custom procedures. For example, template developers can include the NEEDS ID command in templates in order to verify that the user has a custom role before granting the user access to a restricted application. The VCMS software maintains the custom role and user associates for the role, but the installation cannot be adjusted to require that users have the role in order to perform VCMS-specific operations.

You cannot delete the predefined VCMS roles. You can only delete custom roles that you created.

You cannot remove the System role from the admin user, and you cannot delete the admin user itself.

You can add users to the role through the Users tab.

Role The role name. If you’re adding a role, follow the guidelines described in Rules for Role Entries on page 5-19.

Description Detail about the role.

Topics include: • Rules for Role Entries• Adding, Cloning, Editing, or Deleting Roles• Additional Information



Rules for Role Entries

If you do want to add a custom role or clone a role, the role name must conform to several rules. Role names:

• Must be unique within the VCMS installation. Also, the name of a role cannot be the same as the name of a user or group.

• Can include characters, numbers, hyphens (ASCII character code 45), underscores (ASCII character code 95), and spaces (ASCII character code 32).


• Must begin with a character or number


NOTE: A role cannot be a member of another role.

Adding, Cloning, Editing, or Deleting Roles

From the Roles tab of the User Manager primary window, System role users can:

• Add roles by selecting the New Roles icon in the toolbar.

• Clone, edit, and delete roles by right-clicking a role and choosing: Clone, Delete, or Details.

When adding, cloning, or editing a role, the appropriate dialog opens, containing the following fields:

Continue to the User tab to edit the list of users for the role.


The following miscellaneous information may be helpful when adding, editing, cloning, or deleting a role entry.

Role If you’re adding a role, follow the guideline described in Rules for Role Entries on page 5-19.

Description Detail about the role.



Adding a Role Entry

Only System role users can add role entries to the VCMS installation.

You can add a role entry with or without associating users for the role. A role must exist before you can add users to it.

NOTE: 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 any users requiring administrator privileges be added to the System Role rather than share the admin userID.

Cloning a Role Entry

A System role user can clone an existing role 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 Role name and Description information.

Editing a Role Entry

Right-clicking on a role and selecting Details from the menu opens the Details for Role dialog.

System role users can edit any field in the Details for Role window except the Role field; you cannot change the role’s name. (To change the role’s name, you must delete the role and re-enter the information.) You can edit only one role entry at a time.

NOTE: Use caution when editing roles. If you modify a role entry for a user who is currently using a VCMS tool connected to this database, you can affect the user’s authorization for operations. For example, if you remove a user from a role and the user is attempting an operation authorized only for that role, the user may not be able to continue.



Deleting a Role Entry

You cannot delete the predefined VCMS roles.

Only System role users can delete role entries from the VCMS database. Removing a role entry does not remove its members from the database.

If you delete a role, the role name is not automatically removed from projects and content items in the Production Center. You must delete the role name from Production Center projects and content items manually.

NOTE: Use caution when editing roles. If you delete the role entry for a user who is currently working in a VCMS 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 to start a task where only the role authorizes the operation, the user may be unable to continue.


6 Managing VCMS Files

Summary: How to manage various directories and files that the Vignette® Content Management Server V6 (VCMS) software creates when you install and configure your servers.

Audience: Administrators of VCMS


Topics include: • Overview• Understanding Configuration Files• log Files and pid Files• Debugging Templates with the LOG Template Command• Other Files and Directories• Understanding Tool Directories• Understanding Preference Files


Managing VCMS Files Administration Guide

OverviewWhen you install the VCMS software and configure its components, the VCMS software creates directories and files used by the various processes.

Among the files created are:

• Configuration files for each of the VCMS components and log files for each of the VCMS component processes

• Executable files for program tasks• Executable files for the VCMS tools (for example, Project Manager)• Files that store user preferences

The directories created provide repositories for:

• Static web files• Template variations• On-line documentation

Depending on their function, the VCMS software creates files and directories on the host machine where the CMS, CDS,VMCS, or OMS resides.

In addition to the VCMS files in your file system, you will see items in your database related to the VCMS software such as database tables, indexes, and so forth. Contact your database administrator for more information on these items.

Understanding Configuration FilesThis section describes the organization of configuration information into component-specific configuration files and provides the paths to those files.

It also discusses two additional files that the Tcl Page Generator uses to initialize its Tcl interpreter.

See also: • Appendix B, VCMS File Reference• Appendix A, VCMS Process Reference

Topics include: • Overview of Configuration Files• Initialization Files for the Tcl Interpreter


Administration Guide Managing VCMS Files

Overview of Configuration Files

Each VCMS component maintains its own configuration information, both in the VCMS system database and in a component-specific configuration file. The VCMS components each consist of one or more processes. The configuration information for each process is contained in a component-level configuration file.

NOTE: The CDS includes two subcomponents: the Docroot Manager (dm) and the Application Engine (ape). The configuration file for the CDS includes the configuration information for these subcomponents and the processes within them.

The database is a repository of the configuration information stored in the configuration files. To edit configuration information, administrators can:

• Edit the configuration files and then commit their changes to the database by using admin cfgedit

• Directly edit the configuration information stored in the system database by using the Platform Variable Editor or admin cfgedit

NOTE: In most cases, the Platform Variable Editor is the best tool to use when editing configuration variables. See the Configuration Reference for more information about the available editors and the tasks for which they are best suited.

Where the database maintains configuration information for all components, the configuration file for an individual component contains only configuration variables and values relevant to that particular component and its processes.



The following table shows the VCMS components and their processes, and it shows the configuration file for each component.

VCMS componentConsists of the following subcomponents and processes Configuration file

Configuration Management Server (CMS)

• bob (Dispatch Service)• vhs (Request Service)• ted (Event Service)

cms.cfg

Content Delivery Server (CDS)

• dm (Docroot Manager)- pad (Placement Agent)- cmd (Cache Manager)

• ape (Application Engine)- tmd (Template Manager)- ctld (Tcl Page Generator)- ASP Page Generator- JSP Page Generator

cds.cfg

Observation Management Server (OMS)

• omd (Observation Manager)• cld (Campaign Logging Agent)• vrd (Router)• vwd (OMS Watchdog)

oms.cfg

Multi-Channel Communication Server (VMCS)

• mcd (Multi-Channel Delivery Agent)

• vwd (VMCS Watchdog)

mcs.cfg

Web Server module • Web server module ws.cfg

See also: • The Configuration Reference for background information about configuration and how to edit the configuration variables.

• Appendix B, VCMS File Referencefor detailed information about specific configuration files.



The following table shows the paths to the configuration files for each component.

For information on the variables that appear in these paths, see Common Path Name Variables on page 1-5.

Initialization Files for the Tcl Interpreter

The Tcl Page Generator uses a Tcl interpreter to handle requests for dynamic web pages. The Tcl interpreter processes Tcl commands in templates to build the pages for display.

By default, the Tcl Page Generator initializes a new Tcl interpreter every time that it receives a request for a page. However, the CTLD_INTERP_INTERVAL configuration variable allows you to configure the Tcl Page Generator (ctld) to reuse the same Tcl interpreter for multiple page requests. See the Configuration Reference for more information about the CTLD_INTERP_INTERVAL variable. See the Tcl: Template Cookbook for a discussion of Tcl interpreter reuse in 6.0.

Component Path to configuration files

Configuration Management Server (CMS)

WINDOWS install-path\inst-name\conf\cms\cms.cfg

SOLARIS install-path/vignette/inst-name/conf/cms/cms.cfg

Content Delivery Server (CDS)

WINDOWS install-path\inst-name\conf\cds-name\cds.cfg

SOLARIS install-path/vignette/inst-name/conf/cds-name/cds.cfg

Observation Management Server (OMS)

WINDOWS install-path\inst-name\conf\oms-name\oms.cfg

SOLARIS install-path/vignette/inst-name/conf/oms-name/oms.cfg

Multi-Channel Server (VMCS)

WINDOWS install-path\inst-name\conf\mcs-name\mcs.cfg

SOLARIS install-path/vignette/inst-name/conf/mcs-name/mcs.cfg

Web Server module WINDOWS install-path\inst-name\conf\ws-name\ws.cfg

SOLARIS install-path/vignette/inst-name/conf/ws-name/ws.cfg



The Tcl Page Generator calls two files (delivery.tcl and ctld.tcl) in order to initialize the Tcl interpreter with variables and procedures. If you want custom variables and procedures to be available to the Tcl interpreter, you edit these files to add them. Whether you add the information to delivery.tcl or ctld.tcl depends on whether you want the variable or procedure to be available to all Tcl Page Generators on a machine, or only to one Tcl Page Generator specifically:

• delivery.tcl contains variables and procedures that are available to all Tcl Page Generators on a single machine.

• ctld.tcl, on the other hand, contains variables and procedures that are available to each Tcl Page Generator individually. Each CDS has its own local version of ctld.tcl.

To initialize the Tcl interpreter, a Tcl Page Generator first reads its own local copy of ctld.tcl and initializes the Tcl interpreter with any custom variables or procedures listed there. The last line of the ctld.tcl file is a pointer to delivery.tcl, which the Tcl Page Generator then reads for any additional information.

By default, ctld.tcl is empty except for this pointer to delivery.tcl.

The following table provides the paths to the files.

Notice that delivery.tcl is created as a sibling to any cds-name directories. This allows it to be available to all CDSs on a machine.

Name

delivery.tcl

WINDOWS install-path\inst-name\conf\

SOLARIS

install-path/vignette/inst-name/conf/

ctld.tcl

WINDOWS install-path\inst-name\conf\cds-name\

SOLARIS

install-path/vignette/inst-name/conf/cds-name/



If you want all the Tcl Page Generators on multiple CDS machines to have the same information, you must copy your preferred version of delivery.tcl onto the other CDS host machines, overwriting the existing delivery.tcl file(s).

■ To set up Tcl variables and procedures:

1 From a command line, open the delivery.tcl or ctld.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.

4 The next time that the Tcl Page Generator is initialized, the ctld processes will generate the string Brontosaurus dog for a template that includes [SHOW myDino].

You can force the Tcl Page Generator to read delivery.tcl and ctld.tcl by stopping and starting the ctld process. See Using the admin Command to Stop and Start Processes on page 8-3.

See also: • ctld.tcl on page B-21• delivery.tcl on page B-22



log Files and pid FilesThe VCMS software records errors and warnings in the EventLog Viewer (on Windows) or in the messages file (on Solaris).

It records higher-level messages, such as audits and debug messages, in process-specific log files.

For Solaris platform installations, the VCMS software stores process ID (pid) files in the same directories as the log files.

This section describes the names and locations of these files and then discusses the logging in depth—how to set the level of logging, and how to view the logging information.

log and pid File Names and Locations

Every process has its own log file and, on Solaris, its own pid file. The files are named according to the process for which they hold data, and include a .log or .pid extension. For example, the log file for the Dispatch Service (bob) is named bob.log. For processes that may have more than one instance, the process name includes a unique identifier. For example, if you have a Template Manager named tmd-1, the corresponding log file is named tmd-1.log. Finally, if a CDS host machine includes Tcl, ASP, or JSP Page Generators, the VCMS software creates ctld-id.log, asp-id.log, and jsp-id.log, respectively.

Topics include: • log and pid File Names and Locations• Viewing VCMS Log Information



The following table shows the paths to the log and pid files.

The files in the table are given relative to the following directories:

WINDOWS install-path\inst-name\logs\

SOLARIS install-path/vignette/inst-name/logs/

Four processes generate multiple log files because they spawn slave processes, each of which generates its own log file. The processes that generate multiple log files are:

• Request Service (vhs)• Placement Agent (pad)• Tcl Page Generator (ctld)• Multi-Channel Delivery Agent (mcd)

For these processes, the directories shown in the previous table will include a file named process.log (or process-id.log), where process corresponds to the name of the master process, and one or more files named process.#.log, (or process-id.#.log)where # corresponds to the numbered slave process that generated the file. See Appendix B, VCMS File Reference, for more information.

Process name log filepath to log on WINDOWS

path to log or pid on SOLARIS

• Dispatch Service• Request Service • Event Service

• bob.log• vhs.#.log• ted.log

\cms\ /cms/

• Placement Agent • Template Manager• Cache Manager• Tcl Page Generator• ASP Page Generator• JSP Page Generator

• pad.#.log• tmd-id.log• cmd.log• ctld-id.#.log• asp-id.log• jsp-id.log

\cds-name\ /cds-name/

• Campaign Logging Agent• Observation Manager• Router• OMS Watchdog

• cld-id.log• omd-id.log• vrd-id.log• vwd.log

\oms-name\ /oms-name/

• Multi-Channel Delivery Agent

• VMCS Watchdog

• mcd-id.#.log• vwd.log

\mcs-name\ \mcs-name\



When log files reach their maximum capacity (which is determined by the MAX_LOG_SIZE variable), the current log file is renamed to process.log.bak and a new log file is created.

Viewing VCMS Log Information

Using the LOG_LEVEL variable, administrators can configure the level of log message they want to track.

The LOG_LEVEL configuration variable is set at the root level (/LOG_LEVEL in the configuration path) which means that it applies to all VCMS components and their processes. If you want to override the root-level setting for a particular component or process, you can add the LOG_LEVEL configuration variable to the configuration information for the component or process. See the Configuration Reference for more information.

You can set the logging level to 1, 2, 3, or 4. Where the VCMS software writes the logging messages depends on the logging level you specify. By default, the LOG_LEVEL variable is set to 2.

NOTE: For debugging a web server configuration, you can override the inherited LOG_LEVEL value by setting a LOG_LEVEL variable in the web server configuration file (ws.cfg). In this one case (only in a ws.cfg file), you can set the log level to 8 to get maximum logging information.

For log levels 1 and 2, the VCMS software logs messages into the following locations for each supported operating system:

WINDOWS The EventLog service lists events, errors, and messages.

SOLARIS The messages file, found in the /var/adm directory, logs errors and messages managed by the syslogd(1M) process on Solaris.

For log levels 3 and 4, the VCMS software logs messages into the log file for each process.

See also: Configuration Reference



The following table shows the VCMS log levels and message distribution.

Viewing the EventLog Event Viewer on Windows

■ To view the VCMS errors and messages (levels 1 or 2) on Windows:

1 Using your preferred method, open the Event Viewer.

2 From the Log menu, select Application.

3 From the Application Log list, double-click the VCMS 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.

Log Level Message Type

Written to

WINDOWS SOLARIS

1 error EventLog service messages

2 warning EventLog service messages

3 audit process log file process log file

4 debug process log file process log file

Topics include: • Viewing the EventLog Event Viewer on Windows• Viewing the messages file on Solaris



Viewing the messages file on Solaris

■ To view the VCMS errors and messages (levels 1 or 2) on Solaris:

1 Open the messages file by navigating to the following directory on a CMS or CDS host:

/var/adm/

2 Read the contents of the messages file with your preferred text viewer.

Debugging Templates with the LOG Template CommandIn addition to the log files, Tcl template developers can use the LOG template command in templates to create a log file for debugging.

The syntax is [LOG message]

As a template is evaluated, the Tcl interpreter reads any instances of the LOG command, and sends the accompanying message to the infolog files.

The path to the infolog files is the same as the path to the Tcl Page Generator log files:

WINDOWS install-path\inst-name\logs\cds-name\ctld-id.#.infolog

SOLARIS install-path/vignette/inst-name/logs/cds-name/ctld-id.#.infolog

As with the log files for the Tcl Page Generator, the LOG command generates multiple infolog files, one for the master Page Generator (ctld) process, and one for each slave processes.

See also: • Appendix B, VCMS File Reference• Appendix A, VCMS Process Reference• Setting Program Tasks in Production Center Guide• Understanding Tool Directories on page 6-16

See also: • Tcl: Template Command Reference• Tcl: Template Cookbook



Other Files and DirectoriesIn addition to the configuration files, log files, and pid files, the VCMS software creates a variety of executables, utilities, and directories for specific purposes. This section discusses these files and directories, and, where relevant, it provides pointers to additional information.

Other CMS Files and Directories

The CMS files and directories in the table are given relative to the following directories:

WINDOWS install-path\

for example:

D:\Program Files\Vignette\

SOLARIS install-path/vignette/

for example:

/opt/vignette/

Topics include: • Other CMS Files and Directories• Other CDS Files and Directories

File or Directory Name

File or Directory Location

Function

WINDOWS SOLARIS

admin.bat

inst-name\conf\cms\

admin

inst-name/conf/cms/

Stops or starts CMS

expire.exe

6.0\taskbin\winnt\

expire

6.0/taskbin/solaris/

Expires records, files, and templates

flushcache.bat

6.0\taskbin\winnt\

flushcache


Flushes cached pages

launch.exe

6.0\taskbin\winnt\

launch


Launches records, files, and templates



Other CDS Files and Directories

The files for a CDS shown below are given relative to the following install path:

WINDOWS install-path\

for example:

D:\Program Files\Vignette\

SOLARIS install-path/vignette/

for example:

/opt/vignette/

staticfiles

inst-name\working\cms\

staticfiles

inst-name/working/cms/

Directory for Request Service working copies of static files it has processed

tedtasksworkingdir

inst-name\working\cms\

tedtasksworkingdirs

inst-name/working/cms/

Working directory for Event Service program tasks

version.exe

6.0\taskbin\winnt\

version

6.0/taskbin/solaris

Versions records, files, and templates



Function

WINDOWS SOLARIS

admin.bat

inst-name\conf\cds-name\

admin

inst-name/conf/cds-name/

Stops or starts CDS



Function

WINDOWS SOLARIS



docroot

6.0\

docroot

6.0/

Contains on-line VCMS information (development CDS only) that your web browser can access

metafiles

inst-name\working\ cds-name\

metafiles

inst-name/working/ cds-name/

Contains Tcl template variations

metatemplates


metatemplates


Contains template meta-data

obj.conf.vgnbak

inst-name\working\ ws-name\

iPlanet servers only

obj.conf.vgnbak

inst-name/working/ws-name/

iPlanet servers only

Backup copy of NSAPI configuration file for iPlanet server

templates-id


templates-id

inst-name/working/ cds-name/

Template cache written by Template Manager and read by Page Generator

See also: • Appendix B, VCMS File Reference• Appendix A, VCMS Process Reference• Viewing VCMS Log Information on page 6-10



Function

WINDOWS SOLARIS



Understanding Tool DirectoriesThe VCMS software creates folders (directories) for its tool files when the tool sets are installed. The following folders are installed in these default locations:

Understanding Preference Files

The VCMS software saves various preference information in two files:

• security.cfg — Configuration information for tools client security.

• Preferences — Browser preferences and CDS to use when previewing templates or viewing on-line documentation. Also stores default login information.

The VCMS software generates and updates these files as necessary.

C:\Program Files\Vignette\Tools\bin\ Contains the executable (ss.exe) for the VCMS tools and shortcut for the VCMS launch bar.

C:\Program Files\Vignette\Tools\java\ Contains Java files and directories for the tools, as well as licensing and copyright information.

C:\Program Files\Vignette\Tools\lib\ Contains files used by the tool programs.

See also: • Appendix B, VCMS File Reference• Appendix A, VCMS Process Reference• Understanding Preference Files on page 6-16

Topics include: • The security.cfg File• Preferences File



The security.cfg File

There are various security settings you can configure for the tools client.

• You can request, import, and designate the secure certificates that the tools client submits to the CMS for authentication.

• Just as the client submits these certificates to the CMS, so the CMS submits certificates to the client. You need to specify which fields and values you want the client to verify in the incoming CMS certificate.

• Finally, in order for SSL to function, all certificates will need to be signed by a trusted CA (Certificate Authority). You specify which CAs the tools client trusts to sign the incoming CMS certificates.

The tools client stores all of its configuration information locally in the security.cfg file. The contents of security.cfg are not encrypted, however any client keys that have been encrypted with passwords appear here only in their encrypted form.

Preferences File

You set preferences for the browser and CDS to use when previewing templates in the Production Center tool set and in the Development Center. Your browser preference is also used for viewing on-line documentation in other VCMS 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 on-line documentation. This file also stores the specific web server to use for previewing. The VCMS generates and updates this file when you:

• Start a VCMS tools session by logging in. The VCMS tools automatically save your login information each time you log in and also save the last CMS accessed as the default for your next log in.

• Save your preferences by using the Preferences option from the File menu of the VCMS launch bar.

See also: • security.cfg on page B-39• Tools client security chapter of the Security Guide• Configuration Reference



You should not edit this file manually. For more information on using the VCMS launch bar to set your browser preferences, see the section on setting browser preferences in Running the Vignette Content Management Tools.

The VCMS software detects the user’s home directory and stores the Preferences file in the Vignette subdirectory of that home directory.

For example:

\\home\alette\Vignette\Preferences

See also: Preferences on page B-38


7 Managing System and Content Databases

Summary; How to manage the Vignette® Content Management Server V6 (VCMS) system database and how to configure separate content databases.

Audience: Administrators and DBAs for the VCMS software


Topics include: • Overview• System Database Requirements• Database Access• Configuring One or More Content Databases Separate From the

System Database• Handling Legacy Data

See also: • Appendix C, System Database Tables• Visitor Services Guide • Production Center Guide • Configuration Reference


Managing System and Content Databases Administration Guide

OverviewWhen you configure a standard Content Management Server (CMS) component, you specify a single database for the VCMS software to use. The VCMS software accesses and stores both content and system information in the database, which it divides logically into two parts:

• User content — The rows of user content, stored in a set of tables called content tables.

• System content — The management information about all records, files, and templates (their meta-data, such as their projects, owners, and current status), as well as information about projects, tasks, VCMS users, Application Servers, and so on. The VCMS software stores the information in a set of tables called system tables. If your site uses version control, the system database also contains record versions.

NOTE: By default, visitor information is also stored in the system database and is considered to be part of the system content. See the Visitor Services Guide for more information.

If all data is stored in the system database, you may want to create two separate database user authorizations for that database:

• A login for the template environment users to access their own tables (most likely, content tables)

• A login for the VCMS processes to access VCMS system tables containing production management and user information

Creating separate logins ensures that template developers cannot view or modify the VCMS system tables through the template environment.

You can also configure the VCMS software to access separate system, content, and visitor databases by setting the appropriate configuration variables.

Instead of storing content in the VCMS system database, you can configure your installation to store content in one or more separate content databases. If you want to store content in a database that is separate from the system database and did not configure the VCMS software accordingly during installation, see Configuring One or More Content Databases Separate From the System Database on page 7-13.


Administration Guide Managing System and Content Databases

Visitor record information is stored in the vgn_ur table in the system database. As an alternative to this default, you can configure your VCMS installation to store visitor record information (such as user ID, name, and address) in a separate database with separate database user authorization. If you decide to store visitor record information in an external database, you must edit the VISITOR_DB_* configuration variables of the Observation Management Server (OMS) so they include the necessary information about the location and access of vgn_ur. See the Visitor Services Guide and the Configuration Reference for more information.

It is important to distinguish between separate VCMS system, content, and visitor databases on the one hand, and separate logins to the VCMS system database on the other. The VCMS software allows you to configure for either or both of these scenarios. See the following figure:

The SYSTEM_DB_*, CONTENT_DB_*, PM_CONTENT_DB_*, and TEMPLATE_SYSTEM_DB_* variables mentioned in the diagram are discussed in Database Configuration Variables on page 7-6. The VISITOR_DB_* variables are discussed in the Visitor Services Guide.

VCMS Content DB

VisitorDB

VCMSSystem DB

System tablesrequire the

SYSTEM_DB_*variables for login

The template environment uses the

TEMPLATE_SYSTEM_DB_*variables for login

Content databasesrequire the

CONTENT_DB_*and

PM_CONTENT_DB_*variables for login

Visitor databasesrequire the

VISITOR_DB_*variables for login



For a full description of how to create a separate content database, see the section called Configuring One or More Content Databases Separate From the System Database on page 7-13. For a description of how to create a separate visitor database, see the Visitor Services Guide.

For information on the VCMS content types and to access content through the database tables, see the Vignette Content Management Server Overview.

System Database RequirementsThe following sections give requirements and recommendations for using the VCMS system database on Windows, Solaris, or AIX.

TIP: We encourage you to back up your database regularly as recommended by your database vendor. This practice provides some protection for your VCMS database information.

Database Permissions

The username under which the VCMS software operates in the VCMS system database needs permissions for the various database types. The username (or usernames) requires the following permissions; whether you have a single database login or separate logins for content and system tables:

• Connect to the database

• Create, alter, and drop tables, views, and stored procedures

• Insert, update, and delete rows

These rights are needed by all databases supported for the software. See your database vendor documentation for vendor permission requirements.

Topics include: • Database Permissions• Database Size



Database Size

For information on database size requirements, see the VCMS Installation and Configuration Guide (printed copy shipped with product).

In addition, include enough space to accommodate your site templates, content, content versions, and logs. The necessary space varies depending on the size of your current site and future needs.

Database Access

When you configure a CMS, you provide information about the database in which the VCMS software will store user, project, template, record, and file information. This information includes the database user, password, database name, database type, and so on.

Depending on whether the database is the VCMS system database or a content database, this information is owned either by the CMS or by the CDS. If the database access information is for the system database, the VCMS software maintains the information with the CMS’s configuration information. If the database access information is for a content database, the VCMS software maintains the information with the CDS’s configuration information.

NOTE: If you want to configure a separate visitor database, you must set the VISITOR_DB_* configuration variables. The VCMS installation programs do not prompt for visitor database information during installation and configuration. See the Visitor Services Guide for more information.

Topics include: • Database Configuration Variables• Content Databases of Different Types• Configuring a Second Login for the Template Environment• Password Encryption• Database Access Through Templates



Database Configuration Variables

VCMS configuration variables define the database name, path, server, library, and so on for the system, content, and visitor databases. The variables for:

• The system database are named SYSTEM_DB_*• CDS access to the content database are named CONTENT_DB_*• CMS access to the content database are named PM_CONTENT_DB_*• The visitor database are named VISITOR_DB_*• Accessing the system database from the template environment are named TEMPLATE_SYSTEM_DB_*

See the Configuration Reference for information about all database configuration variables. See also the Visitor Services Guide for information about the VISITOR_DB_* variables.

The database configuration variables allow for the following connections:

If you maintain system and content tables on the same database, the SYSTEM_DB_* and CONTENT_DB_* variables will be the same, and you will not need to add the PM_CONTENT_DB_* variables.

VCMS process Must have access to

Dispatch Service (bob)

Tcl Page Generator (ctld)

ASP Page Generator (IIS web server instance)

JSP Page Generator

Template Manager (tmd)

Event Service (vhs)

Observation Manager (omd)

Campaign Logging Agent (cld)

The system database tables

Dispatch Service (bob)

Tcl Page Generator (ctld)

ASP Page Generator (IIS web server instance)

JSP Page Generator

The content database tables



In addition, you may choose to have a single content database or multiple content databases. If you have a single content database, the values for the database configuration variables for each Page Generator (on each CDS) must match. On the other hand, if you have multiple content databases, the values for the database configuration variables may differ from Page Generator to Page Generator depending on which content database that Page Generator accesses. See Configuring One or More Content Databases Separate From the System Database on page 7-13 for more information.

Content Databases of Different Types

If the VCMS software is installed on Solaris and your content database is not the same type as your system database, you must ensure that the Page Generator can access the content database. To do so, add and set the configuration variable for the content database as described in the following procedure.

■ To enable access to a content database of a different type:

1 Log in to the Page Generator’s host as the VCMS administrator.

2 For each Page Generator that accesses the content database, modify that Page Generator’s configuration information to include the path to the database’s library information. For example, for DB2, that would be the literal path to the sqllib/lib directory.

NOTE: For DB2, you must also supply that path in your LD_LIBRARY_PATH environment variable.

For Oracle or Sybase, you would set the ORACLE_HOME or SYBASE variable to the appropriate path (if it doesn’t already exist).

For example, if your system database is Oracle and the content database is Sybase, you should add the SYBASE configuration variable and set it to the path for the Sybase home directory. You can use either the Platform Variable Editor or the admin cfgedit utility to add and set configuration variables. See the Configuration Reference for instructions.

3 Stop and restart the CDS processes using the admin command:

cd install-path/vignette/inst-name/conf/cds-name./admin restart



Configuring a Second Login for the Template Environment

If you have a new VCMS installation, the installation process prompted you to set up a second login to the system database. The procedure is documented in the VCMS Installation and Configuration Guide (printed copy shipped with product).

If you want to set up or change the login for the template environment after your initial installation, you must follow the steps outlined in this section.

Database Vendor Login Requirements for Separate Database Logins

Whether you configure a second database login at initial installation or configure a second login later, you must set up two users using your database software. Consult the documentation for your database software.

The VCMS software supports DB2, Microsoft SQL Server, Oracle, and Sybase databases, each of which requires that you configure two user logins according to the following table:

You must assign both users the permissions described in Database Permissions on page 7-4.

Topics include: • Database Vendor Login Requirements for Separate Database Logins• Setting the TEMPLATE_SYSTEM_DB_* variables for the Second

Database Login• Changing the Table Ownership for Non-System Tables• Granting SELECT Permissions for Certain System Tables

WINDOWS/SOLARIS/ AIX

DB2

Create two users in the database. Neither user should be the instance owner or have database administrator authority.

WINDOWS

Microsoft SQL Server

Set up two users with the same default database. Neither user should have the db_owner role, because the logins must map to a user name in the user repository rather than to the internal, predefined database user (dbo).

WINDOWS/SOLARIS

Oracle

Set up two users with the same default table space.

WINDOWS/SOLARIS

Sybase

Set up two users with the same default database. Neither user should be the database owner, because the logins must map to a user name in the user repository rather than to the internal, predefined database user (dbo).



Setting the TEMPLATE_SYSTEM_DB_* variables for the Second Database Login

The login used by the template environment grants access to the VCMS system database, but not to sensitive VCMS system tables. Access depends on the ownership you set for the individual tables.

NOTE: If you currently have system and content tables in a single database—that is, if the SYSTEM_DB_* variables for the CMS match the CONTENT_DB_* variables for the CDS—then you must change the CONTENT_DB_* variables to reflect the template environment login. Change the PM_CONTENT_* variables for the CMS and for each CDS that accesses this content database.

Using the Platform Variable Editor or the admin cfgedit utility, set the following variables for the template environment:

• TEMPLATE_SYSTEM_DB_USERNAME• TEMPLATE_SYSTEM_DB_PASSWORD• TEMPLATE_SYSTEM_DB_PASSWORD_ENCRYPTED

If you use the Platform Variable Editor, navigate to the node for the bob process within the CMS component to access and update these variables. You also have the option of editing these variables in the cms.cfg file using the admin cfgedit utility. Regardless of the tool you use, be sure to refresh the values in all of the configuration files that reference the variables. See the Configuration Reference for more information.

Changing the Table Ownership for Non-System Tables

Change the ownership for any tables that are not VCMS system tables. The system tables are listed in Appendix C.

The owner for these tables should correspond to the template system user configured with the TEMPLATE_SYSTEM_DB_USERNAME variable.

See your database documentation for information about changing table ownership.

You must also run specific SQL commands found in the template_system.sql.* file located in the following directories.

WINDOWS install-path\6.0\adm\sql\

SOLARIS install-path/vignette/6.0/adm/sql/



Depending on your database software, you will use one of the following:

• template_system.sql.db2

• template_system.sql.ora

• template_system.sql.syb

• template_system.sql.mss

Use your database vendor’s client tool to run the SQL found in the file.

NOTE: You must be logged in as the template system user (TEMPLATE_SYSTEM_DB_USERNAME) when you run the file.

Granting SELECT Permissions for Certain System Tables

Additionally, you must grant SELECT permissions to the template environment login for the following VCMS tables:

• vgn_ci

• vgn_cp

• vgn_roles

• vgn_sg

• vgn_ur

• vgn_version

• vgn_version_tag

Granting select permissions for these tables ensures that certain Tcl template commands can function.

NOTE: If you have a separate visitor database, there are additional system tables that require SELECT permissions. See the Visitor Services Guide for more information.



You should also grant SELECT permissions for any other VCMS system tables that may be accessed from the template environment. Additionally, any template code that refers to these tables needs to be modified to prefix the table name with the system database login. For example, if a template accesses vgn_ur, the template code should be written as follows:

[SEARCH TABLE user_profile INTO vgnData SQL { select * from vgnsysuser.vgn_ur }]

where vgnsysuser is the value of the SYSTEM_DB_USERNAME configuration variable for the CMS.

Password Encryption

Encryption of database passwords is enabled by default for new VCMS installations. If you are upgrading from a previous version of the Vignette software, or if you disabled password encryption for some reason, you can turn password encryption on by following the steps described here. You use the encrypt utility to create encrypted passwords, and then update the appropriate configuration variables.

The encrypt utility resides in the following directories:

• SOLARIS

install-path/vignette/6.0/bin/solaris/

• WINDOWS

install-path\6.0\bin\winnt

■ To turn on database password encryption:

1 Use the encrypt command to create the encrypted versions of the system or content login password. (The two passwords will be the same if you configured one login for access to the VCMS system database.)

At the command line, enter:

encrypt password

For example, to encrypt the password “l1vely,” enter encrypt l1vely. The encrypt command displays a value like this: 21,Hs8g3nvRG.

You may want to direct the output to a file. For example, on Windows:

encrypt l1vely > systems\dbpass



2 Substitute the encrypted system database password for the cleartext password in the variables that apply to your configuration.

You can use the Platform Variable Editor to change the configuration variables or the admin cfgedit utility to edit the variables in the indicated configuration file. See the Configuration Reference for more information.

3 If you have changed from a cleartext password to an encrypted one, set the corresponding *_DB_PASSWORD_ENCRYPTED variable to yes.

4 If you are changing values for a login to content tables, be sure to substitute the encrypted password for the cleartext password for each CDS.

If encryption is already turned on and you want to change the database password, simply encrypt the new password and substitute it for the old password in the appropriate configuration variable.

Variable name Configuration file

SYSTEM_DB_PASSWORD cms.cfg

TEMPLATE_SYSTEM_DB_PASSWORD cms.cfg

CONTENT_DB_PASSWORD cds.cfg

PM_CONTENT_DBn_PASSWORD cms.cfg

VISITOR_DB_PASSWORD oms.cfg



Database Access Through Templates

In order to grant templates access to the content tables, the Page Generators initialize each template with the values that appear in the CONTENT_DB_* variables for the CDS.

However, because content can be stored in tables in multiple databases, templates may need to be able to override the initialized values in order to access other content tables for the content they display. Within Tcl templates, you can use the SET template command to override the initialized settings in order to point a template to content tables on any accessible database. See Setting Database Variables in Tcl Templates on page 7-19 for more information.

NOTE: Pointing templates to content tables is handled differently within ASP and JSP templates. See the COM: Vignette Services API Guide and Reference for information about system and content database access from ASP templates. See the Java: Vignette Services API Guide for information about system and content database access from JSP templates.

Configuring One or More Content Databases Separate From the System Database

You may want to store or access content in one or more content databases that are separate from the VCMS system database. If you do that, you must make it possible for templates to access that content.

Summary: Describes the ways that you can configure one or more content databases separate from the system database.

Topics include: • Performance and Database Access• Records and Rows• Database Content with or without Production Management• GET_NEXT_ID with Multiple Content Databases• Setting Database Variables in Tcl Templates• Changing the Default Content Database• The Dispatch Service (bob) and Separate Content Databases



There are two ways you can make content available to templates if the content is stored in a separate content database:

• By identifying the content database in the CDS’s configuration information. Then records are accessed and stored in that content database by default. When a CDS is configured, content database variables are automatically set to identify the VCMS system database, but you can change them. This method is useful when the majority of your site’s records are stored in a single content database (or when you want a particular CDS to store and access records in a content database separate from the main one).

The section called Changing the Default Content Database on page 7-26 explains this method.

• By setting global variables in the template that identify the content database. For example, a template that wants to save a row to another database would set the database variables to the content database before inserting the row. This method is useful when a template needs to store or access a record in a content database other than the default database.

NOTE: See Records and Rows on page 7-16 for a discussion of the difference between “records” and “rows.”

The section called Setting Database Variables in Tcl Templates on page 7-19 explains this method for Tcl Templates.

NOTE: See the COM: Vignette Services API Guide and Reference for information about system and content database access from ASP templates. See the Java: Vignette Services API Guide for information about system and content database access from JSP templates.

In addition to making it possible for templates to access separate content databases, you should also give the CMS dispatch process (bob) access to those databases. See The Dispatch Service (bob) and Separate Content Databases on page 7-31 for instructions.



Some considerations if you store rows in a separate content database:

• Using the GET_NEXT_ID command — Content entry and save templates use the GET_NEXT_ID command to assign the next available ID to a new record. If your site stores records in multiple content databases, you must make sure that content table names are unique across the databases. See the section GET_NEXT_ID with Multiple Content Databases on page 7-18.

• Performance and database access — The section Performance and Database Access on page 7-15 discusses performance with separate content databases and explains when the databases need to be available to the VCMS software.

Performance and Database Access

Each content database that the VCMS templates will access must be accessible by the database client software installed on the hosts that have Application Engines configured for the CDSs and on the CMS host. See your database documentation for the client connection requirements. As a rule of thumb, you must be able to open the database client tool on the Application Engine or CMS host and connect to the content database.

For best performance, make sure that separate content databases are accessed over fast connections. A separate content database should have the same access speed as the system database.

Policies for system database availability and content database availability:

• System database (CMS) — When the CMS starts up, the Dispatch Manager process (bob) attempts to connect to the system database server. The database server must already be up and available, or bob will fail to start. When it starts, the CMS maintains a connection to the system database at all times. If the database server goes down or otherwise becomes unavailable, bob retries the connection once. When it next needs to access the database, it tries a second time to connect. If the database is still unavailable, the CMS shuts itself down.

• System database (CDS) — The Template Manager process (tmd) within each Application Engine attempts to connect to the system database when the CDS starts. If it fails, the template cache for that Application Engine may become stale in relation to the rest of the CDSs. The Page Generator process in each Application Engine attempts to connect to the system database when evaluating certain template commands. If it can’t connect, page generation fails with a processing error.



• Content database (CMS) — If you specified a separate content database and identified it to the CMS by setting the appropriate configuration variables (PM_CONTENT_DB_*) and that database isn’t available when the CMS starts, the CMS still starts successfully. It will log an error that it couldn’t connect to the content database.

• Content database (CDS) — The Tcl Page Generator (ctld) connects to a content database on demand (for example, to run a SEARCH TABLE or ROW_UPDATE command). If the database isn’t available, the CDS logs an error and continues. If an ASP or JSP Page Generator is not able to connect to a content database, the error generated depends on the connection method used by the template developer.

Records and Rows

Record has a special meaning to the VCMS software. A VCMS record is more than the content stored in a database row: it consists of both the content and the metadata—management information—associated with the content. The metadata includes the properties defined in the Details window when you add a record, its workflow data, its current status, its project information, and so on. The metadata is stored in the system database, regardless of where the content is stored.

The VCMS software provides separate Tcl template commands for inserting, updating, and deleting rows and records:

• The ROW_INSERT, ROW_UPDATE, and ROW_DELETE commands work on the content—the row in the content database. For example, the ROW_UPDATE command modifies the database row.

• The RECORD UPDATE, RECORD UPDATE_VER, and RECORD DELETE commands work on the record metadata—the management information stored in tables in the system database. (RECORD UPDATE_VER also copies the record content.) For example, when you run it the first time for a row, RECORD UPDATE creates a management record for the row, adds a record to the specified project, and starts the record workflow. Subsequent RECORD UPDATE commands change the record’s modification history and, depending on the record’s status, may restart its workflow.



Database Content with or without Production Management

As Records and Rows on page 7-16 explains, a row in a database is different from a VCMS record. But you don’t necessarily have to create a record for every row.

A row must have an associated record only if you want the VCMS software to manage the production of the content with the VCMS Tools. That is, if you want the database content to be added to a Production Center project, to go through a workflow, to be launched, expired, and so on, through the Production Center, the content must have a VCMS record.

You create a record for a row either by notifying the CMS directly with the RECORD UPDATE command or by adding a record through the Production Center (which in turn notifies the CMS by accessing a template that runs the RECORD UPDATE command). For details about the RECORD UPDATE command, see the Tcl: Template Command Reference.

NOTE: You can also create records using commands available through the VCMS APIs (Tcl, C++, COM, and Java).

If you want to control the content that appears on your live web site by status or by version, then the VCMS software must manage that content. The BY_STATUS option to the FILTER command and the BY_VERSION and BY_STATUS options to the SEARCH command need the status and version information associated with Production Center records.

If you just want the VCMS software to retrieve the content from a database and display it, then the content doesn’t require a VCMS record. Simply access the database row from a Tcl template, with SEARCH TABLE, for example, to include the content in a generated page. (For information about identifying the database, see Setting Database Variables in Tcl Templates on page 7-19.)

For example, suppose you have one database of world weather information received from a news feed. Another database contains human resources information.

The weather database doesn’t require production management: it just needs to be displayed on the Web. The human resources data does require management: each item goes through several reviews, and data must be launched, updated, and expired regularly. You also want to save versions of the information.

In this case, you would create records only for the rows in the human resources database.



The implications for the ROW* and RECORD commands:

• To add and update database content (rows) that doesn’t need Production Center management, use either the commands for your database or the ROW_INSERT and ROW_UPDATE commands. The ROW_INSERT and ROW_UPDATE commands are convenient if your site has multiple databases of different types, because they work across database types.

• To add and update database content that you want the Production Center to manage, use either the commands for your database or the ROW_INSERT and ROW_UPDATE commands. Also use the RECORD commands to create a VCMS management record, with its accompanying project, workflow, and other properties, and to notify the VCMS software of changes.

For example, if you change the row contents with ROW_UPDATE, notify the VCMS software of the change with RECORD UPDATE. Then the VCMS software can change the record’s modification data and, if necessary, restart its workflow.

GET_NEXT_ID with Multiple Content Databases

The VCMS software manages IDs for new rows with an internal system table called next_id. The first time a content table is listed as any template’s Primary table (in the template’s Details window), the VCMS software creates a row for the content table in the next_id table. The row contains the content table name and the next available ID for a record added to that table.

Templates that add a new record to the content database use the VCMS software’s GET_NEXT_ID command to allocate an ID to the record. One argument to GET_NEXT_ID is the name of the table to which the record will be added. GET_NEXT_ID looks in the next_id table for the next available ID for that table.



Table name collisions can occur if your site has multiple content databases, because the next_id table doesn’t identify the database to which a table belongs. To avoid name collisions, all table names must be unique across the content databases. You might want to adopt the standard SQL convention of DBname.tablename (for example, partsDB.partnum).

NOTE: If your Tcl template environment is configured to access content databases that are a different database type than your system database, be sure to set the vdbmsg(rwdblib) parameter (to the system database type) in templates that implement the GET_NEXT_ID command. (For example, if your system database is Oracle and your content database is Microsoft SQL Server.) Setting this variable enables you to access the next_id system table from your templates. See the following section to learn how to set the vdbmsg(rwdblib) parameter.

Setting Database Variables in Tcl Templates

When your VCMS site needs to access multiple content databases and the template needs to store or access a record in a content database other than the default database (identified in the CDS’s configuration information), set the appropriate variables as explained in the following procedure.

NOTE: By default, the VCMS software encrypts the database password.

The basic sequence for setting database variables in a Tcl template:

1 Set the database variables to identify the content database you want.

A template needs to set only those variables whose default settings it needs to override:

• If the two databases are the same type (Sybase, for example), then the template must set the appropriate USERNAME, PASSWORD, SERVER, and DATABASE, and vdbmsg(password_encrypted) variables.

• If the two databases are different types, then the template must also set the CONTENT_DB_TYPE and vdbmsg(rwdblib) variables.

When setting PASSWORD, a template must take encryption into account. The template must either set PASSWORD to match the encryption setting for the CDS or override the setting with the vdbmsg(password encrypted) variable. See the section titled PASSWORD Setting and Encryption on page 7-23.



To verify the USERNAME, PASSWORD, SERVER, and DATABASE settings in the template, see if you can connect to the database with them, using the client tool supplied by your database vendor. (Reminder: This will only work if the value of PASSWORD is not encrypted.)

NOTE: You don’t need the CONNECT command in the Tcl template. VCMS commands that access the database, like SEARCH TABLE or NEEDS, establish the connection themselves.

2 Do what you need to while connected to the database (insert rows, select, and so on).

3 If the template needs to access another content database, set the database variables again.

The same Tcl template can connect to multiple databases of the same or different types by resetting the database variables as needed.

For example, if the template next needs to access rows in the default content database:

[SET USERNAME $CONTENT_DB_USER][SET PASSWORD $CONTENT_DB_PASSWORD][SET SERVER $CONTENT_DB_SERVER][SET DATABASE $CONTENT_DB_DATABASE][SET vdbmsg(password_encrypted) $CONTENT_DB_PASSWORD_ENCRYPTED]

If the database is of a different type, the template also requires these lines:

[SET CONTENT_DB_TYPE $CONTENT_DB_TYPE][SET vdbmsg(rwdblib) $CONTENT_DB_RWDBLIB]

NOTE: By default, the CONTENT_DB_* variables are set to the same values as the corresponding SYSTEM_DB_* variables. See the Configuration Reference for a description of each variable.

Set the variables in the Tcl template as follows:

USERNAME database-user-name

where database-user-name is the user name (login) for the content database.

PASSWORD database-user-password

where database-user-password is the login password for the database user. Set PASSWORD to the encrypted form of the content database password if appropriate. See PASSWORD Setting and Encryption on page 7-23.



SERVER database-server-name

where database-server-name is the logical name of the database server (the logical name that the database client uses to connect to the database server). Database clients typically use this name to determine the network-specific protocol information needed to access the server, such as machine name and TCP port.

DATABASE database-name

where database-name is the name of the content database for DB2, Sybase, and MS SQLServer databases.

For an Oracle database, enter an empty string as the value of DATABASE ("") and set the CONTENT_DB_SID variable.

vdbmsg(password_encrypted) [yes | no]

which determines whether PASSWORD is encrypted or plain text. See Password Encryption on page 7-11.

CONTENT_DB_SID sid

where sid is the system identifier for the database. This variable applies to Oracle databases only.

CONTENT_DB_TYPE database-type

where database-type is DB2, MSSqlServer, Oracle, or Sybase.

vdbmsg(rwdblib) database-access-library

where database-access-library is the appropriate library for the database type and operating system:

Database and version Operating system Access library

DB2 7.1 Solaris and AIX librwdb2_mt.so

Windows 2000 and NT mddb2dgmt.dll

Microsoft SQL Server 2000 Windows 2000 and NT mdmodbcdmt.dll

Oracle 8.1.6 Solaris librwora816_mt.so

Windows 2000 and NT mdo816dmt.dll



For Tcl templates, if templates must switch often between databases, you could create Tcl procedures in the delivery.tcl file to handle setting and resetting the variables.

Special Considerations for BY_STATUS and PROFILE_MARK

In most cases, you don’t have to reset the database variables to their default values unless the template logic requires it. When a template sets the database variables, the values are changed only within the context of the template evaluation. However, there are special considerations for the BY_STATUS command keyword and the PROFILE_MARK command.

BY_STATUS

The BY_STATUS command keyword will work correctly only if the setting for vdbmsg(password_encrypted) is the same for both the content database and the system database (usually yes).

PROFILE_MARK

You must restore the setting of vdbmsg(password_encrypted) before invoking the PROFILE_MARK command in a template. PROFILE_MARK queries the system database, so if the password is different (changed by the vdbmsg(password_encrypted)) variable, it can’t connect and will fail.

Follow this sequence with PROFILE_MARK:

1 Save the state of vdbmsg(password_encrypted).

2 Set up variables to access the different database.

3 Reset vdbmsg(password_encrypted) to its original value.

4 Use PROFILE_MARK.



Sybase 12 Solaris librwctlib_mt.so

Windows 2000 and NT mdscdmt.dll




PASSWORD Setting and Encryption

For security, most sites encrypt the password variables for the system database and for content databases. The CONTENT_DB_PASSWORD_ENCRYPTED variable determines whether the password for the content database should be encrypted.

NOTE: Although the configuration variable name is CONTENT_DB_PASSWORD_ENCRYPTED, the Tcl template environment pays attention to the variable vdbmsg(password_encrypted) in order to alter the password encryption setting. Likewise, the template environment pays attention to the variable vdbmsg(rwdblib) in order to set the database-access-library. (The CONTENT_DB_RWDBLIB configuration variable serves the same purpose.)

For the VCMS system database, the configuration variable is SYSTEM_DB_PASSWORD_ENCRYPTED.

NOTE: The purpose of password encryption is to prevent people from reading the password from log files, error messages, or template error messages. The password is only unencrypted before interaction with the database client software.

When connecting to the content database in a Tcl template, you can either match the vdbmsg(password_encrypted) setting or override it. To encrypt the password, use the encrypt command, which resides in the ...\6.0\bin\winnt or .../6.0/bin/solaris directory:

encrypt password

The encrypt command returns a value like this: 21lH60W,S5yG. Set PASSWORD to that value.

To override the setting for the CONTENT_DB_PASSWORD_ENCRYPTED configuration variable, set the vdbmsg(password_encrypted) variable in the template to yes for encryption or to no for no encryption.



Examples

Example 1 shows Tcl template code that inserts a new row into a content database that’s not the default content database (that is, the database defined in the configuration information for the CDS). This example does the following:

1 Sets the database to the content database xad2 on the database server 3rdbase.

2 Inserts a new row into the content database (ROW_INSERT).

3 Tells the VCMS software to create a management record for the content (RECORD UPDATE).

Assume that encryption is turned on for the default content database password.

NOTE: The RECORD UPDATE arguments depend on position. The arguments shown in the following example follow this order: dbKey, tableName, dbServerName, dbName, primaryKey, projectID, recordName.

Example 1

[# Set DB connect parameters][SET USERNAME vignette][SET PASSWORD 201p9HeijAiVez8p5MnV][SET SERVER 3rdbase][SET DATABASE xad2]

[############### Tcl TEMPLATE-SPECIFIC CODE HERE ##################]

[# Create the new row [# Get an id for the movie table and insert the data] [GET_NEXT_ID movie_id TABLE xad2.movie] [SET STATUS [ROW_INSERT movie COLS { movie_id title genre rating director plot_summary review language release_date } VALUES { {[SHOW movie_id]} {[SHOW TITLE]} {[SHOW GENRE]} {[SHOW RATING]} {[SHOW DIRECTOR]} {[SHOW PLOT_SUMMARY]} {[SHOW REVIEW]} {[SHOW LANGUAGE]} {[SHOW RELEASE_DATE]} } ]]



[# Create the new record [# Tell VCMS software to create a management record - [RECORD UPDATE [SHOW movie_id] xad2.movie 3rdbase xad2 movie_id /pr/2b "[SHOW TITLE]"] [############## MORE Tcl TEMPLATE-SPECIFIC CODE HERE ##################]

}]

Example 2

Example 2 connects to multiple databases from the same Tcl template.

[SET archived_SERVER [SHOW SERVER]]

[#Make a query to a content DB that is not the default content DB. Imagine that the default database does not expect an encrypted password, but the intended database does.] [SET USERNAME SSAbcUser] [SET vdbmsg(password_encrypted) yes] [SET PASSWORD 21.tTWm0mMSeTI6N] [SET SERVER bagpipe2] [SET DATABASE SSAbcDB] [SEARCH TABLE foo INTO bar SQL "

SELECT * from text_test "] [SHOW bar] <BR> [# ...other commands... ]

[# Make a query to the default content DB. Remember, the default content database does not expect an encrypted password.] [SET SERVER [SHOW archived_SERVER]] [SET USERNAME SSDefUser] [SET vdbmsg(password_encrypted) no] [SET PASSWORD l1vely] [SET DATABASE SSDefDB] [SEARCH TABLE foo1 INTO bar1 SQL " SELECT * FROM test "] [# ...other commands... ] [SHOW bar1]



Changing the Default Content Database

You can specify a default content database separate from the VCMS system database by setting configuration variables for the CDS. Use this method when the majority of your site’s content is stored in a single content database or if for any reason you want a CDS to store and access records in a separate content database.

Concepts

Each CDS has a set of configuration variables that describe the content database where the CDS stores and accesses records by default.

The Page Generators use these variables to find the database if a command in a template accesses the content database and the template hasn’t set a specific content database.

The default VCMS configuration assumes that the system database and the content database are the same.

You may want to set the same default content database for all the CDSs associated with a single CMS. If you have a single content database separate from the VCMS system database, for example, then you define that content database for each CDS.

However, the VCMS software doesn’t require that the content databases be the same, and you may want to configure different content databases for different CDSs. Some possible reasons for different content databases:

• For performance and scaling. You can separate the content databases of live and development CDSs, for example.

• To dedicate a development CDS for testing and development without affecting performance on other CDSs. You might keep only a representative subset of content on the dedicated CDS.

• For fault tolerance. If you have CDSs in a round-robin configuration and you use software for replicating databases, you can create two or more identical databases and configure a different CDS with each one. Then your web site will still function if a database server goes down.



Setting the Variables

■ To specify a different default content database for a CDS:

1 Start the Platform Variable Editor or the admin cfgedit utility to edit the appropriate configuration variables. (For information about editing configuration variables see the Configuration Reference.)

2 Change the values of some or all of the following variables to identify the new default content database:

• CONTENT_DB_SERVER

• CONTENT_DB_DATABASE

• CONTENT_DB_SID (relevant for Oracle only)

• CONTENT_DB_USERNAME

• CONTENT_DB_PASSWORD

• CONTENT_DB_PASSWORD_ENCRYPTED

• CONTENT_DB_CONNECTION_CLASS (relevant for Java only)

• CONTENT_DB_CONNECTION_URL (relevant for Java only)

You need to set only those variables whose values are different for the new database.

NOTE: Be careful when changing the database configuration variables if the VCMS system database and the content database(s) are Oracle databases. For more information, see Knowledge Base item 2922 in VOLSS.

3 If the new default content database is a different type from the previous database, then also set these variables:

• CONTENT_DB_RWDBLIB

• CONTENT_DB_TYPE

Set the variables as follows:

CONTENT_DB_SERVER database-server-name

where database-server-name is the logical name of the database server (the logical name that the database client uses to connect to the database server). Database clients typically use this name to determine the network-specific protocol information needed to access the server, such as machine name and TCP port.



CONTENT_DB_DATABASE database-name

where database-name is the name of the content database for DB2, Sybase, and MS SQLServer databases.

For an Oracle database, enter an empty string as the value of CONTENT_DB_DATABASE ("") and set the CONTENT_DB_SID variable.

CONTENT_DB_SID sid

where sid is the system identifier for the database. Set this variable for Oracle databases only.

CONTENT_DB_USERNAME database-user-name

where database-user-name is the user name (login) for the content database.

CONTENT_DB_PASSWORD database-user-password

where database-user-password is the login password for the database user. Encrypt the password if appropriate.

CONTENT_DB_PASSWORD_ENCRYPTED yes | no

which determines whether CONTENT_DB_PASSWORD is encrypted or plain text. See the section titled PASSWORD Setting and Encryption on page 7-23.

CONTENT_DB_CONNECTION_CLASS driver-class

where driver-class is the JDBC driver class to use. Valid values include:

Database JDBC driver

DB2 com.ibm.db2.jdbc.app.DB2Driver

Oracle oracle.jdbc.driver.OracleDriver

Sybase com.sybase.jdbc2.jdbc.SybDriver

Microsoft SQL Server com.inet.tds.TdsDriver



CONTENT_DB_CONNECTION_URL connection-url

where connection-url is the JDBC connection URL. Connection URL formats include:

NOTE: The literal values of hostname, port, and dbname (and sid for Oracle) are inserted into this variable value. If you change the values of any of the variables used in the construction of this variable, CONTENT_DB_CONNECTION_URL, you may need to edit this variable to reflect the new values. See the Configuration Reference for more information.

NOTE: For more information on database connections from JSP templates, see the Java: Vignette Services API Guide.

CONTENT_DB_RWDBLIB database-access-library

where database-access-library is the appropriate library for the database type and operating system:

Database JDBC connection URL

DB2 jdbc:db2:hostname:port/dbname

Oracle jdbc:oracle:thin:@hostname:port:sid

Sybase jdbc:sybase:Tds:hostname:port/dbname

Microsoft SQL Server jdbc:inetdae:hostname:port?database=dbname


DB2 7.1 Solaris or AIX librwdb2_mt.so

Windows 2000 and NT mddb2dgmt.dll

Microsoft SQL Server 2000 Windows 2000 and NT mdmodbcdmt.dll







CONTENT_DB_TYPE database-type

where database-type is DB2, MSSqlServer, Oracle, or Sybase.

See the Configuration Reference for more information on these variables.

Example

The following examples show sample values for the configuration variables that you should set.

For a DB2 database on AIX:

CONTENT_DB_RWDBLIB librwdb2_mt.soCONTENT_DB_TYPE DB2CONTENT_DB_SERVER KALLISTOCONTENT_DB_DATABASE "VignContent"CONTENT_DB_SID ""CONTENT_DB_USERNAME arcas1CONTENT_DB_PASSWORD 413rE99gYY3

For an Oracle database on Solaris:

CONTENT_DB_RWDBLIB librwora816_mt.soCONTENT_DB_TYPE OracleCONTENT_DB_SERVER MADRONECONTENT_DB_DATABASE ""CONTENT_DB_SID ora8_tcpCONTENT_DB_USERNAME tst1CONTENT_DB_PASSWORD 2ZZrBYjUfVw1

For a Microsoft SQL Server database:

CONTENT_DB_RWDBLIB mdmodbcdmt.dllCONTENT_DB_TYPE MSSQLServerCONTENT_DB_SERVER SQLSERVCONTENT_DB_DATABASE "lapaz"CONTENT_DB_USERNAME amigoCONTENT_DB_PASSWORD migas

Sybase 12 Solaris librwctlib_mt.so

Windows 2000 and NT mdscdmt.dll




For a Sybase database on Windows NT:

CONTENT_DB_RWDBLIB mdscdmt.dllCONTENT_DB_TYPE SybaseCONTENT_DB_SERVER REDBUDCONTENT_DB_DATABASE "syb11"CONTENT_DB_USERNAME syberCONTENT_DB_PASSWORD 21,ulgJdU0whTQKz

The Dispatch Service (bob) and Separate Content Databases

If you have one or more separate content databases, you need to configure the Dispatch Service (bob process within the CMS) to access those content databases. This access is necessary to support versioning, various transferproject functions, and staging of content.

NOTE: If the values for the SYSTEM_DB_* variables do not match the values for the CONTENT_DB_* variables, then, by definition, you have a separate content database.

If you have one or more separate content databases, you will need to add the following variables to the CMS configuration information using either the Platform Variable Editor or by editing the cms.cfg file with the admin cfgedit utility. The Dispatch Service (bob) will use the variables to access the content databases.

Database parameter Variable name

The total number of content databases in your VCMS system. The remaining variables will appear once for each content database, iterated by number—the value of n.

PM_CONTENT_DB_NUMBER

The content database name. PM_CONTENT_DBn_DATABASE

Password required for the Dispatch Service (bob) to access the content database for content versioning information.

PM_CONTENT_DBn_PASSWORD

Whether PM_CONTENT_DBn_PASSWORD is encrypted.

PM_CONTENT_DBn_PASSWORD_ENCRYPTED

The RogueWave library used to access the content database.

PM_CONTENT_DBn_RWDBLIB



The CMS maintains multiple instances of these configuration variables for systems that maintain content in multiple databases. Unlike the Page Generators, which you configure to access only one content database at a time, the Dispatch Service can access multiple content databases using the information provided in the PM_CONTENT_* variables. In the variables, the n represents a number that corresponds to the content database being accessed. For example, the following variable-value pairs were created to identify two Oracle content databases on Windows NT:

PM_CONTENT_DB_NUMBER 2PM_CONTENT_DB1_TYPE OraclePM_CONTENT_DB1_SERVER orant_a2PM_CONTENT_DB1_DATABASE ""PM_CONTENT_DB1_SID ORCL11PM_CONTENT_DB1_USERNAME loc_userPM_CONTENT_DB1_PASSWORD 2:1eLHcWPM_CONTENT_DB1_PASSWORD_ENCRYPTED yesPM_CONTENT_DB1_RWDBLIB mdor8dmt.dllPM_CONTENT_DB1_TEXTSIZE 1,000,000PM_CONTENT_DB2_TYPE OraclePM_CONTENT_DB2_SERVER ora1_tcpPM_CONTENT_DB2_DATABASE ""PM_CONTENT_DB2_SID ora1

For Oracle, DB2, and Sybase databases, the database server name for the content database. For Microsoft SQL Server databases, the Data Source Name (DSN).

PM_CONTENT_DBn_SERVER

For Microsoft SQL Server databases, the name of the server for the content database. This variable applies to Microsoft SQL Server databases only.

PM_CONTENT_DBn_SERVERNAME

The system identifier for the database. This variable applies to Oracle databases only.

PM_CONTENT_DBn_SID

The value of the largest binary content retrieved from the content database on a regular basis. This value should match that for the TEXTSIZE variable (set at the /cms/bob node) which has a default value of 1Mb.

PM_CONTENT_DBn_TEXTSIZE

The type of the content database. Can be DB2, or MSSqlServer, Oracle, or Sybase.

PM_CONTENT_DBn_TYPE

The user name used to access the content database. PM_CONTENT_DBn_USERNAME

Database parameter Variable name



PM_CONTENT_DB2_USERNAME broPM_CONTENT_DB2_PASSWORD 2.:oRzdfSL,44ezAPM_CONTENT_DB2_PASSWORD_ENCRYPTED yesPM_CONTENT_DB2_RWDBLIB mdor8dmt.dllPM_CONTENT_DB2_TEXTSIZE 1,000,000

The VCMS software does not create these variables at installation time. You must create them. For information on how to add configuration variables, see the Platform Variable Editor and admin cfgedit chapters of the Configuration Reference.

Handling Legacy Data

When you start using the VCMS software, you may already have content stored in databases. To make that data available to the VCMS software, you have two choices (as explained in Database Content with or without Production Management on page 7-17):

• If you want the VCMS software to manage production for the data, then create a management record for each row of data, and create templates that access and display the database rows.

The Production Center includes Tcl templates to help create the records.

• If you want the VCMS software just to generate Web pages to display the data, then simply create templates that access and display the database rows.

Summary: Describes to make your legacy data available to the VCMS software.

Topics include: • Using the Legacy Record Templates• Modifying the Legacy Save Template for a Nondefault

Database• Creating the Records• Making the Record Content Live



In either case, identify the content database in the templates that generate pages from the rows, if the rows aren’t in the default content database. See Setting Database Variables in Tcl Templates on page 7-19.

NOTE: If your legacy content database is a different type than the VCMS system database (and the VCMS software is installed on Solaris), be sure to add and set the configuration variable for the content database as explained in Content Databases of Different Types on page 7-7.

Using the Legacy Record Templates

The VCMS Tools include Tcl templates to simplify creating records for existing database rows. With the legacy edit template, you specify a database table, primary key, project, and rows to select. The legacy save template creates a record for each row in the table or for each row that meets the selection criteria, and it adds the records to the specified project.

By default, the legacy records save template assumes that the database rows are in the CDS’s default content database (the one identified by the CDS’s CONTENT_DB* configuration variables). If the rows are in a different database or databases, you can modify the legacy save template to create records for those rows.

The next sections explain how to use the legacy templates. If you’re creating records for rows in the default content database, go directly to the Creating the Records section. If you’re creating records for rows in a different database, go first to the Modifying the Legacy Save Template for a Nondefault Database section.

NOTE: The Tcl Page Generator or web server may time out if you process a large number of rows. To avoid this problem, either limit the number of rows processed at one time or temporarily increase the timeout values (set by CTLD_EVAL_TIMEOUT in the CDS’s configuration variables and by the RESET_TIMEOUT command in individual Tcl templates). See the Configuration Reference for more information about the CTLD_EVAL_TIMEOUT variable.



Modifying the Legacy Save Template for a Nondefault Database

To create management records for rows that are not in the CDS’s default content database, you first edit the legacy save template to identify the database where the rows are stored.

■ To edit the legacy save template:

1 Start the VCMS Tools.

2 Open the Project Manager, and open the legacy records save template for editing. It’s in the System project.

3 Save a version of the template, with the File–>Save Version command in the Template Editor. (This step is optional but a good idea.)

4 Near the top of the template, set the variables required to identify the database. For information, see Setting Database Variables in Tcl Templates on page 7-19.

For example, you might set the variables like this:

SET SERVER giantSET DATABASE sybHRSET USERNAME sybuserHRSET vdbmsg(password_encrypted) noSET PASSWORD hrgrp

5 Find this line in the template:

[RECORD UPDATE [FIELD [SHOW primaryKey]] [SHOW table] "" ""[SHOW primaryKey] [SHOW userProject] ""]

6 Add arguments to the RECORD UPDATE command to identify the database server and database:

[RECORD UPDATE [FIELD [SHOW primaryKey]] [SHOW table] [SHOW SERVER][SHOW DATABASE] [SHOW primaryKey] [SHOW userProject] ""]

7 Below the line you modified, find this line:

[RECORD UPDATE [FIELD [SHOW primaryKey]] [SHOW table] "" ""[SHOW primaryKey] [SHOW userProject] [FIELD [SHOW nameKey]]]

8 Add arguments to this RECORD UPDATE command to identify the database server and database:

[RECORD UPDATE [FIELD [SHOW primaryKey]] [SHOW table] [SHOW SERVER] [SHOW DATABASE] [SHOW primaryKey] [SHOW userProject] [FIELD [SHOW nameKey]]]



9 Save your changes and close the template.

Now you can create the records, as explained below.

Creating the Records

■ To create management records for rows in the CDS’s default content database:

1 Start the VCMS Tools, if you haven’t already.

2 If you modified the legacy save template to identify the content database, go on to step 3. Otherwise, select the Preferences command in the launch bar, and choose a CDS whose default content database contains the rows for which you want to create management records.

3 Open the Project Manager, if you haven’t already.

4 If you haven’t already created a project or projects for the records you’re adding, do that now.

5 Preview the legacy records edit template in the System project.

NOTE: You can also access the template directly through the browser, at http://host:port/vgn/legacy/edit.

6 Provide values for these fields:

• Table — Name of the table that contains the content rows.

• Primary Key — Name of the column used as the primary key field in the table.

• Name Column — Name of the column whose values to use as record names in the Production Center. (Optional. If you omit this value, records are named like this: dbServerName:dbName:tableName:dbKey.)

• Project — VCMS project to which you want to add the records.



7 Specify the rows for which you want to create records:

• To select all rows, click the All Rows button (after adjusting the timeout values if necessary).

• To select a subset of rows, enter a SELECT statement that finds the rows you want. You must select the same primary key and name columns that you specified above.

• To select a single row, specify a key and value, or enter a SELECT statement that finds the row you want (and selects the same primary key and name columns that you specified above).

8 Click Submit.

9 Preview or browse the legacy records edit template again to add more rows, if necessary.

NOTE: If you selected All Rows and the template timed out before creating records for all the rows, preview or browse the legacy records edit template again. Enter a SELECT statement that finds the remaining rows.

Making the Record Content Live

In the Production Center, the status of the records you created with the legacy templates is Ready To Launch. You must launch the records to make the content appear on your live site. See the Production Center Guide for information about launching records.


8 Managing VCMS Processes

Summary: How to manage the Vignette® Content Management Server V6 (VCMS) processes using the admin command-line interface, the Start menu options, or the Platform Manager.

Audience: Administrators of the VCMS software

Before you begin: • See Chapter 1, VCMS Software Basic Concepts• See Chapter 4, Viewing VCMS Servers and Processes

Topics include: • Overview• Using the admin Command to Stop and Start Processes• Using the admin Command to Reset the Template Manager• Refreshing Referenced Configuration Variables• Obtaining Process Status—Solaris Only• Checking Page Generator Status• Stopping and Starting a CMS from the Start Menu—Windows

Only• Starting and Stopping with the Platform Manager—Windows

Only


Managing VCMS Processes Administration Guide

OverviewThis chapter discusses stopping and starting the following VCMS components:

• Content Management Server (CMS)• Content Delivery Servers (CDSs)• Observation Management Server (OMS)• Vignette Multi-Channel Communication Server (VMCS)

The most common reason for stopping and starting a component is to force that component’s processes to reread their configuration file. If any information in the configuration file has changed and the component is stopped and started, the process runs with the new values.

You might also need to stop components while you perform database maintenance or other administrative tasks.

The VCMS software provides various ways to stop and start components:

These methods of stopping and starting ensure that the processes for the components are stopped and started in the correct order.

In addition to admin restart, admin stop, and admin start, the VCMS software provides the admin refreshfromdb command to allow administrators:

• To refresh the configuration files from the configuration data stored in the database.

• To refresh the configuration files for referenced configuration variables.

See the Configuration Reference for more information about refreshing configuration files.

On Solaris, administrators can use admin status to obtain the status of a component’s processes. (See admin on page A-5.)

admin command-line utility

(using admin restart or admin stop and admin start)

Available on Windows and Solaris

Start menu option for the CMS component Available on Windows

Platform Manager Available on Windows


Administration Guide Managing VCMS Processes

Using the admin Command to Stop and Start ProcessesThe admin restart or admin start and admin stop commands allow you to stop and start all VCMS processes on the local host or you can start and stop the processes of a particular component or subcomponent. The admin restart, admin start, and admin stop commands are available for the following components and subcomponents:

• CDS

— Application Engine

— Docroot Manager

• CMS

• MCS

• OMS

Run admin restart or admin start and admin stop from the directory where the admin command resides. For example, to stop and then start all VCMS processes on the local host, you would run the admin restart command from one of the following directories:

WINDOWS install-path\inst-name\conf\admin.bat

SOLARIS install-path/vignette/inst-name/conf/admin

To learn where the admin command for each component or subcomponent resides, see:

• admin (CDS) on page A-6• admin (CMS) on page A-8• admin (VMCS) on page A-9• admin (OMS) on page A-10

For Windows, you can also use the Platform Manager to stop or start VCMS processes. See Starting and Stopping with the Platform Manager—Windows Only on page 8-9.



■ To stop or start VCMS processes:

1 Log in to the host where the processes are installed.

On Solaris, to run admin restart, admin start, or admin stop you must be the VCMS administrator (owner of the VCMS files). On Windows 2000 and NT, you must have system admin user privileges on the VCMS host.

2 From a command line, navigate to the directory where the admin command is located.

3 Enter the following command at the prompt:

admin restart

or

admin stop

and then

admin start

For restart: The admin command checks all processes and stops any that are running and then starts the processes in the proper order. The command echoes the progress of the operation to the command line.

For stop:

• Command-line messages provide status on each process as it is stopped and returns when the operation is complete.

• If the VCMS Tools launch bar is running, a warning opens indicating that the CMS is not responding. See the CMS Considerations section for more information.

For start: If the processes are already running, the admin command returns an Already running message to let you know the requested start is not necessary. The command echoes the progress of the operation to the command line.

See also: admin on page A-5



CMS Considerations

When you stop the CMS processes, any content that has been scheduled to launch to your web site will not launch. When the CMS processes are restarted, the launch operations continue.

TIP: Do not stop the CMS if you want an imminent launch to proceed on time.

Additionally, if the VCMS Tools launch bar is running when you stop the CMS processes, a warning opens indicating that the CMS is not responding. Click OK to continue. The launch bar displays Not connected.

When you subsequently start the CMS processes, you can also restart the VCMS Tools, if they’re not already running, and connect to the CMS, if desired. Log in to the CMS from the VCMS Login window.

CDS Considerations

The admin command for the CDS does not stop or start ASP Page Generators (IIS web server instances) or JSP Page Generators.

Using the admin Command to Reset the Template Manager

The Template Manager process on the CDS manages templates and updates the template cache with new or modified templates. You may occasionally want to update the contents of the template cache. You can do so by stopping and starting the process. When the Template Manager starts, it verifies that its template cache contains all new and modified templates.

■ To stop and start the Template Manager:

1 Log in to the host where the Template Manager is installed.

On Solaris, to run admin restart, you must be a member of the VCMS administrators group. On Windows 2000 and NT, you must have system admin user privileges on the VCMS host.

2 From a command line, navigate to the directory where the admin command (for the CDS that contains the Template Manager) is located. For the path descriptions, see admin (CDS) on page A-6.



3 Enter the following command at the prompt:

admin restart configid

where configid is the configuration ID for the Template Manager.

Refreshing Referenced Configuration VariablesAs already mentioned, you can stop and start a component to force that component to reread its configuration file. If any information in the configuration file has changed, the processes run with the new values.

However, the configuration files contain some configuration variables which must be the same for all the processes that use them. This is because some processes reference variables owned by other processes. After you edit the referenced variable for the owner process using the Platform Variable Editor, you run the admin refreshfromdb command to write the new value to the configuration files for the owner and referencing processes.

When you run admin refreshfromdb, the configuration files update their inherited and referenced variables from the database. If a value has changed, they read the new value from the database into their own configuration files. You can run admin refreshfromdb for each component or for all VCMS processes on the local host. See admin refreshfromdb on page A-16 for more information.

CAUTION: The admin refreshfromdb command overwrites configuration file values with their corresponding database values. This is true for all variables except those that have permanent overrides. See the Configuration Reference for more information.

In order for the VCMS processes to read the new value in the configuration file, you must stop and start the appropriate component. When the component is restarted, the processes read the configuration file and run with the new values.



Obtaining Process Status—Solaris OnlyFor Solaris installations, the admin status command allows you to obtain the status for all VCMS processes on the local host or you can obtain the status for the processes of a particular component or subcomponent. It is available for the following components and subcomponents:

• CMS

• CDS

— Application Engine

— Docroot Manager

• MCS

• OMS

Run admin status from the directory where the admin command resides. See:

• admin on page A-5• admin (CDS) on page A-6• admin (CMS) on page A-8• admin (VMCS) on page A-9• admin (OMS) on page A-10

The output displays the configuration path, the ports for the processes, and how long the process has been running. For example:

Configuration path is /opt/vignette/inst-1/conf/cds-blade

cmd [Port:3743] ... Up Since: Tue Aug 14 16:45:29 2001

ctld [Port:3737] ... Up Since: Tue Aug 14 16:45:30 2001



For similar status information on Windows, open the Configuration View from the VCMS Tools launch bar. See Viewing Servers and Processes on page 4-2.



Checking Page Generator StatusYou can confirm that the Page Generators you’ve configured are working properly by browsing to their status pages:

In the previous URLs, host:port indicates the host name and port number for the web server associated with the CDS.

For the Tcl Page Generator, the appearance of the login page verifies the Page Generator is generating pages. You do not need to log in for further verification.

Stopping and Starting a CMS from the Start Menu—Windows Only

You can stop and start CMS processes by using the Windows Start menu options. These menu options run the admin.bat program and handle the processes in the correct order, and are easier to run than the command-line options.

You can use the Start menu options to stop or start all processes on the CMS (from the host that is running the CMS processes).

■ To stop or start a CMS from the Windows Start menu:

1 Open the Start menu and select the following options:

Programs -> Vignette Content Management V6 -> 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 services have stopped or started. The service name shows a blank status field when the service is stopped. For service names, see Appendix A.

Page Generator Status Page URL

ASP http://host:port/vgn/asp/status

JSP http://host:port/vgn/jsp/jspstatus

Tcl (ctld) http://host:port/vgn/login



Starting and Stopping with the Platform Manager—Windows Only

Using the Platform Manager, you can stop and start the processes on the local host for the CMS, CDS, MCS, and OMS components, as well as the Application Engine and Docroot Manager subcomponents.

The Platform Manager is accessible through the Start menu on any Windows machine running the VCMS software.

Programs -> Vignette Content Management V6 -> Platform Manager

■ To stop or start a component using the Platform Manager:

1 Open the Platform Manager.

2 Right-click on a CMS, CDS, OMS, MCS, Application Engine, or Docroot Manager and select Stop or Start. A dialog box displays the progress, and informs you when the operation is complete.

3 You can verify in the Services Control Panel that the processes have been stopped or started. In the Services Control Panel, the service name shows a blank status field when the service is stopped. For service names, see Appendix A.


9 Managing the VCMS Site

Summary: Procedures for various management tasks

Audience: Administrators of the Vignette® Content Management Server V6 (VCMS) site


Topics include: • Accessing the Platform Manager—Windows Only• Loading or Removing a Project Package• Synchronizing a Docroot• Gathering Tcl Template Performance Data

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


Managing the VCMS Site Administration Guide

Accessing the Platform Manager—Windows OnlyThe Platform Manager 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, CDS, VMCS, or OMS host to use the Platform Manager.

On host machines where the VCMS software is installed, the Start menu includes the Platform Manager option.

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

2 Open the Start menu and select the following options:

Programs ->Vignette Content Management V6 -> Platform Manager

3 At the Vignette Configuration dialog, select a CMS configuration option and log in.

The Platform Manager opens in full-screen mode.

With the Platform Manager, you can:

Add or remove a CMS, CDS, OMS, VMCS, or Web Server module

See the VCMS Installation and Configuration Guide (printed copy shipped with product).

View the details and status of the components and their processes

See Chapter 4, Viewing VCMS Servers and Processes. (The same detail and status information that appears in the Platform Manager also appears in the Configuration View tool of the Admin Center.)

Configure an LDAP user repository See Appendix D, Configuring the VCMS Software to Use an LDAP User Repository.

Load or remove a project package See the following section.


Administration Guide Managing the VCMS Site

Loading or Removing a Project PackageThe VCMS software allows you to load and remove project packages created with the transferproject utility. For more information about transferproject and the contents of a project package, see Chapter 12, Transferring Projects and Tables between CMSs.

Depending on your environment, you will load and remove projects differently:

WINDOWS With the Platform Manager.

SOLARIS With the config program.

NOTE: Deleting a project using other available tools is not equivalent to removing the project package with the Platform Manager or config program. Removing the package removes the project content and updates the Template Manager for the CDS, as well as removing project-related templates and static files from the CMS.

The next sections describe loading and removing a project package from a CMS. These procedures apply to any project generated with transferproject.

On Windows, you must have system admin user privileges on the VCMS host to run the Platform Manager. On Solaris, you must be the VCMS administrator (the owner of the VCMS files) to run the config program.

■ To load a Project Package using the Platform Manager—on Windows:

1 Log in to the appropriate CMS.

2 In the Platform Manager, select Tools –> Load Package from the toolbar. The Vignette(R) Content Management Server V6: Load Project Package window opens. You can select a package to load.

3 Select the project package that you want to load from the list, and click Next.



4 Enter the Management ID for the destination project. The package will be loaded into the project you indicate.

The default, /pr/a, indicates the Base Project.

You can determine the Management ID for a project through the Project Manager tool. Simply right-click the project and select Details. The Management ID appears on the Misc tab. For more information, see the Production Center Guide.

5 Click Finish. The VCMS software imports the package contents.

■ To remove a Project Package using the Platform Manager—on Windows:

1 In the Platform Manager, select Tools –> Remove Package from the toolbar. The Vignette(R) Content Management Server V6: Remove Project Package window opens. You can select a package to remove.

2 Select the project package that you want to remove from the list.

3 You must also enter the Management ID for the project you want to remove. Open the Project Manager tool and determine the Management ID for the selected project package. Simply right-click the project and select Details. The Management ID appears on the Misc tab. For more information, see the Production Center Guide.

4 Click Finish. The VCMS software removes the selected project.

■ To load a Project Package using the config program—on Solaris:

1 Navigate to the following directory:

install-path/vignette/6.0/adm/

Type config. The Vignette Content Management Server (VCMS) 6.0 Main Menu opens.

2 Select Configure an existing CMS.

3 Select the CMS you want to load the demonstration package into.

4 Log in to the CMS. You must be a System role user to gain access. The Configure CMS menu opens.

5 Select Add Package. The Project Packages menu opens.

6 Select the project package that you want to load and verify your choice.



7 Enter the Management ID for the destination project and verify your choice. The package will be loaded into the project you indicate.

The default, /pr/a, indicates the Base Project.

You can determine the Management ID for a project through the Project Manager tool. Right-click the project and select Details. The Management ID appears on the Misc tab. For more information, see the Production Center Guide.

8 Verify that you want to commit the configuration. The VCMS software imports the package contents.

■ To remove a Project Package using the config program—on Solaris:





3 Select the CMS you want to remove the demonstration package from.


5 Select Remove Package. The Project Packages menu opens.

6 Select the project package that you want to remove and provide the Management ID.

Open the Project Manager tool to determine the Management ID for the project. Simply right-click the project and select Details. The Management ID appears on the Misc tab. For more information, see the Production Center Guide.

7 Verify your choice.

8 Verify that you want to commit the configuration. The VCMS software removes the project package.



Synchronizing a DocrootUse the Synchronize docroot functionality to restore a docroot that somehow gets corrupted or deleted. If you suspect that a docroot has problems and you synchronize the docroot, the Placement Agent (pad) process determines if the docroot contains the correct version of all static files. If not, the Placement Agent places the correct static files in the docroot.

On Windows 2000 and NT, you must have system admin user privileges on the VCMS host to run the Platform Manager. On Solaris, you must be the VCMS administrator (owner of the VCMS files) to run the config program.

■ To synchronize a docroot using the Platform Manager—on Windows:

1 Log in to the appropriate CMS.

2 In the Platform Manager, select the CDS that contains the web server docroot you want to synchronize.

3 Select Configure –> CDS –> Synchronize docroot. The Vignette(R) Content Management Server V6: Sync the docroot window opens.

4 Click Finish to verify that you want to perform the operation. The VCMS software synchronizes the docroot.

■ To synchronize a docroot using the config program—on Solaris:





3 Select a CMS.


5 Select Configure an existing CDS.

6 Select the CDS that contains the web server docroot you want to synchronize.

7 Select Sync the docroot.

8 Verify that you want to commit the configuration. The VCMS software synchronizes the docroot.



Gathering Tcl Template Performance DataThe Template Measurement Tool (TMT) is a set of templates that can collect Tcl template execution time and page size for every Tcl template execution on a CDS and display the statistics in table form. See VOLSS (the Vignette On-line Support System) for more information about TMT. Knowledge Base Item 2457 discusses the data that TMT reports and explains how to enable and use TMT.


10Working with Web Servers

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

Audience: Administrators of the Vignette® Content Management Server V6 (VCMS) software

Before you begin: • See Chapter 1, VCMS Software Basic Concepts• See Chapter 4, Viewing VCMS Servers and Processes

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 Only


Working with Web Servers Administration Guide

Mapping the Root Path (/) to a Front Door CURLMapping the root documentation path to a particular CURL for your web site’s front door 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 configuration variable, the front door of your web site can take advantage of variations even though the page was not arrived at by a CURL. Whether the web server is Apache, IBM HTTP Server, IIS, or iPlanet, the configuration information for the web server contains a variable you can modify to the CURL you want.

To map the root path to a front door CURL, set the HTTPD_FDCURL configuration variable to the appropriate path. (For information about how to edit configuration variables, see the Platform Variable Editor and admin cfgedit chapters in the Configuration Reference.)

For example, you might set HTTPD_FDCURL to:

/public/FrontDoor/0,1001,,FF.html

which means that requests for www.example.com/ would be re-routed internally to www.example.com/public/FrontDoor/0,1001,,FF.html. For additional information, see the chapter that discusses the creation of customized web pages in the Tcl: Template Cookbook.


Administration Guide Working with Web Servers

Working with Web Server Parsing

The VCMS component templates offer a valuable way to increase your web server performance by taking advantage of the VCMS software’s flexible caching strategy.

The VCMS component templates and the personalization features provided by the Vignette® Relationship Management Server V6 (VRMS) product require server-side parsing in order to work.

However, enabling parsing on your web server does have a slight performance penalty. If your site does not use component templates or personalization, you may want to disable parsing as described here.

NOTE: Don’t disable parsing if your web site uses the VCMS component templates or if it tracks web visitor data using the Relationship Management Server (RMS) component of the Vignette Relationship Management Server product.

The following sections discuss enabling, disabling, and optimizing parsing on iPlanet, IIS, and Apache web servers.

Topics include: • VCMS Software Changes to the obj.conf File on iPlanet• Disabling Parsing on iPlanet• Optimizing the parse-html Function on iPlanet• Parsing on IIS—Windows Only• Parsing on Apache (Solaris Only) or IHS (AIX Only)

See also: • Information on component templates in the chapter on Content Delivery Templates in the Tcl: Template Cookbook

• The COMPONENT command in Tcl: Template Command Reference

• Information on component templates in the chapter on the CDS API in the Java: Vignette Services API Guide

• Information on the Vignette.TemplateContext class and its InsertComponent method in the COM: Vignette Services API Guide and Reference



VCMS Software Changes to the obj.conf File on iPlanet

For iPlanet, the VCMS software relies on the iPlanet parse-html function (server-side includes) to interpret component templates properly. When setting up an iPlanet web server, the VCMS software 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 iPlanet 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/*"

The line above enables content to be submitted and to have server-side parsing included at the same time.

NOTE: If you use the iPlanet Web Server 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 iPlanet

NOTE: Don’t disable parsing if your web site uses the VCMS component templates or if the site tracks web visitor data using the Vignette Relationship Management Server product.

To disable parsing on iPlanet for Windows or Solaris, you modify the web server’s VCMS configuration information and the web server’s obj.conf file as described in the following sections. After you have made the modifications, stop and restart your web server.

Topics include: • Disabling interpretation of COMPONENT results• Disabling server-side includes on iPlanet



Disabling interpretation of COMPONENT results

NOTE: For IIS web servers, see Parsing on IIS—Windows Only on page 10-7.

To disable your iPlanet web server so that it doesn’t interpret COMPONENT command results, use the Platform Variable Editor or the admin cfgedit utility to set the value for the HTTPD_COMPONENTSCAN configuration variable. (For information about how to edit configuration variables, see the Platform Variable Editor and admin cfgedit chapters in the Configuration Reference.)

The variable is set to true by default, indicating that parsing is enabled. To disable parsing, change the value of HTTPD_COMPONENTSCAN to false.

Before parsing is completely disabled, you must also change the iPlanet web server’s obj.conf file.

Disabling server-side includes on iPlanet

■ To disable server-side includes (parse-html) completely, edit the iPlanet 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 CDS that you want to modify are running.

2 Open a command line and navigate to the directory:

WINDOWS ws-install-path\ws-instance\config\

SOLARIS ws-install-path/ws-instance/config/

For example, if you installed the web server in the default location:

WINDOWS cd \Netscape\Server\https-myhost\config

SOLARIS cd /Netscape/Server/https-myhost/config

3 Using your preferred editor, open the obj.conf file for an NSAPI web server configured with the VCMS software. 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 the HTTPD_COMPONENTSCAN configuration variable to false. See Disabling interpretation of COMPONENT results on page 10-5.

TIP: You can also use the iPlanet Web Server 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 iPlanet Web Server 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.

Optimizing the parse-html Function on iPlanet

You can configure iPlanet and the VCMS software to run the parse-html function on only those templates (.html pages) that require it: for example, .shtml pages.

■ To optimize parse-html on iPlanet:

1 Use the iPlanet Web Server 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"

3 Save the changes to the web server’s obj.conf file.

4 From the iPlanet Web Server 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—Windows Only

For IIS web servers, use the Microsoft Management Console to change the properties for the web server instance.

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.

■ To control parsing with the IIS web servers:

1 Log in as a user with system admin user privileges to the host where the web server and CDS that you want to modify are running.

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 if it isn’t already selected. This option allows scripts to be run on the web server.

6 Select Configuration. A list of Application Mappings is displayed.

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\inetsrv\ssinc.dll

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

This change is necessary in order for templates to process form posts. Without the change, you will receive an HTTP error 405.

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

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 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 Active Server Pages (ASP) template is required for an asp component to work. ASP templates must have the .asp extension.

Parsing on Apache (Solaris Only) or IHS (AIX Only)

You can add a handler to the native Apache or IHS 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 should be added at the end of the configuration file. For example:

AddHandler server-parsed .html

NOTE: See your Apache or IBM 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 or IHS web server with the VCMS software, see the VCMS Installation and 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 CDS’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 template command 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 using program tasks, see the 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 that 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 Cache Manager (cmd) using the CMD_ACTION configuration 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 of configuration variables, see the Configuration Reference.

■ To clear pages from a CDS document root:

You can 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 -h host -p port [-H proxy_host] [-P proxy port] path ...

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

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



NOTE: If you are using a proxy server, you cannot use secure authenticated or encrypted connections.

For example, to clear pages from the directory:

WINDOWS \OurSite\Books

SOLARIS /OurSite/Books

In the document root for the web server whose Cache Manager’s port is 13625 on system farley, type one of the following commands:

WINDOWS flushcache farley 13625 \OurSite\Books

SOLARIS flushcache farley 13625 /OurSite/Books

To flush multiple paths with one command:

WINDOWS flushcache farley 13625 \OurSite\Books \OurSite\Magazines

SOLARIS flushcache farley 13625 /OurSite/Books /OurSite/Magazines

3 In the Due pane, schedule the task to occur at any time (in effect, immediately) or specify a date and time and whether to repeat the task.

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 runs when you specified in the program task.

-H proxy_host Optional. If your CDS is outside the firewall and you’re using a proxy server to regulate outbound connections to it, specify the name of the proxy server.

-P proxy port Optional. If your CDS is outside the firewall and you’re using a proxy server to regulate outbound connections to it, specify the port number used for communications with the Cache Manager.

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



Using ASP Scripts in Templates—Windows OnlyMake sure that the first entry in the web server’s list of default file names is set to default.asp so that .asp scripts (Active Server Pages), server-side includes, and other VCMS template programming features are correctly delivered to the user. For more information on setting the default file names, see the VCMS Installation and Configuration Guide (printed copy shipped with product).


11Tuning Your VCMS Installation

Summary: Variable settings that you can modify to increase performance or adjust for different content or products.

Audience: Administrators of the Vignette® Content Management Server V6 (VCMS) installation

Before you begin: • See Chapter 4, Viewing VCMS Servers and Processes• Chapter 6, Managing VCMS Files

Topics include: • Overview• Increasing Tcl Page Generator (ctld) Requests• Adjusting Page Generator Timeouts• Accommodating Large Database Retrievals• Increasing Request Handling• Setting the Thread Pool Size for the Cache Manager• Enabling the Cache Manager to Regenerate Cached Pages• Adjusting the Number of Concurrent Web Server Processes• Restricting Access to the Servers• Enabling VCMS Status Notification


Tuning Your VCMS Installation Administration Guide

OverviewTo tune your VCMS site, you must edit certain variables in the process-specific configuration files where they reside. The Platform Variable Editor and the admin cfgedit chapters of the Configuration Reference explain how to edit these variables.

Remember that in order for changes to the configuration files to take effect, the affected components must be stopped and started. See Chapter 8, Managing VCMS Processes.

If you have multiple CDSs or web server modules, you must be sure to update the variables for each component where you want the new value to be in effect.

Increasing Tcl Page Generator (ctld) RequestsYou can increase Page Generator throughput by increasing the number of requests (slave processes) that the Tcl Page Generator (ctld) allows. Do so by adjusting the value of the POOL_SIZE configuration variable for the ctld process. However, blindly increasing the number is not advised.

Dynamic page generation is a CPU-intensive operation. For this reason, the ctld rarely yields the CPU while it is generating a page. Thus, increasing the number of slave processes far beyond the number of available CPUs does not usually provide the desired results.

The general recommendation for most VCMS installations is to allow 2 slave processes per CPU. For example, if the Application Engine is installed on a machine with 4 CPUs, then the default value of 8 for the POOL_SIZE configuration variable (for the ctld process) is sufficient.

If the Application Engine is installed on a machine with more than 4 CPUs and you want to increase the number of requests that the ctld allows, adjust the value of the POOL_SIZE configuration variable (for the ctld process) accordingly.

For information about the POOL_SIZE configuration variable for the ctld, such as minimum and maximum values, see the Configuration Reference. For information about editing configuration variables, see the Platform Variable Editor and the admin cfgedit chapters in the Configuration Reference.

NOTE: See the Vignette On-line Support System (VOLSS) for more detailed information on this topic.


Administration Guide Tuning Your VCMS Installation

Adjusting Page Generator Timeouts

Setting a time limit for page generation prevents a template with a programming error, such as an infinite loop, from tying up a CDS’s Page Generator.

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 configuration variable. CTLD_EVAL_TIMEOUT sets the default length of time that the Page Generator can take to evaluate a template and produce a page.

• With the VCMS template command, RESET_TIMEOUT. RESET_TIMEOUT resets the timeout value for the template it’s in, overriding the CTLD_EVAL_TIMEOUT configuration variable value. See the Tcl: Template Command Reference.

Use the Platform Variable Editor or the admin cfgedit utility to set the value for CTLD_EVAL_TIMEOUT. (For information about how to edit configuration variables, see the Configuration Reference.)

The default value for CTLD_EVAL_TIMEOUT is 20 seconds. Increase the value to a reasonable length for most templates.

The value of CTLD_EVAL_TIMEOUT must not be larger than the web server module’s HTTPD_TIMEOUT value. If a processes’ timeout value is larger than the timeout value of one of its dependent processes, the dependent processes’ value prevails.

NOTE: Because CTLD_EVAL_TIMEOUT is referenced by the web server module, you will need to stop and start both the CDS and the web server in order for the change to take effect.

See information about variables that reference other variables in the Configuration Reference.

Topics include: • Setting Page Generation Timeouts• Using the RESET_TIMEOUT Template Command



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.

NOTE: Template timeouts have a significant negative impact on system performance because the ctld slave process that times out is destroyed and then re-created. If templates are timing out, you should investigate the cause. The code within your Tcl templates may need debugging or you may have inefficient database queries. To enable the VCMS software to evaluate template performance, set the VGN_TMTENABLE, VGN_TMTPATH, and VGN_TMTSIZE configuration variables. See the Configuration Reference for more information about these variables. See the Vignette On-line Support System (VOLSS) for more information about gathering template performance data.

Using the 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 current template evaluation.

NOTE: Be careful when using RESET_TIMEOUT. Resetting the timeout can potentially tie up resources, since the Page Generator and web server can wait indefinitely (if RESET_TIMEOUT is set to a very high value or included in a loop that never completes, for example).

For a full description of the RESET_TIMEOUT command, see the Tcl: Template Command Reference.

Accommodating Large Database RetrievalsYou can adjust the TEXTSIZE configuration variable to account for large database retrievals. The TEXTSIZE limit applies to Sybase read operations.

NOTE: Consult with your database administrator regarding any constraints Sybase has on handling large binary content. For example, if you 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, use the Platform Variable Editor or the admin cfgedit utility to set the value for the TEXTSIZE configuration variable. (For information about how to edit configuration variables, see the Configuration Reference.)

The default value for TEXTSIZE is 1Mb. Increase the number to accommodate the largest image you regularly request from the database, which is the largest image the CDSs will have to handle. For example, if your templates routinely pull 2Mb images, set the value accordingly.

NOTE: Because this value is used by the bob process and referenced by the vhs, ctld, and tmd processes, you will need to stop and start not only the CMS, but all CDSs in order for the change to take effect. See information about variables that reference other variables in the Configuration Reference.



Increasing Request HandlingThe 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 POOL_SIZE configuration variable for the vhs process. If you modify the POOL_SIZE configuration variable for the vhs process, you should also modify it for the pad process. (See POOL_SIZE in the Configuration Reference.)

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. Do not increase the POOL_SIZE configuration variable for the vhs process unless file submissions occur frequently enough to warrant the change.

To adjust for increased request handling, use the Platform Variable Editor or the admin cfgedit utility to set the value of the POOL_SIZE variable for the vhs process. (For information about how to edit configuration variables, see the Configuration Reference.) The default value of the POOL_SIZE variable for the vhs process is 8.

Setting the Thread Pool Size for the Cache ManagerIf a template is configured to cache its pages, the VCMS software 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 Cache Manager (cmd) maintains the cached pages. The Cache Manager flushes a page from the cache when one of the following occurs:

• The related template is updated.

• The flushcache program task, in the Production Center, flushes the template path. See Clearing Pages from a Root Path on page 10-9.

• The CLEAR_CACHE template command flushes the template path.

• The Cache class, of the Java Vignette Services APIs, flushes the template path. For more information on the Cache class, see Java: Vignette Services API Reference.

The POOL_SIZE variable for the Cache Manager determines how many threads are available to the Cache Manager for flushing the page cache.



Use the Platform Variable Editor or the admin cfgedit utility to set the value of the POOL_SIZE variable for the Cache Manager. (For information about how to edit configuration variables, see the Configuration Reference.)

The default value for the Cache Manager’s POOL_SIZE 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 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.



Enabling the Cache Manager to Regenerate Cached Pages

If particular pages on your site are subject to extremely high demand and regular updates, you have the option of configuring the Cache Manager (cmd) to regenerate cached pages in response to flush requests (from the flushcache program task or the CLEAR_CACHE template command, for example). Doing so ensures that a version of the cached page is always available in the disk cache under the web server document root.

Ordinarily, the Cache Manager simply deletes pages that are to be flushed, relying on subsequent requests to regenerate the page. However, pages that are subject to extremely high demand can take a significant amount of time to generate, resulting in numerous simultaneous requests to generate the page before it is replaced in the document root.

To enable the Cache Manager to regenerate cached pages, the REGENERATE_PAGE configuration variable must be set to True. (This variable is set to True by default when the VCMS software is installed.) Enabling this option allows the Cache Manager to generate certain pages before removing the cached version of those pages.

The REGENERATE_ACCESS_TIME configuration variable determines which pages in the cache should be regenerated by the Cache Manager. If you want the Cache Manager to regenerate only those files that have been accessed within the last five minutes, set the REGENERATE_ACCESS_TIME variable to 300 seconds. (For information about how to edit configuration variables, see the Configuration Reference.)

The default value for the REGENERATE_ACCESS_TIME variable is 60 seconds. Do not set this value too low. Doing so will not have a positive effect on performance. Likewise, if the setting for this variable is too high, the Cache Manager will end up regenerating pages that are seldom accessed, which is not beneficial either.

The Cache Manager regenerates the appropriate cached files by issuing requests to the Page Generator. The Cache Manager forms the requests to the Page Generator by using the Object IDs created when the files were originally generated and cached.



Use the REGENERATE_CONCURRENCY_LIMIT configuration variable to set the number of concurrent requests the Cache Manager is allowed to make to the Page Generator. The default value for this variable is 2. By limiting the number of concurrent requests, you ensure that the Page Generator is not overloaded with requests from the Cache Manager. You can set this value as high as you want, however, for stability and performance, this value should not exceed 25 percent of the total POOL_SIZE for the Page Generator.

If the limit established by the REGENERATE_CONCURRENCY_LIMIT variable is reached, the REGENERATE_CONCURRENCY_WAIT variable determines how long the Cache Manager will wait for the concurrency level to drop below the limit. The default value for the REGENERATE_CONCURRENCY_WAIT variable is 25 seconds. The Cache Manager will attempt to issue the request for the number of seconds indicated, after which the requested page will either be renamed as a backup file or removed from the cache.

NOTE: If the Cache Manager fails to regenerate a page for any reason, that page is either renamed as a backup file or removed from the cache and regenerated when a browser or web server request for it is received. The action taken by the Cache Manager is governed by the CMD_ACTION configuration variable.

NOTE: If a given template directory includes many cached pages, the Cache Manager regenerates the pages serially (per template path), however, the order is indeterminate.

To learn more about the configuration variables discussed in this section and how to edit them, see the Configuration Reference.

Adjusting the Number of Concurrent Web Server Processes

Many web servers also let you adjust the number of processes that the web server will use to serve concurrent requests. 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 among web servers. Consult your web server vendor’s documentation for specific information.



Restricting Access to the ServersBy default, the VCMS services accept connections from any source. You can limit access to the CMS and CDSs by setting their configuration variables 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 VCMS installation.

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 all the machines in the 207.8.8 subnet. Additionally, you can use wildcards, for example an asterisk (*), for any of the components in the IP address.

Use the Platform Variable Editor or the admin cfgedit utility to set the value for ALLOWED_IP_ADDRESSES for the various process. (For information about how to edit configuration variables, see the Configuration Reference.)

You should set this value for every VCMS process that receives external connections:

• bob• cmd• ctld• vrd• mcd• omd• pad• tmd• vhs

NOTE: The ALLOWED_IP_ADDRESSES variable is just one of many variables that the VCMS software provides to enhance security on your site. For a full description of the VCMS security features, see the Security Guide.

See the discussion of the ALLOWED_IP_ADDRESSES variable in the Configuration Reference and in the Security Guide.



Enabling VCMS Status NotificationYou can configure the Observation Management Server (OMS) and the Multi-Channel Communication Server (VMCS) VCMS components to send e-mail notification to specific recipients when one of the processes:

• experiences errors• experiences warnings• is started • is restarted

To enable e-mail notification, you must set the following configuration variables. These variables are set at the /notify/SMTP/PORT node. See the Configuration Reference for more information.

To learn more about the configuration variables discussed in this section and how to edit them, see the Configuration Reference.

HOST The outgoing e-mail host. For example, mailhost.company.com.

PORT The outgoing e-mail port. The default value is 25.

TO Specifies a set of comma-separated addresses for the individuals who should receive notification. This variable defaults to the e-mail address specified during the initial configuration of a CMS.

FROM Specifies a set of comma-separated addresses from which the notification is received. This variable defaults to the e-mail address specified during the initial configuration of a CMS.

NOTIFY_LEVEL Specifies the level of status for which notification e-mail is sent. Possible values include:

• 0 — No notification• 1 — Critical errors• 2 — Serious errors• 3 — Warning (for example, when a process is restarted)• 4 — Debug (for example, when a process is started)

The default value for this variable is 0.


12Transferring Projects and Tables between CMSs

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


Before you begin: See Chapter 7, Managing System and Content Databases

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

See also: • transferproject on page A-40


Transferring Projects and Tables between CMSs Administration Guide

OverviewIf your company has multiple VCMS CMSs, you may need at times to transfer—copy—a project from one CMS to another. You can also use transferproject to move single content items (or sets of content items) between projects. Some possible reasons to use transferproject:

• 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

• To move one or more content items (files, records, or templates) from one CMS to another

The VCMS transferproject utility, which you run 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. The transferproject utility also enables you to transfer database content for a project.

NOTE: If you plan to run transferproject outside of the Vignette install tree, you must set the VGN_HOME system environment variable to the root of your VCMS installation. For example, if you install on Solaris and your VCMS installation is at install-path/vignette/6.0/, then the VGN_HOME environment variable must point to the directory one level above the 6.0 directory, which is install-path/vignette.


Administration Guide Transferring Projects and Tables between CMSs

Requirements, Assumptions, and RestrictionsSome conditions for transferring projects:

• The CMSs between which you transfer projects must both be running StoryServer 4.1 or a later version of the Vignette software..

NOTE: The 6.0 version of transferproject will only work against 6.0 versions of the CMS. To transfer between a 4.x (or 5.x) CMS and a 6.0 CMS, use the 4.x (or 5.x) version of transferproject for the export and the 6.0 version of transferproject for the import.

• 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 CDSs configured for the CMS must be also running.

• The transferproject utility transfers VCMS project data and database content between VCMS system databases. In general, the content to be transferred must be stored in the VCMS’s system database, not in a separate content database. However, the -R option allows for transfer to and from non-VCMS databases. See The -r option versus the -R option on page 12-22.

• You must have the appropriate VCMS authorization. Authorized users for a project can import content to that project. If the imported content includes templates, the user must also have the System or Developer role. For specific authorizations, see the VCMS Authorizations section. See also Roles Authorization on page 5-5.

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

• The transferproject utility provides a way for you to transfer projects, including database content, between CMSs. 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 12-32.

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



• 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 accidentally deleting projects, templates, records, files, and tables.

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

• 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 automatically transfer all project and content properties. By setting options for transferproject, you can partially determine what is transferred and what is not. See What Is Transferred and What Isn’t on page 12-33.

• By default, 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 Automatically launch content as soon as workflow completes autolaunch attribute set.

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

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.

• With the -e option, you can force all transferred content to begin at the top of the workflow specified on the destination CMS. See transferproject on page A-40.

• Unless the -i option is set, template IDs are automatically reset when transferred to 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 Using the –i Option on page 12-26 and Things to Do after Transferring on page 12-32.



How to Transfer Projects

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

Different operations of the transferproject utility handle 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, you can see the project appear in the Project Manager’s project listing.

• By default, a project is transferred with all its records, files, and templates, as well as its subprojects, their records, files, templates, and so on.

• You can transfer the VCMS project data and the database content independently.

Topics include: • Exporting and Importing Projects• Typical Transfers• VCMS Project Data and Database Content• Project Package

export Exports project data

export (-r|-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



• You can transfer projects regardless of operating system and VCMS 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 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. The same holds true when transferring subsets of projects, for example, individual content items.

NOTE: Whether transferring whole projects or subsets of projects, by default the management IDs of content items will be reset to new values on the destination CMS. With the -z option (2 or 3), transferproject will overwrite conflicting content with the management IDs of the source content. Otherwise, the VCMS software generates new management IDs for the imported content. See a description of the -z options for transferproject on page A-40.

• When you import a project that contains file content items, the destination CDSs must be running. If the CDSs are not running, the project information will be imported, but the file content will not.

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 12-1, the project specified for export is Archery. The project package includes the VCMS 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 12-1: Transferring a project to the Base Project

from sourceCMS

projectpackage

to destinationCMS



In Figure 12-2, the project specified for export is Templates, a subproject of the Archery project. The project package includes the VCMS 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 12-2: Transferring a project to a lower level in the hierarchy

from sourceCMS

projectpackage

to destinationCMS



Figure 12-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 12-3: Project contents

project on destination CMS

project on source CMS

projectpackage



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

■ To transfer a project:

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

2 Using transferproject’s export operation, export the VCMS project data for the project from the source CMS. The project data includes the project hierarchy and all VCMS metadata, records, templates, files, and keywords, but not tasks, authorizations, notes, and so on. See What Is Transferred and What Isn’t on page 12-33.

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.

3 Using 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 automatic launch if you don’t want the transferred content items to go Live immediately. See transferproject on page A-40.

5 Import the database content to the destination CMS using 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 run the command again.

To force the operation to continue despite errors, you can use the -k option. See Using the –k Option on page 12-27.

7 Import the VCMS project data to the destination CMS using 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 run the command again.

See transferproject on page A-40.

9 After completing the transfers, make any required changes for the project on the destination CMS.

VCMS Project Data and Database Content

transferproject distinguishes projects conceptually into two parts:

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

• Database content. The database content consists of rows in content tables in the VCMS database. The rows may or may not correspond to records.



When you transfer a project, you may or may not need to transfer both VCMS project data and database content. For example, suppose the content tables are stored in a separate content database, not in the VCMS 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 destination CMS, you can transfer the database content with transferproject—or with a database tool, such as Sybase’s bcp.

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—using the VCMS Production Center.) In that case, there’s no need to transfer content tables, so you would transfer only the VCMS 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 VCMS system database. No entries are made in the destination next_id table for database tables transferred without VCMS templates that reference them.

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 VCMS 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 VCMS 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 or exportData 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/vignxfer, the directory will contain this set of files:

vignxfer.attr(vignxfer.tar) or (vignxfer.zip and vignxfer.exe)vignxfer.datavignxfer.purgevignxfer.sch.db2vignxfer.sch.mssvignxfer.sch.oravignxfer.sch.syb

Two of the files contain the VCMS project data:

• The .attr file contains the 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.

• 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, Microsoft SQL Server, DB2, 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 exportData operation creates a project package that contains only the files related to database content.

For more information, see Contents of Project Package on page 12-41.

transferproject SyntaxThe transferproject command resides in the VCMS operating-system directory below the bin directory. The default locations:

• SOLARIS

install-path/vignette/6.0/bin/solaris/

• WINDOWS

install-path\6.0\bin\winnt\

NOTE: Run the transferproject command from the bin/solaris directory or the bin\winnt directory.

The following usage statement shows the transferproject syntax. For detailed information about each option, see transferproject on page A-40.

transferproject -b CMShost:CMSport:projectid -o { export [-f file-format] [-r | -R] [-t content item-list | list file] [-n version-name] import [-s | -e] [-F] [-i] [-m ID map file] [-E character encoding][-z conflict-option] [-n version-name] [-u] [-T] delete exportData -t table-list importData [-k] deleteData [-k] -p package-directory [-w adminutil.cfg-path] [-l user:password] [-v] [-?]



You specify the operation that transferproject performs—export the VCMS project data, export the database content, import the VCMS project data, and so on—with the -o operation option, where operation can be export, import, delete, exportData, importData, or deleteData.

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

delete — delete project data

transferproject -o delete -b destCMShost:destCMSport:projID -l user:password [-v]

deleteData — delete database content

transferproject -o deleteData [-k] -b destCMShost:destCMSport -p package-directory -l user:password [-v]

export — export project data

transferproject -o export -b sourceCMShost:sourceCMSport:projID -p package-directory -l user:password [-t content item-list] [-f file-format] [ -n version-name ] [-v]

export -r — export project data and database content

transferproject -o export (-r|-R) -b sourceCMShost:sourceCMSport:projID -p package-directory -l user:password [-t content item-list | list file] [-f file-format] [-n version-name] [-v]

exportData — export database content

transferproject -o exportData -b sourceCMShost:sourceCMSport -p package-directory -l user:password -t "table-list" [-v]

import — import project data

transferproject -o import [-s] [-i] [-z option [ -n version-name ]] -p package-directory -b destCMShost:destCMSport:projID -l user:password [-v][-m ID map file] [-E character encoding]

importData — import database content

transferproject -o importData [-k] -b destCMShost:destCMSport -p package-directory -l user:password [-v]

none — display a usage statement

transferproject -?



Transferring Projects

transferproject Permissions and Other Requirements

The general requirements for using the transferproject command:

• For export operations, you must have a VCMS 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 VCMS user ID on the CMS to which the project is imported, and you must have read and write permissions for the project package directory. To import VCMS project data, you must also have the appropriate VCMS authorization. See VCMS Authorizations on page 12-38.

• For delete operations, you must have a VCMS user ID on the CMS to which the project is imported, and you must have read permission for the project package directory. To delete VCMS project data, you must also have the appropriate VCMS authorization. See VCMS Authorizations on page 12-38.

• On Solaris, the appropriate environment variables must be set. See Setting Environment Variables on Solaris on page 12-17.

Topics include: • transferproject Permissions and Other Requirements• Setting Environment Variables on Solaris• Import Conflicts• Finding Project IDs• Exporting Project Data• Exporting VCMS Project Data and Database Content

Together• Importing VCMS Project Data• Exporting Database Content• Importing Database Content• Deleting Project Data• Deleting Database Content• Moving a Project Package



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:

• ORACLE_HOME, DB2_DIR, or SYBASE — Database-specific identifier. Set this environment variable before using the exportData, importData, or deleteData operation.

• LD_LIBRARY_PATH — Depending on the type of database being used at your site, the LD_LIBRARY_PATH variable should be set to one of the following:

Oracle 8:

install-path/vignette/6.0/lib/solaris:$ORACLE_HOME/lib

Sybase 12.0:

install-path/vignette/6.0/lib/solaris:$SYBASE/OCS-12_0

DB2 7.1:

install-path/vignette/6.0/lib/solaris:$DB2_DIR

NOTE: If you use DB2, it sets the LD_LIBRARY_PATH variable to the appropriate value during installation. If you changed this the value of this variable, be sure to reset it to the paths indicated.

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

Set the variable to the path of the database client installation, as explained in the database client documentation.

If the database variable isn’t set, transferproject will report that the connection to the database failed, and a message from the database server should report the reason for the failure.

If LD_LIBRARY_PATH isn’t set when you run one of the transferproject operations that requires it, the transfer will fail. transferproject will report something like this:

[DBNOTFOUND] No access library ...



Import Conflicts

Before importing a project, transferproject’s import operation checks for conflicts between the project data and the VCMS 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-40.

A conflict occurs when one of the following items, which must be unique on a CMS, is the same on the destination CMS and in the project to be imported:

• Template name

• Template path

• Template ID (only if the -i option has been specified with the import operation. See Using the –i Option on page 12-26.)

• 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 and reports them, rather than exiting as soon as it finds the first conflict, so you can fix all conflicts at once and then execute transferproject again.

NOTE: The transferproject command also ensures that a file and template object do not have the same path (because both are launched to the web server docroot). Such a conflict causes an error that must be resolved before any objects can be transferred.



transferproject treats project names differently from template names, template paths, template IDs, file path names, and record definitions. The VCMS software 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, template IDs, file path names, and record definitions still apply: unless you specify one of the options available with -z, the transfer will fail if there are conflicts on the destination CMS.

NOTE: Template IDs are normally reset to new values on the destination CMS. However, transferproject will maintain the template IDs if the -i option is specified with the import operation. If the -z option is also specified, transferproject will respond to conflicts between template IDs. See Using the –i Option on page 12-26.

Finding Project IDs

When you export a project’s VCMS project data, you must know the VCMS 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 also need its ID.

■ To find project IDs:

1 From the VCMS 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 tab. 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:



NOTE: 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. Specify a forward slash (/) as the project ID if you want transferproject to ignore the name of the top-level project in the imported package and place the project contents into the Base Project. All subprojects in the imported package will be owned by the Base Project upon import.

Exporting Project Data

To export a project’s project data (without its database content), enter this command at the command line:

transferproject -o export -b sourceCMShost:sourceCMSport:projID -p projPackageDir -l user:password [-f file-format] [-v]

If you do not use the -f argument on Windows, 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, or zip on Solaris. See transferproject on page A-40 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 example 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/xfer. The package includes VCMS project data for project /pr/34 and all its subprojects, if it has any.

transferproject -o export -b sorcerer:62120:/pr/34 -p /opt/xfer -l swalker:hi11top

The following example 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



As a last example, the following command uses the -t option to export a subset of content—in this case, two records with management IDs /ci/43 and /ci/3a, which are enclosed in double quotations and delimited by a space.

transferproject -o export -p /film -l pjames:m1stry7 -v -b juno:13666:/pr/82 -t "/ci/43 /ci/3a"

NOTE: Although content item management IDs must be specified explicitly with the -t option at export, they will be set to new values on the destination CMS at import. Also, the management IDs specified with the -t option must exist under the specified project hierarchy. If not, transferpoject lists the IDs not found and returns an error.

Exporting VCMS Project Data and Database Content Together

To export a project’s project data and its database content, you can specify the -r option or the -R option when you run transferproject’s export operation.

These options are designed for simple transfers, that is, transfers in which the project has a set of database content and each content row has a corresponding Production Center record.

If you use the -r and -R options for 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 or -R is a more efficient choice than a separate exportData operation.

If you want to export entire tables, regardless of whether rows correspond to project records, use the exportData operation instead of the -r or -R option. (See Exporting Database Content on page 12-25.)

To export a project’s data and database content, enter this command at the command line:

transferproject -r -o export -b sourceCMShost:sourceCMSport:projID -p projPackageDir -l user:password [-f file-format] [-v]

See transferproject on page A-40 for argument descriptions.



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 project data and the database content separately.

The following example exports the project with management ID /pr/22, on the CMS host sable and CMS port 37500, including both the project’s 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

The -r option versus the -R option

• -r

With transferproject -o export, the -r option exports both project data and database content into one project package. The project data is exported into the .attr file and to a .zip or .tar file. The database content is exported into the .data, .purge, and .sch files. See Contents of Project Package on page 12-41.

At import, you must run import and importData. The import option pulls the project data from the .attr file and from the .zip or .tar file; the importData option pulls the database content from the .data file and from the appropriate .sch file.

• -R

With transferproject -o export, the -R option also exports both project data and database content into one project package. However, with -R, both are stored in the .attr file.

At import, you only need to run transferproject -o import to complete the transfer. The import option pulls database content from the .attr file.

Because content data is stored directly with the project data in the .attr file, transferproject can determine whether to do SQL updates (for new records) or inserts (for existing records) on the destination CMS database.



If you have specified export -R, you will want to specify import -z # to allow transferproject to manage conflicts by inserting or updating records as appropriate. (Replace # with 0, 1, 2, 3, or 4.) For the options available with -z, see transferproject on page A-40.

Importing VCMS 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 workflow 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 12-39.

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. You can also affect workflow for transferred items with the -e option. See Using the –s and –e Options to alter content status and workflow on page 12-40.

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 Project Data on page 12-29, or use the -z option to specify how to handle import problems. See transferproject on page A-40.

• If you want to add the contents of the imported project to the destination project, import the project.

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

• If you want to preserve the template IDs of templates on the source CMS upon import to the destination CMS, specify the -i option. See Using the –i Option on page 12-26.



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

4 Enter this command at the command line:

transferproject -o import -p projPackageDir [-i] [-v] -b destCMShost:destCMSport:projID -l user:password

where projID is the management ID of the project that will be the parent of the project you’re importing. See transferproject on page A-40 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 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. Specify a forward slash (/) as the project ID if you want transferproject to ignore the name of the top-level project in the imported package and place the project contents into the Base Project. All subprojects in the imported package will be owned by the Base Project upon import.

The following example imports a project from the project package directory /apps/xfer 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/xfer -l pgranger:784wingtips

NOTE: The management IDs of all transferred content are set to new values on the destination CMS at import–this is true even if you specify the -t option. Although management IDs must be specified explicitly at export with -t, they will be reset at import.



Exporting Database Content

To export database tables to a project package, enter this command at the command line:

transferproject -o exportData -b sourceCMShost:sourceCMSport -p projPackageDir -l user:password -t "table-list" [-v]

where 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 table. See transferproject on page A-40 for other argument descriptions.

The following example 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/xfer.

transferproject -o exportData -b sorcerer:62120 -p /opt/xfer -t "Auditnos Audithist" -l swalker:hilltop

Importing Database Content

The importData operation imports database content from a project package created 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 12-30.

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

3 Enter this command at the command line:

transferproject -o importData [-k] -b destCMShost:destCMSport -p projPackageDir -l user:password [-v]

The -k option tells transferproject to continue even if an error occurs while it’s processing the schema file. See Using the –k Option on page 12-27. For other argument descriptions, see transferproject on page A-40.



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

The following example imports the project package that’s in the directory /apps/xfer.transferproject and creates the transferred tables in the database used by the CMS at delrio:36550.

transferproject -o importData -b delrio:36550 -p /apps/xfer -l Admin:axTR89

Using the –i Option

Template IDs are normally reset to new values when transferred to the destination CMS. However, transferproject will maintain the template IDs if the -i option is specified with the import operation.

This option should be used with caution because it can create two complications:

1 Any conflicts between template IDs from the source CMS and existing template IDs on the destination CMS will cause the transfer to stop. You can use -z option 4 to check in advance for potential conflicts.

2 The next_id table generates template IDs as new templates are created. With the -i option, you may import templates with template IDs greater than the current value of the next_id table. This may cause errors when the VCMS software is asked to create a new template: the next_id table may generate an ID value that is already assigned to one of the imported templates.

After transferring, you may want to set the next available ID in the next_id table to a number greater than the largest imported template ID.



Using the –k Option

The importData operation runs 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 VCMS 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 VCMS 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 VCMS 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 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

If you are transferring content between databases of different types, conflicts between the two databases’ schema restrictions may prevent database content from being imported. See both database vendors’ documentation and compare their schema restrictions for possible conflicts. Following are some examples of schema restriction conflicts that can cause errors with transferproject -o importData:

• Datatypes — Oracle has a limit of one LONG or LONGRAW datatype per table. However, DB2, Sybase, and Microsoft SQLServer allow multiple unbounded text types in a single table. Both DB2 and Oracle allow multiple BLOB and CLOB datatypes.

Various databases have different 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." DB2 and Oracle treat these names as uppercase. If the source database is Sybase or MS SQLServer and the destination database is DB2 or Oracle, neither DB2 or Oracle will allow the transfer, because it would result in two columns named “EMPPHONE.”

• Column sizes — Sybase allows a variable character column to be defined with a maximum of 255 characters. Oracle variable character columns can have a maximum of 4000 characters. Microsoft SQL Server allows up to 8000 characters in a variable-length character column. DB2 allows a maximum length for its VARCHAR type of 32672 bytes and its LONG VARCHAR type of 32700 bytes.



Deleting Project Data

You delete a project’s data with transferproject’s delete operation. The 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 VCMS users may have added.

To delete a project’s data (all its contents, including its subprojects and all their contents), enter this command at the command line:

transferproject -o delete -b destCMShost:destCMSport:projID -l user:password [-v]

The following command deletes the 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 VCMS 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 12-41.) Before executing deleteData, make sure that the tables can be dropped. Back them up if necessary.

To delete a project’s database content, enter this command at the command line:

transferproject -o deleteData [-k] -b destCMShost:destCMSport -p projPackageDir -l user:password [-v]

where projPackageDir is 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 Using the –k Option on page 12-27.

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.

■ To move the project package:

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/vign/transfers, create a directory named transfers on the destination machine (for example, /fs6/vign/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 project data, must be treated like a binary file. When moving a project package from Solaris to Windows, use binary mode. Otherwise, the .attr file will be invalid on Windows.



Things to Do after TransferringSome things to check and do after importing a project:

• Adjust project properties as needed (for example, owners, users, attributes, workflow, and 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.

This change is necessary because template IDs are automatically reset on the destination CMS. To override this reset behavior, you can specify the -i option at import. See Using the –i Option on page 12-26.

• If you transfer tables without the templates that reference those tables (via the primary database table attribute), you will need to manually create an entry in the next_id table if you want to use the GET_NEXT_ID template command on that table.

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, then enter 301 in the id column. If for some reason you import an empty table, set the next available ID to 1.

• If you transferred templates using the -i option, you may want to set the next available ID in the next_id table to a number greater than the largest imported template ID. See Using the –i Option on page 12-26.

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

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.



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

The following table shows which template properties transferproject transfers.

versions no No

See transferproject on page A-40 for information about the -n option.

notes no No

tasks no No

subprojects yes

templates yes

files yes

records yes

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

Template property Transferred? Inherited or replaced?

name yes

cache setting yes

body yes

internal-use-only setting yes

paths yes

primary table yes

file extension yes

category yes

Project property Transferred? Inherited or replaced?



template ID no Replaced with new one (unless the -i option is specified with the import operation.) See Using the –i Option on page 12-26.

management ID no Replaced with new one

workflow no No


See Using the –s and –e Options to alter content status and workflow on page 12-40.

status yes/no • Launchable template: if was Live, becomes Live.

NOTE: If a Live template replaces a Live template on the target CMS and the templates are the same, it stays Live. However, if a Live template replaces a Live template on the target CMS and the templates are different the template goes to Working status.

• Internal use only template: always becomes Ready For Internal Use.


Use -e or -s to alter the default behavior. See Using the –s and –e Options to alter content status and workflow on page 12-40

history no No

versions no No





The following table shows which record properties transferproject transfers.

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

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 or -e option).



history no No




The following table shows which file properties transferproject transfers.

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



status yes/no If was Live, becomes Live (unless you use the -s or -e option.



history no No

Record property Transferred? Inherited or replaced?



General Information about Transferring Projects

VCMS Authorizations

The following table shows the required VCMS authorizations for transferproject operations. Members of the System role are authorized for all operations.

NOTE: For database interactions, transferproject assumes the database permissions of the VCMS database user.

versions no No


notes no No

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

Operation VCMS 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 the System role)

deleteData Any VCMS user of the destination CMS

export Any VCMS user of the source CMS

exportData Any VCMS user of the source CMS

import Owner of the parent project on the destination CMS

importData Any VCMS user of the destination CMS

File Property Transferred? Inherited or Replaced?



NOTE: Any time that templates are imported into a project, the user needs to be assigned either the Developer or System role.

Parent Project and Status of Imported Content Items

When you import templates, records, and files into a project, the VCMS software doesn’t transfer their workflows. 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.

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)

NOTE: If a Live template replaces a Live template on the target CMS and the templates are the same, it stays Live. However, if a Live template replaces a Live template on the target CMS and the templates are different, the template goes to Working status.

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



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.

The autolaunch attribute is set on the General page of the project’s Details window: Automatically launch content as soon as workflow completes.

Using the –s and –e Options to alter content status and workflow

The -s and -e options alter the default behavior for content status and content workflow when the content is imported.

With the -s option, any content with a status Live on the source CMS is given the status Ready to Launch on the destination CMS.

With the -e option, transferred content items inherit workflow from the project into which they are imported. In effect, a content item imported with -e is treated like a content item newly added to the project: it inherits the same workflow that an asset of its type (template, record, or file) would be assigned if it were added through the Production Center.

This option is especially useful in staging environments.

NOTE: The -e option and the -s option are mutually exclusive. If both are specified, -e takes precedence.



Contents of Project Package

With an export option, transferproject creates a project package that contains several files with different extensions:

package-directory-name.attr package-directory-name.file-formatpackage-directory-name.datapackage-directory-name.purgepackage-directory-name.sch.sybpackage-directory-name.sch.msspackage-directory-name.sch.orapackage-directory-name.sch.db2

Two files contain the VCMS 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, 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, or zip on Solaris.

The .attr file must be treated like a binary file. When moving a project package from Solaris to Windows, use binary mode. Otherwise, the .attr file will be invalid on Windows.

This table shows the meaning of each file by extension.

Extension Operation Description

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

When the -R option is specified, the .attr file also includes database content corresponding to the project data. See The -r option versus the -R option on page 12-22.

.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, this is the default format.

.data exportDataexport -rexport

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



Deleting the dist Directory

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.

.purge exportDataexport -rexport

Contains information for removing the tables specified with exportData or export -r. 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.

.sch.db2 exportDataexport -rexport

Contains create table functions in DB2 format for installing the tables specified with exportData. Empty if export is specified without -r.

Extension Operation Description


A VCMS Process Reference

Summary: A quick reference for processes followed by detailed information for each.


Before you begin: See Chapter 8, Managing VCMS Processes

Topics include: • Process Reference Overview

• admin• admin (CDS)• admin (CMS)• admin (VMCS)• admin (OMS)• admin cfgedit• admin chlog• admin refreshfromdb• bob• campadmin• cgutil• cld• cmd• config• ctld• encrypt• expire

• flushcache• gencert• inboundmail• launch• mcd• omd• pad• pzndelete• reseteur• sgutil• ted• tmd• transferproject• version• vhs• vwd• wscfg

August 2001 Vignette Confidential A-1

VCMS Process Reference Administration Guide

Process Reference OverviewThis appendix contains information on VCMS processes and commands.

NOTE: Information about the VCMS files can be found in Appendix B, VCMS File Reference.

NOTE: If you plan to run any of the VCMS program tasks or commands outside of the Vignette install tree, you must set the VGN_HOME system environment variable to the root of your VCMS installation. For example, if you install on Solaris and your VCMS software installation is at install-path/vignette/6.0/, then the VGN_HOME environment variable must point to the directory one level above the 6.0 directory, which is install-path/vignette.

Process Type Description

admin Command-line utility Stops, starts, or checks status for all VCMS components on the local host

admin (CDS) Command-line utility Stops, starts, or checks status for the CDS, CMS, VMCS, or OMS processes.See also admin cfgedit and admin refreshfromdb.

admin (CMS)

admin (VMCS)

admin (OMS)

admin cfgedit Command-line utility Sets and changes configuration variables. See also the Configuration Reference.

admin chlog Command-line utility Changes the log level setting for components and their processes.

admin refreshfromdb Command-line utility Refreshes configuration file variable values with values from the system database

bob CMS process Dispatch Service

campadmin Program task Used with the Vignette Relationship Management Server (VRMS). Checks for broken campaigns. See also the Business Center Guide.

A-2 Vignette Confidential August 2001

Administration Guide VCMS Process Reference

cgutil Command-line utility Used with the Vignette Relationship Management Server (VRMS). Imports content groups. See also the Business Center Guide.

cld OMS process Campaign Logging Agent

cm WINDOWScmd SOLARIS

CDS process Cache Manager

config Interactive program Configures VCMS components

ctld CDS process Tcl Page Generator

encrypt Command-line utility Creates encrypted strings

expire Program task Expires records, files, or templates

flushcache Program task Clears cached pages from a specified location

gencert Command-line utility Generates keys and certificate requests. See also the Security Guide.

inboundmail Program task Converts e-mail data into multi-part form data and issues a post to a URL

launch Program task Launches records, files, and templates

mcd VMCS process Multi-Channel Delivery Agent

omd OMS process Observation Manager

pad CDS process Placement Agent

pzndelete Program task Removes visitor information from the visitor records database.

reseteur Program task Clears the user and group cache of the EUR (external user repository).

sgutil Program task Used with the Vignette Relationship Management Server (VRMS). Retrieves segments and their populations from a netCustomer web server. See the Business Center Guide.

ted CMS process Event Service




NOTE: For information on file location variables, see Common Path Name Variables on page 1-5.

tmd CDS process Template Manager

transferproject Command-line utility Transfers project info from one CMS to another

version Program task Creates, names, restores, or deletes versions of files, records, or templates

vhs CMS process Request Service

vrd OMS process Router

vwd OMS and VMCS process Watchdog

wscfg AIX Command-line utility Associates or disassociates a web server on a dissimilar host with a CDS on a standard host in a heterogeneous configuration.




adminStops, starts, or (on Solaris) checks status for all VCMS processes on the local host.

Location

Windows

install-path\inst-name\conf\admin [restart | start | stop]

Solaris

install-path/vignette/inst-name/conf/admin [restart | start | stop | status]

Description

The admin command-line utility lets you start and stop all VCMS processes on the local host.

On Windows 2000 and NT, you must have system admin user privileges on the host where the processes are installed to use the admin command. On Solaris, you must be the VCMS administrator (owner of the VCMS files) to run the restart, start, and stop subcommands. To run the status subcommand, you must be a member of the VCMS administrators group.

NOTE: You can also run admin refreshfromdb for all VCMS processes on the local host. See admin refreshfromdb on page A-16 for more information.

Subcommands

restart

Stops the running processes for all components and then starts the processes.

start

Starts the VCMS processes. If the VCMS processes are already running, the start subcommand returns an Already running message to let you know the requested start is not necessary.



status SOLARIS

Returns status on all VCMS processes.

stop

Stops all VCMS processes.

admin (CDS)Stops, starts, or (on Solaris) checks status for CDS processes.

Location

Windows

install-path\inst-name\conf\cds-name\admin [restart | start | stop][ape-n | cfgid | dm]

Solaris

install-path/vignette/inst-name/conf/cds-name/admin [restart |start | stop | status] [ape-n | cfgid | dm]

Description

The CDS admin command-line utility lets you start and stop all VCMS processes associated with a CDS (cds-name).

On Windows 2000 and NT, you must have system admin user privileges on the host where the CDS is installed to use the start and stop subcommands. On Solaris, you must be the VCMS administrator (owner of the VCMS files) to run the start and stop subcommands. To run the status subcommand, you must be a member of the VCMS administrators group.



Subcommands

restart

Stops the running processes in the CDS and then starts the processes.

start

Starts the CDS processes. If the CDS processes are already running, the start subcommand returns an Already running message to let you know the requested start is not necessary.

status SOLARIS

Returns status on all CDS processes.

stop

Stops all CDS processes.

Options

ape-n

To stop, start, or check the status of a specific ape (Application Engine), specify the name of that ape (for example, ape-1) after the restart, start, status, or stop subcommand. Doing so starts, stops, or provides status for the tmd (Template Manager) and any ctld (Tcl Page Generators) that the Application Engine contains, but not ASP Page Generators (IIS web server instances) or JSP Page Generators.

cfgid

To stop, start, or check the status of a specific CDS process, specify the configuration ID of that process after the restart, start, status, or stop subcommand. The VCMS verifies that the provided configuration ID exists in the manifest file on the local host. (See manifest on page B-27.)

dm

To stop, start, or check the status of the dm (Docroot Manager) for a specific CDS, specify dm after the restart, start, status, or stop subcommand. Doing so starts, stops, or provides status for the cmd (Cache Manager) and pad (Placement Agent) that the Docroot Manager contains.



admin (CMS)

Stops, starts, or (on Solaris) checks status for CMS processes.

Location

Windows

install-path\inst-name\conf\cms\admin [restart | start | stop]

Solaris

install-path/vignette/inst-name/conf/cms/admin [restart | start | stop | status]

Description

The CMS admin command-line utility lets you start and stop CMS processes.

On Windows 2000 and NT, you must have system admin user privileges on the host where the CMS is installed to use the restart, start, and stop subcommands. On Solaris, you must be the VCMS administrator (owner of the VCMS files) to run the restart, start, and stop subcommands. To run the status subcommand, you must be a member of the VCMS administrators group.

Subcommands

restart

Stops the running processes in the CMS and then starts the processes.

start

Starts the CMS processes. If the CMS processes are already running, the start subcommand returns an Already running message to let you know the requested start is not necessary.



status SOLARIS

Returns status on all processes of the CMS.

stop

Stops all processes in the CMS.

admin (VMCS)Stops, starts, or (on Solaris) checks status for Vignette® Multi-Channel Communication Server V6 (VMCS) processes.

Location

Windows

install-path\inst-name\conf\mcs-name\admin [restart | start | stop]

Solaris

install-path/vignette/inst-name/conf/mcs-name/admin [restart | start |stop | status]

Description

The VMCS admin command-line utility lets you start and stop (and obtain status on Solaris) for the VMCS processes.

On Windows 2000 and NT, you must have system admin user privileges on the host where the VMCS product is installed to use the restart, start, and stop subcommands. On Solaris, you must be the VCMS administrator (owner of the VCMS files) to run the restart, start, and stop subcommands. To run the status subcommand, you must be a member of the VCMS administrators group.



Subcommands

restart

Stops the running processes in the VMCS and then starts the processes.

start

Starts the VMCS processes. If the VMCS processes are already running, the start subcommand returns an Already running message to let you know the requested start is not necessary.

status SOLARIS

Returns status on all processes of the VMCS.

stop

Stops all processes in the VMCS.

admin (OMS)Stops, starts, or (on Solaris) checks status for OMS processes.

Location

Windows

install-path\inst-name\conf\oms-name\admin [restart | start | stop]

Solaris

install-path/vignette/inst-name/conf/oms-name/admin [restart | start | stop | status]



Description

The OMS admin command-line utility lets you start and stop (and obtain status on Solaris) for the OMS processes.

On Windows 2000 and NT, you must have system admin user privileges on the host where the OMS is installed to use the restart, start, and stop subcommands. On Solaris, you must be the VCMS administrator (owner of the VCMS files) to run the restart, start, and stop subcommands. To run the status subcommand, you must be a member of the VCMS administrators group.

Subcommands

restart

Stops the running processes in the OMS and then starts the processes.

start

Starts the OMS processes. If the OMS processes are already running, the start subcommand returns an Already running message to let you know the requested start is not necessary.

status SOLARIS

Returns status on all processes of the OMS.

stop

Stops all OMS processes.



admin cfgeditAllows you to adjust the settings in CMS, CDS, OMS, MCS, and web server module configuration files.

On Windows 2000 and NT, you must have system admin user privileges on the host where the components and processes are installed to use the admin cfgedit command. On Solaris, you must be a member of the VCMS administrators group.

NOTE: You can also use the Platform Variable Editor to set and edit configuration variables. See the Configuration Reference to learn more about the Platform Variable Editor and the configuration tasks for which it is best suited.

Location

Windows

install-path\inst-name\conf\component\admin cfgedit

Solaris

install-path/vignette/inst-name/conf/component/admin cfgedit

In these paths, component corresponds to one of the following:

• cms• cds-name• mcs-name• oms-name• ws-name• adminutil• cmscppapi

For more information about adminutil and cmscppapi, see the Appendix B, VCMS File Reference.

NOTE: You can edit the host.cfg file using the admin cfgedit command. Instead of navigating down to the /component level, go to the /conf directory and enter admin cfgedit host.cfg. See host.cfg on page B-23 for more information about the host.cfg file.



Description

The admin cfgedit command and its many subcommands provide the ability to create, delete, and manage individual configuration variables for the VCMS processes. The admin cfgedit command also enables you to set individual configuration variables with permanent overrides so that the admin refreshfromdb command will not overwrite them. For a full discussion of admin cfgedit, see the admin cfgedit chapter in the Configuration Reference.

admin chlog Allows you to dynamically adjust the log-level setting for:

• The CMS, CDS, and OMS components• Individual processes within the CDS and OMS components• Web-server modules

On Windows 2000 and NT, you must have system admin user privileges on the host where the components and processes are installed to use the admin chlog command. On Solaris, you must be a member of the VCMS administrators group.

Location

Windows

install-path\inst-name\conf\component\admin chlog [-u userID -p password] [-s subcomponent] [-l level] [-v]

Solaris

install-path/vignette/inst-name/conf/component/admin chlog[-u userID -p password] [-s subcomponent] [-l level] [-v]


• cms• cds-name• oms-name• ws-name



Description

The admin chlog command provides the ability to dynamically change the log level setting for the CMS, CDS, and OMS components. You can also dynamically change the log-level setting for the individual processes within the CDS and OMS components and for web-server modules.

For example, if you are not able to diagnose a problem with the CDS, admin chlog enables you to change the log level for the entire CDS component or for specific processes within the CDS (such as tmd or pad) so that you receive more complete diagnostic information. You can make this change while the processes are running.

The following table shows VCMS log levels and message distribution.

Options

-u userID -p password

Optional. Specify an ID and password only if you are changing the log level for the CMS. Supply your CMS user ID and password. If you do not supply an ID and password when changing the log level for the CMS, admin chlog prompts you for this information.

-s subcomponent

Optional. Specify the subcomponent (process) for which you want to dynamically change the log level. Valid values for CDS processes include ctld, cmd, pad, or tmd. Valid values for OMS processes include vrd, omd, or cld. If there is more than one instance of a particular process, for example you have multiple tmd processes in your CDS, chlog changes the log level for each instance.

Log level Message type

Written to

WINDOWS SOLARIS

1 error EventLog service messages

2 warning Eventlog service messages

3 audit process log file process log file

4 debug process log file process log file



NOTE: Do not specify subcomponents (processes) for the CMS. The admin chlog command dynamically alters the log level for all processes within the CMS, but cannot do so for individual CMS processes.

If you do not specify a subcomponent (process), admin chlog changes the log level for all processes within the current component directory. For example, if you are in the install-path/vignette/inst-name/conf/cds-huge directory and you run admin chlog without specifying the -s option, all the ctld, cmd, pad, and tmd processes in that directory adopt the new log level.

The -s option is not applicable to web-server modules because they do not include subprocesses. If you want to change the log level for multiple web-server modules, you need to navigate to the directory in which each one resides and then run the admin chlog command. You cannot alter the log level for more than one web server module at a time.

-l level

Optional. Specify the log level that you want to set for the component or process. As explained in the description for admin chlog, you can specify 1, 2, 3, or 4 for the level. If you do not specify a level value, admin chlog reads the log-level setting from the component’s configuration file.

NOTE: The -l option does not apply to web-server modules. This means that you must first change the log level setting in the configuration file for a web-server module before running the admin chlog command. The log level setting for web server modules can be set as high as 8 for maximum logging.

NOTE: If you specify a level value with the admin chlog command, the command does not write that value to the component’s configuration file. This means that the next time you start a component (or one of its processes), the component will use the log level setting from its configuration file and not the setting you specify with the admin chlog command.

-v

Optional. Activates verbose mode, which displays the host and port of the component or process for which you are altering the log level.



admin refreshfromdbThe admin refreshfromdb command refreshes the variable values in all configuration files with the values stored in the database. You can refresh the variable values for all VCMS processes (on the local host) or for a specific component.

Location for All Local VCMS Processes

Windows

install-path\inst-name\conf\admin refreshfromdb [-f]-u userID -p password

Solaris

install-path/vignette/inst-name/conf/admin refreshfromdb [-f]

-u userID -p password

Location for Specific Components

Windows

install-path\inst-name\conf\component\ admin refreshfromdb [-f] -u userID -p password

Solaris

install-path/vignette/inst-name/conf/component/ admin refreshfromdb [-f] -u userID -p password




• cms• cds-name• mcs-name• oms-name• ws-name• adminutil• cmscppapi

For more information about adminutil and cmscppapi, see Appendix B, VCMS File Reference.

Description

Refreshes all the variables in the configuration files with values from the database, as well as removes variables from the configuration files that no longer exist in the database. If you have modified variables for a component or process by editing the configuration file (using admin cfgedit), the admin refreshfromdb command prompts to see if you want to overwrite the modifications in the configuration file with values from the database.

If you specify -f, refreshfromdb overwrites all modifications to configuration files except for variables with permanent overrides.

If you edit variables within a configuration file and want to commit those changes to the database, use the admin cfgedit committodb subcommand. See the admin cfgedit chapter of the Configuration Reference.

The admin refreshfromdb command is especially useful when refreshing the values of referenced configuration variables. See Refreshing Referenced Configuration Variables on page 8-6.

On Windows 2000 and NT, you must have system admin user privileges on the host where you want to use the admin refreshfromdb command. On Solaris, you must be a member of the VCMS administrators group to use the admin refreshfromdb command.



Options

-f

Optional. Specify this option if you know you want to overwrite all modifications to configuration files with values from the database (except for those variables that have permanent overrides).

-u userID

Required. A user ID with system admin user privileges.

-p password

Required. The password for the user ID.

bobDispatches all CMS transactions.

Windows Service Name

Vignette 6.0 Dispatch Service (inst-name)

Description

All CMS services communicate through this main CMS process.

On Windows, 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 the VCMS Installation and Configuration Guide (printed copy shipped with product).

The cms.cfg file maintains configuration information for this process. See cms.cfg on page B-16.



campadminA program task that enables you to identify campaigns that are not working properly.

Location

Windows

install-path\6.0\taskbin\winnt\campadmin

Solaris

install-path/vignette/6.0/taskbin/solaris/campadmin

Description

The campadmin program task is used with the Vignette Relationship Management Server. This utility enables you to monitor campaigns, and notify campaign owners by e-mail when a broken campaign is detected. See the appendix that covers the campadmin program task in the Business Center Guide.

cgutilThe cgutil command is used with the Vignette Relationship Management Server. This command enables you to define custom content types and place content that is not managed by Vignette into groups. These imported content groups can then be configured as part of a campaign and delivered to a target audience.

NOTE: You must have the Developer role or System role to use the cgutil command.

See the cgutil appendix in the Business Center Guide for complete information on the cgutil command, including the command’s syntax and sample input.



cldA process in the OMS that logs visitor, visitor context, and profile mark information.

Much of the information that the cld logs is impression, response, and custom metric data for campaigns.

The oms.cfg file maintains configuration information for this process. See oms.cfg on page B-36.

cmd(cm on Windows)

The CDS process that maintains cached content.


Vignette 6.0 Cache Manager (inst-name cds-name dm)

Description

The Cache Manager process maintains stable pages of information in a cache so that only dynamic information needs to be generated from the database.

There is one Cache Manager process per CDS.

The cds.cfg file maintains configuration information for this process. See cds.cfg on page B-10.



configConfigures VCMS system components.

Location

Windows

install-path\6.0\adm\config.bat

Solaris

install-path/vignette/6.0/adm/config

Description

This interactive script enables you to configure a CMS, CDS, MCS, or OMS and to load or remove project packages. For more information, see Chapter 9, Managing the VCMS Site.

For information on using this command, see the VCMS Installation and Configuration Guide (printed copy shipped with product).

On Windows 2000 and NT, you must have system admin user privileges to run this command. On Solaris, you must be a member of the VCMS administrators group to run this command.

ctldThe Tcl Page Generator (a CDS process) interprets Tcl templates, accesses content, and generates web pages on demand by viewers on the World Wide Web.


Vignette 6.0 Page Generator (inst-name cds-name ape-n)



Description

The Tcl Page Generator master process (ctldm) spawns a pool of slave processes (ctlds) that generate page content from the database. The master process controls the slave processes that it spawns.

There is one Tcl Page Generator master process in an Application Engine. By default, the master process can create up to eight slave processes (for a total of nine Page Generator processes). For information on changing the number of slave processes, see Increasing Tcl Page Generator (ctld) Requests on page 11-2.

The master process typically starts two or more slave processes automatically when it receives a page generation request from an associated Web server.


The delivery.tcl and ctld.tcl files initialize the template interpreter. See Initialization Files for the Tcl Interpreter on page 6-5.

encryptA VCMS utility for generating an encrypted string from a cleartext string.

Location

Windows

install-path\6.0\bin\winnt\encrypt

Solaris

install-path/vignette/6.0/bin/solaris/encrypt

Description

Several configuration variables accept encrypted strings as values. See the Security Guide.

For an example, see Password Encryption on page 7-11.



expireA program task for expiring records, files, or templates.

Location

Windows

install-path\6.0\taskbin\winnt\expire [-r] (project_mgmt_id | ci_mgmt_id) [-w adminutil.cfg-path]

Solaris

install-path/vignette/6.0/taskbin/solaris/expire [-r] (project_mgmt_id | ci_mgmt_id) [-w adminutil.cfg-path]

Description

The expire command is used primarily as a program task in the Production Center’s 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 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, 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 tab of the project, record, file, or template Details window.

-w adminutil.cfg-path

The path to the adminutil.cfg configuration file, which is necessary when your CMS is configured for security. When you use the expire command as a program task (in the Production Center’s Task Manager or Project Manager) if this path is not specified, it defaults to:

WINDOWS install-path\inst-name\conf\adminutil\adminutil.cfg

SOLARIS install-path/vignette/inst-name/conf/ adminutil/adminutil.cfg

However, if your CMS is configured for security and you use the expire command from the command line, you must include the -w option along with the complete pathname to the adminutil.cfg file. If not, the expire command returns an error message.

For a full description of the adminutil.cfg file, see the Security Guide.

Example

Almost all the options of the expire command are handled by selections in the Production Center tools. This example, however, specifies individual subprojects (by project_mgmt_id) and templates, records, or files (by ci_mgmt_ids) in a program task for a project-level expiration:

expire /pr/106 /ci/21d /ci/404g /ci/783f

NOTE: The forward slash (/) is part of the ID, not a path, and should be used whether specifying the task for a Windows 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 hierarchy) can be expired.



flushcacheA program task that clears pages from a specified location.

Location

Windows

install-path\6.0\taskbin\winnt\ flushcache -h host -p port [-H proxy_host] [-P proxy_port] path ...

Solaris

install-path/vignette/6.0/taskbin/solaris/ flushcache -h host -p port [-H proxy_host] [-P proxy_port] path ...

Description

The flushcache program task is used primarily as a Task Manager or Project Manager program task. It clears pages from one or more specified paths within a CDS 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.

See Clearing Pages from a Root Path on page 10-9.

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 the Production Center Guide.

NOTE: The flushcache command works in the same way as the VCMS template command CLEAR_CACHE. For more information on using CLEAR_CACHE, see the Tcl: Template Cookbook.

NOTE: Do not use the flushcache command to clear pages after you expire a template. You must manually delete cached pages related to a template you expire.



Options

-h host

Specifies the host where the Docroot Manager for the CDS resides.

-p port

Specifies the port number for the Cache Manager in the CDS associated with the web server document root.

-H proxy_host

Optional. If your CDS is outside the firewall and you’re using a proxy server to regulate outbound connections to it, specify the name of the proxy server.

-P proxy_port

Optional. If your CDS is outside the firewall and you’re using a proxy server to regulate outbound connections to it, specify the port number used for communications with the Cache Manager.

NOTE: If you are using a proxy server, you cannot use secure authenticated or encrypted connections.

path

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

Example

The following example shows 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 CDS whose Cache Manager’s port is 13625, on system sysA.

flushcache sysA 13625 /OurSite/Books




gencertA command-line utility for generating private keys and certificate requests.

Location

Windows

install-path\6.0\adm\gencert [-a alias] [-c componentname] [-b (512|1024)] [-e] [-f filename] [-s]

Solaris

install-path/vignette/6.0/adm/gencert [-a alias] [-c componentname] [-b (512|1024)] [-e] [-f filename] [-s]

Description

You can configure your VCMS system to perform authentication between components (or even processes). Each component must maintain a private key and certificate.

The gencert command allows you to generate private key and certificate requests that you can use to obtain new certificates and private keys to replace the shipped defaults. See the Security Guide for a full description of the gencert command.



Options

Option Function

-a alias Optional. The file that gencert generates for the key and certificate request will have file names with the format: alias.key and alias.cer

If no alias is specified, the componentname is used for the file name. If no componentname is specified, the file names are new.key and new.cer by default.

-c componentname Optional. Requests a certificate with an associated componentname in the CN (Common Name) field. You can configure a server component to examine and verify this field when it receives the certificate. See the section on overriding default common name values in the Security Guide.

Note that gencert does not populate the CN field with the specific value of componentname. Instead, it associates componentname with a more descriptive value. For instance, specifying -c cms causes gencert to create a certificate whose Common Name is VgnCMS. For a list of the associations, see the Security Guide.

NOTE: The value of componentname must be all lower-case.

-b (512|1024) Optional. Specifies the number of bits in the generated key. If the argument is not specified, it defaults to 512.

-e Optional. Encrypts the generated private key with a password. After you enter the command, you will be prompted to designate the password. See the section on encrypting private keys for components in the Security Guide.

-f filename Optional. Reads the contents of filename into the prompts for the certificate’s field values.

Note that if filename specifies a value for the CN field, the value found in filename will override the value specified with the -c option.

You can also specify the private key password for the generated certificate by including the following line in filename:

PRIVATE_KEY_PASSWORD=password



inboundmailA program task that you can schedule to collect e-mail and post contents to a template.

Location

Windows

install-path\6.0\taskbin\winnt \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]

Solaris

install-path/vignette/6.0/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]

-s Optional. Causes gencert to function in silent mode, meaning that the user will not be prompted to enter any fields. Instead, all necessary information is read directly from the filename specified with -f.

If you have specified the -e option, be sure to include PRIVATE_KEY_PASSWORD=password in filename.

Option Function



Description

In order to read e-mail, inboundmail communicates with mail servers through the POP3 protocol that is supported by popular mail servers including Microsoft Exchange Server. After it reads e-mail, it converts the e-mail data into multi-part form data and then issues 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 plaintext e-mail.

NOTE: The inboundmail program task does not have the ability to use SSL for communicating with secure web servers.

Most likely, you will want to schedule inboundmail as a repeating program task. See the discussion of program tasks in the Production Center Guide.

Options

-mailserver mail-host

This parameter identifies the address of the mail server. For example, mail.example.com.

-mailport port

Optional. This parameter identifies the port at which the mail server is available. Its default value is 110.

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

-webserver web-domain

This parameter identifies the web server associated with the CDS that will execute the template that processes the mail message. For example, www.example.com.



-webport port

Optional. This parameter identifies the port at which the web server is available. Its default value is 80.

-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 determines the variable names through which the form data will be available to the target template. For example:

details comments

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 three parts and only one name was specified, the 2nd and 3rd parts will be named “part-2” and “part-3” respectively.

-debug

Optional. This parameter determines if debug messages are printed.

Exampleinboundmail -mailserver mail.example.com -mailport 6578 -maillogin newsbot -mailpassword 73^%4a547 -webserver www.example.com -webport 443 -url /Jason/Fleece/1,1443,,00.html -namelist \"details\"" \"comments\"" -debug



launchA program task that launches records, files, and templates, making them visible on all live CDSs. (Templates designated for internal use only are not launched.)

Location

Windows

install-path\6.0\taskbin\winnt\launch [-r] (project_mgmt_id | ci_mgmt_id) [-w adminutil.cfg-path]

Solaris

install-path/vignette/6.0/taskbin/solaris/launch [-r] (project_mgmt_id | ci_mgmt_id) [-w adminutil.cfg-path]

Description

The launch program task is used primarily as a Task Manager or Project Manager program task. It launches records, files, and templates to all live CDSs 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 the top level only, or use the -r flag to launch all subprojects recursively 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 tab of the project, record, file, or template Details window.


The path to the adminutil.cfg configuration file, which is necessary when your CMS is configured for security. When you use the launch command as a program task (in the Production Center’s Task Manager or Project Manager) if this path is not specified, it defaults to:


SOLARIS install-path/vignette/inst-name/conf/adminutil/adminutil.cfg

However, if your CMS is configured for security and you use the launch command from the command line, you must include the -w option along with the complete pathname to the adminutil.cfg file. If not, the launch command returns an error message.

Use this option to specify a custom configuration file for the launch command to use when gaining access to VCMS processes in a secure VCMS installation.


Example

Almost all the options of the launch command are handled by selections in the Task Manager or Project Manager. In this example, you specify individual subprojects (project_mgmt_id) and templates, records, or files (ci_mgmt_ids) in a program task for a project-level launch, where you can also set a Repeat command:

launch /pr/106 /ci/21d /ci/404g /ci/783f




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.

mcdThe Multi-Channel Delivery Agent (mcd) is a VMCS process, which means that it is part of the Vignette Multi-Channel Communication Server product.

The Multi-Channel Delivery Agent delivers content via multiple delivery channels. When campaign events occur, the mcd determines which style templates to evaluate. The style templates generate delivery documents that are processed by the appropriate Delivery Channel Plug-in and sent to subscribed visitors.

The mcs.cfg file maintains configuration information for this process. See mcs.cfg on page B-30.

omdThe Observation Manager (omd) is an OMS process that manages visitor records and visitor context objects.


padThe CDS process that deploys static content when needed for web page generation.


Vignette 6.0 Placement Agent (inst-name cds-name dm)



Description

The Placement Agent controls a pool of slave processes that deploy static content that is not stored in the database, and makes it available for use when a web page is generated.

There is one Placement Agent master process in a CDS. By default, the master process can create up to eight slave processes (for a total of nine Placement Agent processes per CDS). For information on changing the default, see Increasing Request Handling on page 11-6.


pzndeleteUse the pzndelete executable to help manage the Vignette Relationship Management Server’s visitor records database. The pzndelete executable removes visitor and visitor context information from the visitor records database. See the Visitor Services Guide for more information about the Vignette Relationship Management Server.

NOTE: Be sure that you have a configured OMS within your VCMS installation before invoking pzndelete. Otherwise, the pzndelete executable will not function properly.

Description

To create a pzndelete task, you must be the admin user, or you must have the System role, or you must be a project owner who has the Full Business Center role.

Without arguments, pzndelete deletes profile marker data for keywords deleted through the Keyword Manager since pzndelete last executed. (pzndelete also removes the profile marker data for deleted keywords when it’s specified with -v or -m.)

Syntaxpzndelete [-e] [-l length-in-days -v | -m]



Options

-e

Use this option to delete expired visitor context information from the system or visitor database (depending on your configuration) and from the Observation Manager (omd) cache.

-l length-in-days

Use this option to specify the elapsed time (in number of days) that you want to use as the criteria for deleting visitor and profiling information from the visitor records database.

-m

Specify this option if you want to remove profile marker data. This option and the -v option are mutually exclusive.

-v

Specify this option if you want to remove both visitor registry and profile marker data. This option and the -m option are mutually exclusive.

Examples

-l length-in-days -v

Deletes all visitor information (both visitor registry and profile marker data) for visitors who haven’t visited your site for the number of days specified in length-in-days. For example, this command removes all information about visitors who haven’t been to the web site in 60 days:

pzndelete -l 60 -v

If a visitor whose information has all been deleted returns to your web site, that visitor will have to complete another registration form (if your site requires registration).

-l length-in-days -m

Deletes the profile marker data (not registration data) of visitors who haven’t visited your site for the number of days specified in length-in-days. For example, this command removes the profile marker data of visitors who haven't been to the site in 28 days:

pzndelete -l 28 -m



If a visitor whose profile marker information has been deleted (but whose registration information wasn’t deleted) returns to your web site, that visitor will not have to complete another registration form.

NOTE: pzndelete always checks for and removes any data for deleted keywords. With arguments, pzndelete also removes some or all visitor data according to the age of the data.

When you use pzndelete, keep in mind that the number of days you specify with -l can have a big impact on your site: the shorter the time period, the longer the operation will take and the more data will be removed from the database.

For example, you would probably not want to execute this command, because it would remove most of the site's profile information:

pzndelete -l 3 -v

Of course, as you plan and prototype profiling, you can adjust the pzndelete time period.

reseteurA program task that clears the user and group cache of the external user repository (EUR).

Location

Windows

install-path\6.0\taskbin\winnt\reseteur [-h] [-b host:port] {-c credentials | -l userid:pwd} [-w adminutil.cfg-path]

Solaris

install-path/vignette/6.0/taskbin/solaris/reseteur [-h] [-b host:port] {-c credentials | -l userid:pwd} [-w adminutil.cfg-path]



Description

The reseteur program task enables administrators to clear the user and group cache of the external user repository (EUR) without stopping and restarting the bob (Dispatch Service) process.

Administrators can run the reseteur program task to force LDAP (lightweight directory access protocol) updates to appear in the EUR. For example, if new groups are defined via an LDAP client and do not appear in the EUR, an administrator can launch reseteur overnight to clear the cache and force the new groups to appear. The reseteur program task helps ensure that the users, groups, user-to-group associations, and user-to-role associations defined in the EUR match corresponding LDAP entries. See Appendix D, Configuring the VCMS Software to Use an LDAP User Repository for more information.

Options

-h

Displays usage information for this program task and its options.

-b host:port

Specifies the host and port for the bob process.

-c credentials | -l userid:pwd

Required. You must supply either the encrypted form of your user authorization or your user ID and password for the CMS.


If your VCMS components (such as the CMS or CDS) are configured for security, supply the complete pathname to the adminutil.cfg configuration file. If you have configured the VCMS software for security and this path is not specified, the reseteur command returns an error message.




sgutilA program task that retrieves and loads visitor segments from a netCustomer web server.

Description

The sgutil program task retrieves visitor segments and segment populations from a netCustomer web server. It then loads the segments into the VCMS system database and the segment populations into the VCMS visitor records database.

For more information, see the sgutil appendix in the Business Center Guide. Also see the Production Center Guide for the steps to set up a program task.

tedA CMS process that tracks timed events for the main CMS process (bob).


Vignette 6.0 Event Service (inst-name)

Description

The ted process tracks scheduled events for the CMS.




tmd The CDS process that manages templates.


Vignette 6.0 Template Manager (inst-name cds-name ape-n)

Description

The Template Manager checks whether any templates have been revised and updates the corresponding Page Generator process. You can also tell the Template Manager to make new templates available at any time.

There is one Template Manager process per Application Engine (ape) subcomponent.


transferprojectAn executable that moves project content and project information from one CMS to another.

Description

If your company has multiple CMSs, you may need at times to transfer—copy—a project from one CMS to another. The transferproject command, available from the command line, allows you to perform the transfer.

NOTE: If you plan to run transferproject outside of the Vignette install tree, you must set the VGN_HOME system environment variable to the root of your VCMS installation. For example, if you install on Solaris and your VCMS installation is at install-path/vignette/6.0/, then the VGN_HOME environment variable must point to the directory one level above the 6.0 directory, which is install-path/vignette.

For the details about transferproject, see Chapter 12, Transferring Projects and Tables between CMSs.



Syntax transferproject -b CMShost:CMSport:projectid -o { export [-f file-format] [-r | -R] [-t content item-list | list file] [-n version-name] import [-s | -e] [-F] [-i] [-m ID map file] [-E character encoding] [-z conflict-option] [-n version-name] [-u] [-T] delete exportData -t table-list importData [-k] deleteData [-k] -p package-directory [-w adminutil.cfg-path] [-l user:password] [-v] [-?]

Status Codes

The transferproject command returns the following status codes. A non-zero value indicates that an error occurred.

Code Status

0 Success

1 Fatal error

2 Conflicts found (import with the -z 4 option)

3 Error retrieving SQL schema information for table

4 Error occurred while writing SQL file

5 Error occurred while writing the purge file

6 Error retrieving record data

7 Error requesting visual template file contents

8 Error occurred while opening a file in the distribution directory

9 Error requesting file contents

10 Error occurred while writing a file in the distribution directory

11 Error occurred while creating the distribution directory



Options

-o operation

Required. The transfer operation: export, import, delete, exportData, importData, or deleteData.

delete

Operation that deletes 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 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).

import

Operation that imports project data from the .attr file and the .tar or .zip file in the project package.

If the -R option is specified at export, the .attr file also includes database content.

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.



-b destCMhost:port:projID

Required with the import operation. The host and port of the CMS into which to import the project, and the management ID of the project under which to put the imported project. Example: -b whitman:32000:/pr/65

NOTE: 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. Specify a forward slash (/) as the project ID if you want transferproject to ignore the name of the top-level project in the imported package and place the project contents into the Base Project. All subprojects in the imported package will be owned by the Base Project upon import.

-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 management ID of the project to export. Example: -b thoreau:7623:/pr/24

-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

-e

Optional with the import operation. Transferred content items inherit workflow from the project into which they are imported. In effect, a content item imported with -e is treated like a content item newly added to the project: it inherits the same workflow that an asset of its type (template, record, or file) would be assigned if it were added through the Production Center.

The -e and -s options are mutually exclusive. If both are specified, -e takes precedence. Compare the -s option.



-E character encoding

Optional with the import operation. Specifies the character set encoding of the incoming project package. You can specify an encoding value of latin1, which defines extensions to ASCII for values above 127 (character points) for conveying special Latin characters, such as accented characters.

NOTE: Do not use the -E option to import project packages that were created with Vignette e-Business Platform 5.5 or later Vignette software (including VCMS 6.0). The -E option is only necessary when you need to import project packages created with StoryServer 5.0 that contain one or more special characters (an 8-bit character with the high-order bit set; for example, the copyright symbol).

-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, 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, or zip on Solaris. Example: -f tar

-F

Optional with the import operation. Replaces or creates a new version of existing content items, including locked content items. If you do not specify the -F argument, transferproject checks all content items that are to be replaced or versioned to determine if they are locked. If transferproject finds locked content items, it terminates the import operation and displays an error message. The error message lists the management ID of each locked content item and the name of the user who has the item locked.

-i

Optional with the import operation. Preserves the template IDs of source CMS templates when writing them onto the destination CMS. This option should be used with caution. See Using the –i Option on page 12-26.

-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 username:password

Required with all operations.

For export operations: VCMS user name and password that are valid on the source CMS. Example: -l pjames:m1stry7

For import and delete operations: VCMS user name and password that are valid on the destination CMS (and have the required authorization for the operation). Example: -l codger:gor18dita

-m ID map file

Optional with the import operation. If you specify this option, transferproject creates a text file that contains a source-to-target mapping. The format of each line in the file is:

source ID target ID operation

Where:

• source ID is the management ID from the original (exported) system, for example: ci/27

• target ID is the management ID in the new system

• operation is:

— NEW – object added

— UPDATED – object updated (-z 2)

— VERSION – new version of an existing object was created (-z 3)

-n "version-name"

Optional with the export operation. The version-name specifies the version name associated with the item(s) you want to export. Content items which do not have a version of this name will be ignored by the export.

Example: -n "daytime"

-n "version-name"

Optional with the -z 3 option for the import operation. Specifies the name of the version created if object conflicts occur.

-p projPackageDir

Required. The directory that contains the project package files. Example: -p /opt/vign/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). Database content is exported to the .data, .purge, and .sch files; project data is exported to the .attr file and to a .zip or .tar file. If you specify -r with export, run import and importData to complete the transfer.

See Project Package on page 12-13.

The -r and -R options are mutually exclusive. If both are specified, -R takes precedence. See The -r option versus the -R option on page 12-22.

NOTE: If you are importing a record that already exists in the destination CMS (but the row for that record does not exist) and you are updating the content for the row (that is, the package was exported with the -r option), a new row is inserted and a new version of the record is created.

-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). Additionally, the tables to which you are transferring the data must already exist in the destination database. For example, if you are exporting data from a table named UserIds, the UserIds table must already exist in the destination database. Unlike the -r option, -R causes database content to be exported to the .attr file rather than to the .data, .purge, and .sch files.

At import, you only need to run transferproject -o import to complete the transfer. The import option pulls database content from the .attr file.

The -r and -R options are mutually exclusive. If both are specified, -R takes precedence. See The -r option versus the -R option on page 12-22.

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

The -e and -s options are mutually exclusive. If both are specified, -e takes precedence. Compare the -e option.



-t content item-list or list file

Optional with the export operation. Allows users to transfer a subset of a project’s content items (records, files, or templates) between projects. If the list includes more than one item, it must be enclosed in double quotation marks, and the items should be separated by spaces. You also have the option of listing the items in a text file and specifying the name of that file with the -t option.

Example: -t "/ci/43 /ci/3a" or -t list_file.txt

-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 more than one table, it must be enclosed in double quotation marks. The tables must be in the source CMS’s VCMS system database.

Example: -t "Auditnos Audithist"

-T

Optional with an import operation. Use this option when you import a project package that contains database content for more than one content database. This option works only with those project packages that were exported with the -R option. Additionally, the destination VCMS configuration must have at least as many content databases as the source configuration, and the target tables must already exist in the destination content databases.

For example, records that were in content database A in the source VCMS configuration will be imported into content database A in the destination VCMS configuration. Records that were in content database B will be imported into content database B in the destination VCMS configuration, and so on.

NOTE: The -T option requires that the CMS configuration information (for both the source and destination) includes the PM_CONTENT_DB_* configuration parameters. See Managing System and Content Databases on page 7-1 and the Configuration Reference for more information about the PM_CONTENT_DB_* parameters.



-u

Optional with an import operation. Use this option when you need to import assets that already exist in the destination project and you want those assets to retain their original state (such as Live or Ready for Internal Use). For example, if you need to import modified System templates into the Base Project, using the -u option ensures that the System templates in the Base Project that are overwritten retain their original state. This option supersedes the -e and -s options.

-v

Optional with any operation. Specifies verbose mode.


If your VCMS components (such as the CMS or CDS) are configured for security, supply the complete pathname to the adminutil.cfg configuration file. If you have configured the VCMS software for security and this path is not specified, the transferproject command returns an error message.


-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 "version-name" on page A-45.

• -z 4 View potential import conflicts before actually executing the import, i.e. no data is transferred. Returns a list of conflicts.

-?

Displays a usage statement.



version A program task that creates, names, restores, or deletes a version of records, files, or templates.

Location

Windows

install-path\6.0\taskbin\winnt\version [-o version operation] [-n version name] [-r] (project_mgmt_id | ci_mgmt_id) [-w adminutil.cfg-path]

Solaris

install-path/vignette/6.0/taskbin/solaris/version [-o version operation] [-n version name] [-r] (project_mgmt_id | ci_mgmt_id) [-w adminutil.cfg-path]

Description

The version command is used primarily as a program task in the Production Center’s 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 his or 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 content items in a project’s top level, or use the -r flag to version content items in all subprojects recursively through an entire project hierarchy.

The project owner can also version individual content items 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.



Options

-o version operation

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

Creates 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

Creates a version only for those content items that have already been versioned (-n version name optional).

restore

Restores the specified version (must also specify -n version name).

name

Attaches the specified name to the current version (must also specify -n version name). A specific name can be 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. (Names can have a maximum of 128 characters, including spaces.)

delete

Deletes the specified version (must also specify -n version name).

-n version name

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

Optional. Recursively performs a version operation on all records, files, and templates 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 tab of the project, record, file, or template Details window.


The path to the adminutil.cfg configuration file, which is necessary when your CMS is configured for security. When you use the version command as a program task (in the Production Center’s Task Manager or Project Manager) if this path is not specified, it defaults to:


SOLARIS install-path/vignette/inst-name/conf/adminutil/adminutil.cfg

However, if your CMS is configured for security and you use the version command from the command line, you must include the -w option along with the complete pathname to the adminutil.cfg file. If not, the version command returns an error message.


Defaults

The VCMS software 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 workflow, the VCMS software 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 content item 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 (simply version or version -r with no arguments), the VCMS software 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

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

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

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



vhsA CMS process that manages requests for the CMS.


Vignette 6.0 Request Service (inst-name)

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 service processes. For information on changing the default number of slave processes, see Increasing Request Handling on page 11-6.


vrdThe OMS process that receives external messages.

A Router (vrd) receives all external messages for the OMS and routes those messages to the other processes of the OMS, including the Observation Manager (omd) and the Campaign Logging Agent (cld).




vwd

Windows Service Names

Vignette 6.0 Observation Manager (inst-name oms-name vwd-hostname) (vwd for OMS)

Vignette 6.0 Multi-Channel Service (inst-name oms-name vwd-hostname) (vwd for MCS)

Description

A watchdog process that monitors other OMS and MCS processes. A vwd process is present on any machine that hosts a process of the OMS or MCS.

The oms.cfg file maintains configuration information for the OMS Watchdog, and the mcs.cfg files maintains configuration information for the MCS Watchdog.

NOTE: You can configure the vwd to send e-mail notification when OMS or MCS processes go down. See Enabling VCMS Status Notification on page 11-11 for more information.

wscfgAssociates or disassociates a web server on a dissimilar host in a heterogeneous configuration with a CDS on a standard host.

A dissimilar host is a machine that runs a different operating system than the operating system being run by the other machines in your site. For example, if your site runs on Windows 2000 machines and you add an AIX machine, the AIX machine is called a dissimilar host.

A heterogeneous configuration is one in which certain components of your web site reside on a dissimilar host.

NOTE: Vignette supports only certain combinations for a heterogeneous configuration. See the Vignette Content Management Server V6 Release Notes, version 6.0 to find what combinations Vignette supports.



Location

AIX

install-path/vignette/6.0/bin/aix/wscfg

NOTE: You must ensure that LIBPATH contains the path to the AIX libraries in order to run wscfg.

Description

The wscfg executable file performs various actions, based on the arguments you provide:

-a ws.cfg-path

Associates a web server running on the dissimilar host in a heterogeneous configuration with a CDS running on one or more other hosts in that same configuration.

-d ws.cfg-path

Disassociates a web server on the dissimilar host from a CDS running on one or more other hosts in that same configuration.

-r ws.cfg-path

Refreshes the ws.cfg file on the dissimilar host. You must refresh the ws.cfg file on the dissimilar host if you modify your site’s configuration so that the ws.cfg configuration file on the web server’s Docroot Manager host is updated with new information after you have run ws.cfg -a on the dissimilar host.

For more information about the wscfg command, see the VCMS Installation and Configuration Guide (printed copy shipped with product). The VCMS Installation and Configuration Guide further describes heterogeneous configurations. It also tells how to plan and implement the components of such a configuration and how to install the necessary software to run the wscfg command on the dissimilar host.

.


B VCMS File Reference

Summary: A reference for Vignette® Content Management Server V6 (VCMS) files and directories.


Before you begin: Chapter 6, Managing VCMS Files

Topics include: • File Reference Overview• adminutil.cfg• asp-id.log• bob.log• bob.pid• cds.cfg• cfgpassword.log• cld-id.log• cld-id.pid• cld-id-timestamp.log• cmd.log• cmd.pid• cms.cfg• cmscppapi.cfg• config.log• ctld-id.#.infolog• ctld-id.#.log• ctld-id.pid• ctld.tcl• delivery.tcl• docroot• host.cfg• insts.cfg• jsp-id.log• jsp-id.pid• manifest• mcd-id.deliver.log• mcd-id.#.log• mcd-id.pid• mcs.cfg

• messages• metafiles• metatemplates-id• obj.conf.vgnbak• omd-id.log• omd-id.pid• oms.cfg• pad.#.log• pad.pid• Preferences• security.cfg• staticfiles• ted.log• ted.pid• tedtasksworkingdir• templates-id• tmd-id.log• tmd-id.pid• upgrade.log• UsrMacroData.xml• vhs.#.log• vhs.pid• vrd-id.log• vrd-id.pid• vwd.log• vwd.pid• ws.cfg• ws.log• ws.pid

August 2001 Vignette Confidential B-1

VCMS File Reference Administration Guide

File Reference OverviewThis appendix contains information on the VCMS files.

NOTE: Information about processes and commands can be found in Appendix A, VCMS Process Reference.

File or directory name Type Description

adminutil.cfg Configuration file Configuration information for the VCMS utilities and program tasks

asp-id.log Log file One log file for each ASP Page Generator

bob.log Log file Log file for the bob (Dispatch Service) process

bob.pid SOLARIS Process ID file The process identification number for the bob (Dispatch Service) process

cds.cfg Configuration file Configuration information for the Content Delivery Server (CDS) and its processes

cfgpassword.log Log file Log file for errors encountered retrieving or storing passwords for the configuration files

cld-id.log Log file One log file for each cld (Campaign Logging Agent) process

cld-id.pid SOLARIS Process ID file The process identification number for each cld (Campaign Logging Agent) process

cld-id-timestamp.log Log file Log file passed to the netCustomer Analysis Engine by the cld (Campaign Logging Agent) process on the OMS

cmd.log Log file Log file for the cmd (Cache Manager) process

cmd.pid SOLARIS Process ID file The process identification number for the cmd (Cache Manager) process

cms.cfg Configuration file Configuration information for the Content Management Server (CMS) and its processes

cmscppapi.cfg Configuration file Configuration information used by VCMS APIs for connecting to secure processes

config.log Log file Log file containing errors generated while configuring the VCMS software

ctld-id.#.infolog Log file Log file for the LOG template command

B-2 Vignette Confidential August 2001

Administration Guide VCMS File Reference

ctld-id.#.log Log file One log file for each ctld (Tcl Page Generator) process

ctld-id.pid SOLARIS Process ID file The process identification number for each ctld (Tcl Page Generator) master process

ctld.tcl Configuration file Local initialization information for the ctld (Tcl Page Generator) process

delivery.tcl Configuration file Global initialization information for the ctld (Tcl Page Generator) process

docroot Directory On-line VCMS information that your web browser can access

host.cfg Configuration file Contains the configuration information for the local host

insts.cfg Internal file Contains information about each VCMS component and process installed on the local host

manifest Configuration file For each VCMS component, lists the subcomponents configured on the local host

mcd-id.deliver.log Log file One delivery log for each mcd process

mcd-id.#.log Log file One log file for each mcd (Multi-Channel Delivery Agent) process

mcd-id.pid SOLARIS Process ID file The process identification number for each mcd (Multi-Channel Delivery Agent) master process

mcs.cfg Configuration file Configuration information for the Vignette® Multi-Channel Communication Server V6 (VMCS) and its processes

messages SOLARIS Log file Log file of errors for the VCMS

metafiles Directory Binary versions of the browser capabilities of corresponding templates

metatemplates-id Directory Holds template meta-data

obj.conf.vgnbak Configuration file A backup copy of the NSAPI configuration file for an iPlanet web server

omd-id.log Log file One log file for each omd (Observation Manager) process




omd-id.pid SOLARIS Process ID file The process identification number for each omd (Observation Manager) process

oms.cfg Configuration file Configuration information for the OMS (Observation Management Server) and its processes

pad.#.log Log file Log file for the pad (Placement Agent) process

pad.pid SOLARIS Process ID file The process identification number for the pad (Placement Agent) master process

Preferences Configuration file (Present only if you install the VCMS Tools)

Preferences for the browser to use for previewing templates, and for viewing on-line documentation

security.cfg Configuration file (Present only if you install theVCMS Tools)

Security configuration information for the VCMS user tools

staticfiles Directory Working copies of the static files that the vhs (Request Service) has processed

ted.log Log file Log file for the ted (Event Service) process

ted.pid SOLARIS Process ID file The process identification number for the ted (Event Service) process

tedtasksworkingdir Directory Timed-event process working files

templates-id Directory Template cache written by tmd and read by ctld

tmd-id.log Log file One log file for each tmd (Template Manager) process

tmd-id.pid SOLARIS Process ID file The process identification number for each tmd (Template Manager) process

upgrade.log Log file Log file of errors generated while upgrading the VCMS

UsrMacroData.xml Configuration file (Present only if you install the Vignette Development Center)

Custom macros created by users of the Macro Editor within the Vignette Development Center




vhs.#.log Log file Log file for the vhs (Request Service) process

vhs.pid SOLARIS Process ID file The process identification number for the vhs (Request Service) master process

vrd-id.log Log file Log file for the vrd (Router) process

vrd-id.pid SOLARIS Process ID file The process identification number for each vrd (Router) process

vwd.log Log file Log file for the vwd (Watchdog) process

vwd.pid Process ID file The process identification number for the vwd (Watchdog) process

ws.cfg Configuration file Configuration information for the web server module




adminutil.cfgThe configuration file for the VCMS utilities and program tasks.

Location

Windows

install-path\inst-name\conf\adminutil\adminutil.cfg

Solaris

install-path/vignette/inst-name/conf/adminutil/adminutil.cfg

Description

The adminutil.cfg file contains configuration variables for the VCMS utilities and program tasks, including variables that enable the utilities and program tasks to connect securely to the VCMS processes. The following administrative utilities and program tasks use this file:

• admin cfgedit • cgutil • campadmin • config • expire • flushcache • launch • pzndelete • sgutil • transferproject • upgrade • version

See the Security Guide for a full description of the security variables in adminutil.cfg.

You can use the admin cfgedit utility to edit this file. You can also use the Platform Variable Editor to set and edit configuration variables. See the Configuration Reference to learn more about the Platform Variable Editor and the admin cfgedit utility.



asp-id.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cds-name\asp-id.log

Solaris

install-path/vignette/inst-name/logs/cds-name/asp-id.log

Description

The log file contains the chronological list of transactions and errors for this ASP Page Generator (IIS web server instance). The id in asp-id.log corresponds to the unique identifier of the ape (Application Engine) to which the ASP Page Generator belongs. For example, if an Application Engine is named ape-1, the log file for its ASP Page Generator is named asp-1.log.

NOTE: An Application Engine can contain only one Tcl Page Generator, one ASP Page Generator, and one JSP Page Generator.

The level of logging is set in the LOG_LEVEL configuration variable. See the Configuration Reference for more information about the LOG_LEVEL variable.

For more information, see log Files and pid Files on page 6-8.



bob.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cms\bob.log

Solaris

install-path/vignette/inst-name/logs/cms/bob.log

Description

The log file contains the chronological list of transactions and errors for the bob (Dispatch Service) process.





bob.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cms/bob.pid

Description

The pid file contains the process identification number for the bob (Dispatch Service) process. For more information, see log Files and pid Files on page 6-8.



cds.cfgThe configuration file for the CDS and its subcomponents and processes, including:

• Docroot Manager (dm)

— Cache Manager (cmd)

— Placement Agent (pad)

• Application Engine (ape)

— Template Manager (tmd)

— Tcl Page Generator (ctld)

— ASP Page Generator (IIS web server instance)

Location

Windows

install-path\inst-name\conf\cds-name\cds.cfg

Solaris

install-path/vignette/inst-name/conf/cds-name/cds.cfg

Description

Each VCMS component maintains its own configuration information, both in the VCMS system database and in a component-specific configuration file. The CDS component contains two subcomponents which each consists of multiple processes. The configuration information for each subcomponent and process is contained in the cds.cfg configuration file.

Use the admin cfgedit utility to edit this file. You can also use the Platform Variable Editor to set and edit configuration variables. See the Configuration Reference to learn more about the Platform Variable Editor and the admin cfgedit utility.



See also cmd on page A-20, pad on page A-34, tmd on page A-40, and ctld on page A-21.

For more information, see Overview of Configuration Files on page 6-3.

cfgpassword.logLogs errors related to encryption/decryption of configuration files.

Location

Windows

install-path\inst-name\logs\cfgpassword.log

Solaris

install-path/vignette/inst-name/logs/cfgpassword.log

Description

The component-specific configuration files are encrypted with passwords. Any errors encountered encrypting or decrypting the files with these passwords are logged in cfgpassword.log.

NOTE: This file does not exist by default. It is only created if errors need to be logged.

For more information, see the Configuration Reference.



cld-id.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\oms-name\cld-id.log

Solaris

install-path/vignette/inst-name/logs/oms-name/cld-id.log

Description

This log file contains the chronological list of transactions and errors for a cld (Campaign Logging Agent) process. The id in cld-id.log corresponds to the unique identifier for the cld (Campaign Logging Agent). For example, if you have a Campaign Logging Agent named cld-1, the corresponding log file is named cld-1.log.





cld-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/oms-name/cld-id.pid

Description

The pid file contains the process identification number for the cld (Campaign Logging Agent) process. The id in cld-id.pid corresponds to the unique identifier for the cld (Campaign Logging Agent). For example, if you have a Campaign Logging Agent named cld-1, the corresponding pid file is named cld-1.pid.




cld-id-timestamp.logA log file created by the cld (Campaign Logging Agent) on the OMS.

Location

Windows

install-path\inst-name\outgoing\oms-name\cld-name\cld-id-timestamp.log

Solaris

install-path/vignette/inst-name/outgoing/oms-name/cld-name/cld-id-timestamp.log

Description

This log file contains information to be passed to the netCustomer Analysis Engine from the Observation Management Server (OMS). The id in cld-id-timestamp.log corresponds to the unique identifier for the cld (Campaign Logging Agent).

The timestamp appended to the file name is in the format: YYYYMMDD-HHMMSS. See the netCustomer appendix in the Business Center Guide for more information.



cmd.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cds-name\cmd.log

Solaris

install-path/vignette/inst-name/logs/cds-name/cmd.log

Description

This log file contains the chronological list of transactions and errors for the cmd (Cache Manager) process. The level of logging is set in the LOG_LEVEL configuration variable. See the Configuration Reference for more information about the LOG_LEVEL variable.




cmd.pidSolaris only. On Solaris, every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cds-name/cmd.pid

Description

The pid file contains the process identification number for the cmd (Cache Manager) process. For more information, see log Files and pid Files on page 6-8.

cms.cfgThe configuration file for the CMS and its processes, including bob (Dispatch Service), ted (Event Service), and vhs (Request Service).

NOTE: The cms.cfg file contains the configuration information for the Vignette Relationship Management Server if it is included in your VCMS installation.

Location

Windows

install-path\inst-name\conf\cms\cms.cfg

Solaris

install-path/vignette/inst-name/conf/cms/cms.cfg



Description

Each VCMS component maintains its own configuration information, both in the VCMS system database and in a component-specific configuration file. The CMS component consists of three processes: bob (Dispatch Service), ted (Event Service), and vhs (Request Service). The configuration information for each process is contained in the cms.cfg configuration file.


See also bob on page A-18, ted on page A-39, and vhs on page A-54.


cmscppapi.cfgA configuration file used by the VCMS CMS and C++ APIs to connect to processes with authentication and/or encryption enabled.

Location

Windows

install-path\inst-name\conf\cmscppapi\cmscppapi.cfg

Solaris

install-path/vignette/inst-name/conf/cmscppapi/cmscppapi.cfg



Description

The cmscppapi.cfg file contains configuration variables that allow VCMS APIs to connect securely to the VCMS processes.

See the Security Guide for a full description of cmscppapi.cfg.


config.logLogs any errors generated while configuring the VCMS components.

Location

Windows

install-path\6.0\config.log

Solaris

install-path/vignette/6.0/config.log

Description

The config program logs any errors to this file. You can increase the level of detail by specifying config -v.

See also config on page A-21.



ctld-id.#.infologOutput generated by the LOG template command.

Location

Windows

install-path\inst-name\logs\cds-name\ctld-id.#.infolog

Solaris

install-path/vignette/inst-name/logs/cds-name/ctld-id.#.infolog

Description

As a template is evaluated, the interpreter reads any instances of the LOG command, and sends the accompanying message to the infolog file for the appropriate ctld.

NOTE: The infolog files are named ctld-id.#.infolog, where id corresponds to the unique identifier for the ctld process, and # corresponds to the numbered slave process that generated the file.

The syntax is [LOG message]

See Debugging Templates with the LOG Template Command on page 6-12. See also the Tcl: Template Command Reference and Tcl: Template Cookbook.



ctld-id.#.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cds-name\ctld-id.#.log

Solaris

install-path/vignette/inst-name/logs/cds-name/ctld-id.#.log

Description

This log file contains the chronological list of transactions and errors for a ctld (Tcl Page Generator) process. The id in ctld-id.#.log corresponds to the unique identifier of the Application Engine (ape) to which the Tcl Page Generator belongs. For example, if an Application Engine is named ape-1, the log file for its Tcl Page Generator is named ctld-1.#.log.

NOTE: An Application Engine can contain only one Tcl Page Generator, one ASP Page Generator, and one JSP Page Generator.

The ctld process generates multiple log files because it spawns slave processes, each of which generates its own log file. Therefore, # in ctld-id.#.log corresponds to the numbered slave process that generated the file.





ctld-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cds-name/ctld-id.pid

Description

The pid file contains the process identification number for a ctld (Tcl Page Generator) master process. The id in ctld-id.pid corresponds to the unique identifier of the Application Engine (ape) to which the Tcl Page Generator belongs. For example, if an Application Engine is named ape-1, the pid file for its Tcl Page Generator is named ctld-1.pid.


ctld.tclA file containing template variables and procedures that are available to each Page Generator (ctld) individually. Each ctld process has its own local version of ctld.tcl.

Location

Windows

install-path\inst-name\conf\cds-name\ctld.tcl

Solaris

install-path/vignette/inst-name/conf/cds-name/ctld.tcl



Description

The ctld (Tcl Page Generator) calls two files (delivery.tcl and ctld.tcl) in order to initialize the Tcl interpreter with variables and procedures. If you want custom variables and procedures to be available to the Tcl interpreter, add them to one of these files. Whether you add the information to delivery.tcl or ctld.tcl depends on whether you want the variable or procedure to be available to all Tcl Page Generators on a machine or only to one Page Generator.

See Initialization Files for the Tcl Interpreter on page 6-5.

See also ctld on page A-21.

delivery.tclContains global information for the ctld (Tcl Page Generator) processes in a VCMS installation.

Location

Windows

install-path\inst-name\conf\delivery.tcl

Solaris

install-path/vignette/inst-name/conf/delivery.tcl

Description

The ctld (Tcl Page Generator) calls two files (delivery.tcl and ctld.tcl) to initialize the Tcl interpreter with variables and procedures. If you want custom variables and procedures to be available to the Tcl interpreter, you will edit these files to add them. Whether you add the information to delivery.tcl or ctld.tcl depends on whether you want the variable or procedure to be available to all Tcl Page Generators on a machine or only to one Page Generator.

See Initialization Files for the Tcl Interpreter on page 6-5. See also ctld on page A-21.



docrootContains on-line VCMS information that your web browser can access.

Location

Windows

install-path\6.0\docroot\

Solaris

install-path/vignette/6.0/docroot/

Description

The docroot directory contains a web-browsable set of VCMS 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.

For information on file location variables, see Common Path Name Variables on page 1-5.

host.cfgContains configuration information for the local host.

Location

Windows

install-path\inst-name\conf\host.cfg

Solaris

install-path/vignette/inst-name/conf/host.cfg



Description

This file contains host-specific configuration variables for the VCMS. To learn more about the configuration variables within this file, see the Configuration Reference.

insts.cfgAn internal file that contains information about each VCMS component and process installed on the local host.

Location

Windows

install-path\insts.cfg

Solaris

install-path/insts.cfg

Description

This internal file should not be edited by administrators because the VCMS automatically generates and updates the values within it. The VCMS uses this file when performing configuration tasks.



jsp-id.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cds-name\jsp-id.log

Solaris

install-path/vignette/inst-name/logs/cds-name/jsp-id.log

Description

The log file contains the chronological list of transactions and errors for this JSP Page Generator. The id in jsp-id.log corresponds to the unique identifier of the ape (Application Engine) to which the JSP Page Generator belongs. For example, if an Application Engine is named ape-1, the log file for its JSP Page Generator is named jsp-1.log.

NOTE: An Application Engine can contain one Tcl Page Generator, one ASP Page Generator, and one JSP Page Generator.





jsp-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cds-name/jsp-id.pid

Description

The pid file contains the process identification number for the JSP Page Generator process. The id in jsp-id.pid corresponds to the unique identifier of the ape (Application Engine) to which the JSP Page Generator belongs. For example, if an Application Engine is named ape-1, the pid file for its JSP Page Generator is named jsp-1.pid.




manifestA manifest file exists for the CDS, OMS, and MCS components. It lists the subcomponents that are configured on the local host.

Location

Description

Each line of the manifest file contains the name of a VCMS subcomponent or process and its configuration ID. The VCMS uses the manifest file to determine the subcomponents and processes that it needs to start on the local host.

NOTE: The manifest file for the OMS and MCS components contains the configuration ID for the vwd (Watchdog) process. The configuration IDs for the other OMS and MCS processes are contained in their configuration files. See the Configuration Reference for details.

Component Path to manifest file

CDS WINDOWS install-path\inst-name\conf\cds-name\manifest

SOLARIS install-path/vignette/inst-name/conf/cds-name/manifest

OMS WINDOWS install-path\inst-name\conf\oms-name\manifest

SOLARIS install-path/vignette/inst-name/conf/oms-name/manifest

MCS WINDOWS install-path\inst-name\conf\mcs-name\manifest

SOLARIS install-path/vignette/inst-name/conf/mcs-name/manifest



mcd-id.deliver.logThis file is the delivery log for an mcd process.

Location

Windows

install-path\inst-name\logs\mcs-name\mcd-id.deliver.log

Solaris

install-path/vignette/inst-name/logs/mcs-name/mcd-id.deliver.log

Description

The mcd-id.deliver.log file contains the addresses and channels for each delivery made by an mcd (Multi-Channel Delivery Agent) process.

The id in mcd-id.deliver.log corresponds to the unique identifier for the mcd process. For example, if you have a Multi-Channel Delivery Agent named mcd-1, the corresponding delivery log is named mcd-1.deliver.log.



mcd-id.#.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\mcs-name\mcd-id.#.log

Solaris

install-path/vignette/inst-name/logs/mcs-name/mcd-id.#.log

Description

This log file contains the chronological list of transactions and errors for an mcd (Multi-Channel Delivery Agent) process. The id in mcd-id.#.log corresponds to the unique identifier for the mcd process. For example, if you have a Multi-Channel Delivery Agent named mcd-1, the corresponding log file is named mcd-1.#.log.

The mcd process generates multiple log files because it spawns slave processes, each of which generates its own log file. Therefore, the # in mcd-id.#.log corresponds to the numbered slave process that generated the file. It is within these files that the plug-in modules report on their delivery status.

The logging plug-in module also creates a log file. If you install the logging plug-in as plugin-2, the log file appears in the following directory:

install-path/vignette/inst-name/logs/mcs-name/plugin-2/





mcd-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/mcs-name/mcd-id.pid

Description

The pid file contains the process identification number for an mcd (Multi-Channel Delivery Agent) master process. The id in mcd-id.pid corresponds to the unique identifier for the mcd process. For example, if you have a Multi-Channel Delivery Agent named mcd-1, the corresponding pid file is named mcd-1.pid.


mcs.cfgThe configuration file for the MCS and its processes, including the mcd (Multi-Channel Delivery Agent), plugin (Delivery Channel Plug-in), and vwd (Watchdog).

Location

Windows

install-path\inst-name\conf\mcs-name\mcs.cfg

Solaris

install-path/vignette/inst-name/conf/mcs-name/mcs.cfg



Description

Each VCMS component maintains its own configuration information, both in the VCMS system database and in a component-specific configuration file. The MCS component consists of multiple processes. The configuration information for each process is contained in the mcs.cfg configuration file.



See mcd on page A-34, vrd on page A-54, and vwd on page A-55.

messagesSolaris only. Tracks errors and messages for log levels 1 and 2.

Location/var/adm/messages

Description

The messages file logs errors and messages managed by the syslogd(1M) process on Solaris.

See Viewing VCMS Log Information on page 6-10.



metafilesA directory containing binary versions of the browser capabilities of corresponding templates.

Windows

install-path\inst-name\working\cds-name\metafiles\

Solaris

install-path/vignette/inst-name/working/cds-name/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

For a discussion of browser capabilities, see the Production Center Guide.

See templates-id on page B-43. See also tmd on page A-40 and ctld on page A-21.


metatemplates-idA directory containing meta-data for corresponding templates.

Windows

install-path\inst-name\working\cds-name\metatemplates-id\

Solaris

install-path/vignette/inst-name/working/cds-name/metatemplates-id/



Description

The metatemplates-id 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:


The tmd (Template Manager) process uses the files in the metatemplates-id directory to update the meta-data for templates. The id in metatemplates-id corresponds to the unique identifier of the Application Engine that contains the tmd process. For example, if an Application Engine is named ape-1, the metatemplates directory for its Template Manager is named metatemplates-1.

See tmd on page A-40. For information on file location variables, see Common Path Name Variables on page 1-5.

obj.conf.vgnbakA backup copy of the NSAPI configuration file for an iPlanet web server.

Location

Windows

install-path\inst-name\working\ws-name\obj.conf.vgnbak

Solaris

install-path/vignette/inst-name/working/ws-name/obj.conf.vgnbak



Description

The obj.conf.vgnbak file provides a backup copy of obj.conf in order to preserve web server mappings before making VCMS modifications.


The file is a copy of the:

WINDOWS ws-install-path\ws-instance\config\obj.conf

SOLARIS ws-install-path/ws-instance/config/obj.conf

file, where:

ws-install-path

Specifies the directory where you installed the iPlanet web server software.

ws-instance

Specifies the directory for the web server instance configured with the VCMS software.

omd-id.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\oms-name\omd-id.log

Solaris

install-path/vignette/inst-name/logs/oms-name/omd-id.log



Description

This log file contains the chronological list of transactions and errors for an omd (Observation Manager) process. The id in omd-id.log corresponds to the unique identifier for the omd process. For example, if you have an Observation Manager named omd-1, the corresponding log file is named omd-1.log.



omd-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/oms-name/omd-id.pid

Description

The pid file contains the process identification number for an omd (Observation Manager) process. The id in omd-id.pid corresponds to the unique identifier for the omd process. For example, if you have an Observation Manager named omd-1, the corresponding pid file is named omd-1.pid.




oms.cfgThe configuration file for the OMS and its processes, including the vrd (Router), omd (Observation Manager), cld (Campaign Logging Agent), and vwd (Watchdog).

Location

Windows

install-path\inst-name\conf\oms-name\oms.cfg

Solaris

install-path/vignette/inst-name/conf/oms-name/oms.cfg

Description

Each VCMS component maintains its own configuration information, both in the VCMS system database and in a component-specific configuration file. The OMS component consists of multiple processes. The configuration information for each process is contained in the oms.cfg configuration file.



See vrd on page A-54, omd on page A-34, cld on page A-20, and vwd on page A-55.



pad.#.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cds-name\pad.#.log

Solaris

install-path/vignette/inst-name/logs/cds-name/pad.#.log

Description

This log file contains the chronological list of transactions and errors for a pad (Placement Agent) process. The pad process generates multiple log files because it spawns slave processes, each of which generates its own log file. Therefore, the # in pad.#.log corresponds to the numbered slave process that generated the file.





pad.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cds-name/pad.pid

Description

The pid file contains the process identification number for the pad (Placement Agent) master process. For more information, see log Files and pid Files on page 6-8.

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 VCMS Tools session.

Description

The VCMS Tools generate and update the Preferences file when you:

• Start a VCMS Tools session by logging in. The VCMS tools automatically save your login information each time you log in and also save the last CMS accessed as the default for your next log in.

• Save your preferences by using the Preferences option in the File menu of the VCMS Tools launch bar.



The file is updated each time you change your selection. You should not edit this file manually. For more information on using the VCMS launch bar to set your browser preferences, see the section on setting browser preferences in Running the Vignette Content Management Tools.

NOTE: The location of the on-line documentation is set during configuration of a development CDS. If no development CDS can be found, the VCMS on-line documentation defaults to the Vignette on-line location.

By default, the VCMS Tools store your Preferences file in the Vignette subdirectory in your home directory.

security.cfgThe VCMS Tools client stores its security configuration information locally in the security.cfg file.

Location

Windows

install-path\Vignette\Tools\6.0\lib\security.cfg

Description

The VCMS software creates a default copy of security.cfg in the directory shown above. If any changes are made to the file, the altered version of the file is stored in the Vignette subdirectory in your home directory. The default copy does not change.

NOTE: If the VCMS software is not able to write security.cfg to the home directory, it will overwrite the default copy of security.cfg in the 6.0\lib\ directory.

When the client tools read in security information, they will first look in the Vignette subdirectory in your home directory. If no security.cfg file is found there, the tools will look for the default copy of the file in the 6.0\lib\ directory shown above.



The contents of security.cfg are not encrypted, however; any client keys that have been encrypted with passwords appear here only in their encrypted form.

For more information about client tools security, see the Security Guide.

staticfilesContains the working copy of the static files that the vhs (Request Service) has processed. In pre-5.0 releases, this directory was called VhsProtoDocRoot.

Location

Windows

install-path\inst-name\working\cms\staticfiles\

Solaris

install-path/vignette/inst-name/working/cms/staticfiles/

Description

The staticfiles directory contains files being processed by vhs.

Each time a user adds a static content file (any content that doesn’t reside in the database) via the Submit File option of the Project Manager File command, the VCMS software creates the file in the CMS’s staticfiles directory.

The CMS then distributes copies of new files to the docroots of the web servers configured with the development CDSs. When a launch occurs, the CMS distributes the associated static files to the live CDS web server docroots.

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 staticfiles. The file is also propagated to development CDSs if it has not been launched and to live CDSs if it has already been launched.

TIP: If you add static files other than through the Project Manager, the VCMS software does not know about them. You should copy these files to the CDSs according to the type of the CDS. For example, copy files from the docroot of a development CDS’s web server to the docroot of another development CDS’s web server to avoid exposing files in progress on a live CDS.


See also vhs on page A-54.

ted.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cms\ted.log

Solaris

install-path/vignette/inst-name/logs/cms/ted.log



Description

The log file contains the chronological list of transactions and errors for the ted (Event Service) process. For more information, see log Files and pid Files on page 6-8.


ted.pidSolaris only. On Solaris, every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cms/ted.pid

Description

The pid file contains the process identification number for the ted (Event Service) process. For more information, see log Files and pid Files on page 6-8.



tedtasksworkingdirContains working files for the ted (Event Service) process.

Location

Windows

install-path\inst-name\working\cms\tedtasksworkingdir

Solaris

install-path/vignette/inst-name/working/cms/tedtasksworkingdir

Description

The tedtasksworkingdir directory contains files being processed by the ted (Event Service) process.

See also ted on page A-39.


templates-idTemplate cache written by the tmd (Template Manager) process and read by the Page Generator process.

Location

Windows

install-path\inst-name\working\cds-name\templates-id\

Solaris

install-path/vignette/inst-name/working/cds-name/templates-id/



Description

The templates directory is the template cache written by the Template Manager process and read by the Page Generator process. The cache contains files with names corresponding to template locations.

The template ID for each template is represented as a file. Each template path is also represented as a file with %2f (the URL encoding of the ASCII character /) being used instead of / in the directory path name, for example:


See metafiles on page B-32.

NOTE: The VCMS includes a separate templates directory for each Application Engine. The id in templates-id corresponds to the unique identifier for the associated Application Engine.


tmd-id.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cds-name\tmd-id.log

Solaris

install-path/vignette/inst-name/logs/cds-name/tmd-id.log



Description

This log file contains the chronological list of transactions and errors for a tmd (Template Manager) process. The id in tmd-id.log corresponds to the unique identifier of the ape (Application Engine) to which the Template Manager belongs. For example, if an Application Engine is named ape-1, the log file for its Template Manager is named tmd-1.log.

NOTE: An Application Engine can contain only one Template Manager.



tmd-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cds-name/tmd-id.pid

Description

The pid file contains the process identification number for the tmd (Template Manager) process. The id in tmd-id.pid corresponds to the unique identifier of the ape (Application Engine) to which the Template Manager belongs. For example, if an Application Engine is named ape-1, the pid file for its Template Manager is named tmd-1.pid.




upgrade.logLogs any errors generated while upgrading to the VCMS components.

Location

Windows

install-path\6.0\upgrade.log

Solaris

install-path/vignette/6.0/upgrade.log

Description

The upgrade program logs any errors to this file. The upgrade program logs errors in verbose mode by default. You can decrease the level of detail by specifying upgrade -n.

UsrMacroData.xmlContains the custom macros created by users of the Macro Editor within the Vignette Development Center.

Description

The Vignette Development Center generates and updates the UsrMacroData.xml file when a user:

• Creates the first custom macro.

• Changes any of his or her custom macros.

By default, the Vignette Development Center stores the UsrMacroData.xml file in the Vignette subdirectory in the home directory of the Vignette Development Center user.



vhs.#.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\cms\vhs.#.log

Solaris

install-path/vignette/inst-name/logs/cms/vhs.#.log

Description

This log file contains the chronological list of transactions and errors for a vhs (Request Service) process.The vhs process generates multiple log files because it spawns slave processes, each of which generates its own log file. Therefore, the # in vhs.#.log corresponds to the numbered slave process that generated the file.





vhs.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/cms/vhs.pid

Description

The pid file contains the process identification number for the vhs (Request Service) master process. For more information, see log Files and pid Files on page 6-8.

vrd-id.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension.

Location

Windows

install-path\inst-name\logs\oms-name\vrd-id.log

Solaris

install-path/vignette/inst-name/logs/oms-name/vrd-id.log



Description

This log file contains the chronological list of transactions and errors for a vrd (Router) process. The id in vrd-id.log corresponds to the unique identifier for the vrd process. For example, if you have a Router named vrd-1, the corresponding log file is named vrd-1.log.



vrd-id.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/oms-name/vrd-id.pid

Description

The pid file contains the process identification number for a vrd (Router) process. The id in vrd-id.pid corresponds to the unique identifier for the vrd process. For example, if you have a Router named vrd-1, the corresponding pid file is named vrd-1.pid.




vwd.logEach of the VCMS processes may generate its own log file, depending on the setting of the LOG_LEVEL configuration variable. The generated log files are named according to the process for which they hold data, and include a .log extension. The vwd (watchdog) process exists on any machine that maintains any process of the OMS or MCS.

OMS Location

Windows

install-path\inst-name\logs\oms-name\vwd.log

Solaris

install-path/vignette/inst-name/logs/oms-name/vwd.log

MCS Location

Windows

install-path\inst-name\logs\mcs-name\vwd.log

Solaris

install-path/vignette/inst-name/logs/mcs-name/vwd.log

Description

This log file contains the chronological list of transactions and errors for the vwd (Watchdog) process.





vwd.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension. The vwd (watchdog) process exists on both the OMS and MCS components.

OMS Location

Solaris

install-path/vignette/inst-name/logs/oms-name/vwd.pid

MCS Location

Solaris

install-path/vignette/inst-name/logs/mcs-name/vwd.pid

Description

The pid file contains the process identification number for the vwd (watchdog) process. For more information, see log Files and pid Files on page 6-8.



ws.cfgThe configuration file for the VCMS ws (web server) module.

Location

Windows

install-path\inst-name\conf\ws-name\ws.cfg

Solaris

install-path/vignette/inst-name/conf/ws-name/ws.cfg

Description

Each VCMS component maintains its own configuration information, both in the VCMS system database and in a component-specific configuration file.





ws.logThe log file for the VCMS ws (web server) module.

Windows

install-path\inst-name\logs\ws-name\ws.log

Solaris

install-path/vignette/inst-name/logs/ws-name/ws.log

Description

This log file contains the chronological list of transactions and errors for a ws (web server) module. The level of logging is set in the LOG_LEVEL configuration variable. See the Configuration Reference for more information about the LOG_LEVEL variable.


ws.pidSolaris only. On Solaris every process has its own pid file. The files are named according to the process for which they hold data, and include a .pid extension.

Location

Solaris

install-path/vignette/inst-name/logs/ws-name/ws.pid

Description

The pid file contains the process identification number for a ws (web server) process. For more information, see log Files and pid Files on page 6-8.


C System Database Tables

Summary: A list of the Vignette® Content Management Server V6 (VCMS) system database tables with short descriptions of each.

Audience: Administrators and DBAs for the VCMS

Topics include: VCMS System Database Tables

August 2001 Vignette Confidential C-1

System Database Tables Administration Guide

VCMS System Database TablesThe VCMS software creates, maintains, and manages its own tables in the database, including tables for the CDSs and for the CMS. (The table names are the same for both Windows and Solaris operating systems.)

The following table shows the tables and briefly describes their use.

NOTE: If you have a single VCMS login to the database, a user or process with that login can access all tables. If you have configured a separate login for accessing content tables, that user or process will not be able to access the following tables. See Configuring a Second Login for the Template Environment on page 7-8.

Table Name Description

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

template Stores all templates

template_v Version information for the templates. This table is created dynamically when the first template version is created.

template_path Stores template paths

template_path_v Version information for the template paths. This table is created dynamically when the first template version is created.

vgn_ag Stores all content groups for the Vignette® Relationship Management Server V6 (VRMS) product. See the Business Center Guide.

vgn_ag_membership Associates manual content groups with content items for the Vignette Relationship Management Server. See the Business Center Guide.

vgn_asset_group_impl Specifies dll or shared libraries used by implied content groups. The cgutil program task configures the table. See the Business Center Guide.

vgn_asset_type Stores all available content types for the Vignette Relationship Management Server. The cgutil program task configures the table. See the Business Center Guide.

vgn_bz Stores an entry for each Business Center role user. See the Business Center Guide.

C-2 Vignette Confidential August 2001

Administration Guide System Database Tables

vgn_campaign_metric_map Associates Vignette Relationship Management Server campaigns with registered metrics. See the Business Center Guide.

vgn_cc Stores personalization content catalog information

vgn_cf Contains VCMS configuration information

vgn_cfgdef The vgn_cfg* tables manage the configuration path hierarchy.

vgn_cfgnode

vgn_cfgrel

vgn_cfgspc

vgn_cfgval

vgn_cfgvar

vgn_channels Contains all available delivery channels for the Vignette Relationship Management Server. See the Business Center Guide.

vgn_ci Contains production management information for templates, files, content records

vgn_cld_files Contains a list of all files generated by the Campaign Logging Agent (an OMS process) and a timestamp for each file. See the Business Center Guide.

vgn_context_default Stores behavior data collected for each visitor to your site. Includes context ID, visitor ID, date created, and date of last access.

See the discussion of Visitor Context commands in the Visitor Services Guide.

vgn_context_info Stores namespace information and expiration policy information applicable to all visitor context objects.

See the discussion of Visitor Context commands in the Visitor Services Guide.

vgn_cp Stores data about Vignette Relationship Management Server campaigns, such as campaign name, owner, description, status, and start/stop information. See the Business Center Guide.

vgn_dbconfig Holds internal information about CMS classes and objects




vgn_disabled A table of disabled users. See the User Security chapter of the Security Guide.

vgn_failed_file_operations Contains a list of any failed file operations attempted by the pad (Placement Agent), with the operation name and a datestamp.

vgn_features Contains the list of browser features

vgn_feedback Contains metric counts for Vignette Relationship Management Server campaigns. Information includes rule ID, trigger ID, and metric ID. See the Business Center Guide.

vgn_groups Stores VCMS groups

vgn_groupassoc Associates users with groups

vgn_history Contains history for the content items. See the Production Center Guide.

vgn_kr Stores personalization keyword registry information

vgn_metrics Contains a list of registered metrics for Vignette Relationship Management Server campaigns. Information includes metric ID and a counter. See the Business Center Guide.

vgn_password_history Stores user password history.

vgn_plock Contains persistent lock information for CMS objects

vgn_pr Contains project management information

vgn_roles Stores VCMS roles

vgn_roleassoc Associates users with roles

vgn_rule_trigger_map Associates rules with events. See the Business Center Guide.

vgn_rules Stores data contained in each rule for Vignette Relationship Management Server campaigns. Information includes rule ID, campaign ID, channel ID, segment ID, content type, and style. See the Business Center Guide.

vgn_scratch Provides a temporary working area for the CMS

vgn_sg Contains a list of available visitor segments. Information includes segment ID, name, description, and visitor count. See the Business Center Guide.



Administration Guide System Database Tables

vgn_sg_map_1 Associates visitors with visitor segments. See the Business Center Guide. When this table is in use, data is loaded into vgn_sg_map_2.

vgn_sg_map_2 Associates visitors with visitor segments. See the Business Center Guide. When this table is in use, data is loaded into vgn_sg_map_1.

vgn_sg_map_info Location information for visitor segments imported from the netCustomer web server. See the Business Center Guide.

vgn_style_templates Contains a list of all templates created to implement campaign styles. Information includes content type, style ID, channel ID, and template ID. See the Business Center Guide.

vgn_styles Contains a list of all available campaign styles, by ID and name. See the Business Center Guide.

vgn_submitted_files Contains a list of all files submitted to the file system through the CMS. Information includes path, live/dev status, and submit date.

vgn_task_trigger_map Associates campaign events with tasks. See the Business Center Guide.

vgn_tk Contains task management information

vgn_triggers Contains a list of all registered events for Vignette Relationship Management Server campaigns. Information includes event name and how many campaigns are configured to use the event as a trigger. See the Business Center Guide.

vgn_uc Stores personalization profile-marker-by-user information

vgn_ur Stores personalization user registry information

vgn_users Stores VCMS users

vgn_variations_map Maps templates to sets of browser features

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

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




vgn_xmlattrs The vgn_xml* tables are for XML persistent storage.

vgn_xmlbcodes

vgn_xmlcolls

vgn_xmldocs

vgn_xmlids

vgn_xmlnames

vgn_xmltags

vgn_xmltexts

See also: Database Access on page 7-5



D Configuring the VCMS Software to Use an LDAP User Repository

Summary: Describes how to configure the Vignette® Content Management Server V6 (VCMS) software to use an existing lightweight directory access protocol (LDAP) user repository for VCMS user and group administration.

Audience: VCMS and LDAP administrators who want to use LDAP to manage VCMS users, roles, and groups

Before you begin: For information about VCMS roles, see:

• Chapter 5, Managing VCMS Users, Groups, and Roles• Production Center Guide

For detailed information about LDAP, see the following links and books (among others):

• http://docs.iplanet.com/docs/manuals/directory.html#dirserver413

• http://developer.netscape.com/docs/manuals/index.html

• LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol, by Timothy A. Howes and Mark C. Smith

• Understanding and Deploying LDAP Directory Services, by Timothy A. Howes, Mark C. Smith, and Gordon S. Good

August 2001 Vignette Confidential D-1

Configuring the VCMS Software to Use an LDAP User Repository Administration Guide

Topics include: • Overview• Understanding How the VCMS Software Integrates with

LDAP• Setting up LDAP SSL Certificates and Keys• Making LDAP Schema and Database Changes• Making Configuration Changes• LDAP and Internationalization• Configuring the VCMS Software to Use LDAP• Using LDAP Configuration (for Windows Users)• Using the config Command (for Windows and Solaris Users)• Things to Do After Configuring the VCMS Software to Use

LDAP

D-2 Vignette Confidential August 2001

Administration Guide Configuring the VCMS Software to Use an LDAP User Repository

OverviewIf you are currently using LDAP as a repository for storing user and group information, you can configure the VCMS software to exploit your LDAP repository.

NOTE: The VCMS installation is not a reason to begin using an LDAP server for user and group administration. LDAP configuration and administration require a lot of planning and resources. You should decide to use LDAP for business reasons other than as a way to manage users and groups for the VCMS installation; the VCMS software provides its own user and group administration functions.

This appendix explains how to configure the VCMS software to use an existing LDAP user and group repository for user and group administration, so that you obtain the benefits of LDAP while using the VCMS software to create and manage your web site.

This appendix does not explain LDAP. For background information, there are many books about LDAP. For example:

• LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol by Timothy A. Howes and Mark C. Smith

• Understanding and Deploying LDAP Directory Services by Timothy A. Howes, Mark C. Smith, and Gordon S. Good

The LDAP Configuration. the VCMS software provides you with the LDAP Configuration (both a GUI and a command-line version) to perform the actual configuration. There are several steps you must perform before using the configuration tool, and things to be aware of after the configuration is complete.

Supported LDAP server. To find what version of the LDAP server the VCMS software supports, see the Vignette Content Management Server V6 Release Notes.

Roadmap. The following roadmap table outlines the steps required to configure the VCMS software to use LDAP.

NOTE: You must perform the pre-configuration steps; if you do not, the configuration fails.



Table D-1: Roadmap for configuration

Steps See

Pre-configuration

1 Understand how the VCMS software integrates with LDAP.

Understanding How the VCMS Software Integrates with LDAP on page D-5

2 Determine whether you want to make a secure or non-secure connection between LDAP and the VCMS software. If you want a secure connection, go to step 3. If not, go to step 4.

3 Set up LDAP SSL certificates and keys. Setting up LDAP SSL Certificates and Keys on page D-12

4 Make required schema and database changes to LDAP.

Making LDAP Schema and Database Changes on page D-17

5 Set the configuration variable EUR_ENABLE_AUTO_REGISTRATION to false.

Change the value of the CONNECT_RETRIES variable within the EUR_CONFIGURATION configuration variable, if desired.

Making Configuration Changes on page D-20

6 Understand LDAP and internationalization. LDAP and Internationalization on page D-21

7 Make sure the LDAP server is running and accessible to the VCMS software.

Configuration

8 Understand the flow of steps required to configure the VCMS software to use LDAP.

Configuring the VCMS Software to Use LDAP on page D-22

9 Configure the VCMS software to use LDAP using one of the following tools:

• The LDAP Configuration tool (Windows users only)

• config (a command-line interface for Windows or Solaris users)

• Using LDAP Configuration (for Windows Users) on page D-25

• Using the config Command (for Windows and Solaris Users) on page D-39

Post-configuration

10 Be aware of post-configuration issues. Things to Do After Configuring the VCMS Software to Use LDAP on page D-52



Understanding How the VCMS Software Integrates with LDAP

The VCMS software has its own external user repository (EUR), which the Content Management Server (CMS) manages. You can configure the VCMS software to use LDAP’s user repository instead of the VCMS EUR.

Once you configure the VCMS software to use LDAP:

• The VCMS EUR stores role definitions (name and description of role)• LDAP stores role associations (which users have which roles)

You perform user and group administration tasks with tools as follows:

Using the VCMS Software without LDAP

To understand how LDAP can be integrated with the VCMS software, you must first understand how the VCMS software manages users and groups without LDAP.

Without LDAP, the VCMS software has its own EUR, which the CMS component manages (although the EUR is external to the CMS). The EUR is the repository that contains all user and group information for the VCMS software.

Task Tool

Add, modify, and remove users LDAP clienta

a. It may be necessary to run the reseteur program task to cause the CMS to refresh its EUR cache, in order to see a newly-added LDAP group or user prior to the user logging in. When a user logs into the system, the user’s information (including role and group association) is refreshed. The most idiosyncratic case is when a new LDAP group won’t be available until a member of that group logs in (causing the group’s cache to update).

Add, modify, and remove groups

Associate users with groups

Associate roles with users VCMS User Manager

NOTE: It is also possible to associate roles with users through an LDAP client. You may have to restart the VCMS when you make a roles (or other) update through an LDAP client. See the table footnote.



The VCMS tools connect to the CMS through a pipe, secure or non-secure (depending on whether you configure the VCMS software with security). If it’s a secure pipe, it is secured on the client side with a VCMS tool client certificate, and on the server side with a CMS’ server certificate. Figure D-1 shows a secure connection between the VCMS tools and the CMS.

Figure D-1: The VCMS Software without LDAP (secure connection)

Using the VCMS Software with LDAP

Instead of using the CMS EUR to manage VCMS user and group information, you can use an existing LDAP user repository and then manage VCMS users and groups through an LDAP client. The rest of this appendix explains in detail how to do this. In simplest terms, you configure the VCMS software to use an LDAP user repository by using either:

• LDAP Configuration, a GUI (for Windows users only)• config, a command-line interface (for Windows or Solaris users)

VCMSTools

Client certificate

CMS

CMS EUR (external user

repository)

Secure pipe

Server certificate



When configuring the VCMS software to use LDAP, you must specify the type of connection you want between LDAP and the VCMS software. You have to perform different steps, depending on which type of connection you choose.

These are the types of connections you can have between LDAP and the VCMS software:

Making a Non-secure Connection to LDAP

A non-secure connection between LDAP and the VCMS software provides no security between LDAP and the VCMS software, but it is the easiest connection to set up. With this type of connection, you do not have to set up a server certificate on the LDAP server or a client certificate on the CMS. However, you still need to configure the VCMS software with a distinguished name (DN) and password pair that has write permissions to the roles attributes of the VCMS user entries.

NOTE: If you use a non-secure connection between the CMS and LDAP, be aware that the CMS:

1 Decrypts the encrypted user-level passwords it receives from the VCMS Tools, transforming them to clear text

2 Sends the clear-text passwords to LDAP

This connection is truly not secure!

Connection type See

Non-secure. This is the default. Making a Non-secure Connection to LDAP on page D-7

Secure without client authentication (no client certificate is required on the CMS).

Making a Secure Connection to LDAP without Client Authentication on page D-9

Secure with client authentication (a client certificate is required on the CMS).

Making a Secure Connection to LDAP with Client Authentication on page D-10



Figure D-2 shows a non-secure connection:

Figure D-2: Non-secure connection with LDAP

VCMSTools

Client certificate

CMS

Server certificate

LDAP

User repository

The VCMS software compares repositories and logs discrepancies


repository)

Secure pipe(SSL)

Non-secure pipe



Making a Secure Connection to LDAP without Client Authentication

To create a secure connection between LDAP and the VCMS software, you need to set up a server certificate on the server side (LDAP). The CMS becomes a client of LDAP. Because the CMS already has a server certificate, which it uses in the secure pipe between the VCMS tools and the CMS, you can use this as the client certificate for the secure pipe between LDAP and the CMS if the certificate authorities (CAs) are the same.

Figure D-3 shows a secure connection between LDAP and the CMS, which uses the DN and password combination as client authentication for the connection between LDAP and the CMS:

Figure D-3: Secure connection with LDAP without client authentication

VCMSTools

Client certificate Server certificate

CMS

Server and clientcertificate

LDAPUser

repository



repository)

Secure pipe(SSL)

Secure pipe(SSL)



Making a Secure Connection to LDAP with Client Authentication

Figure D-4 shows a CMS with two certificates. The server certificate on the CMS is a certificate used by the secure pipe between the VCMS tools and the CMS. The client certificate on the CMS is the certificate used by the secure pipe between LDAP and the CMS.

Figure D-4: Secure connection with LDAP with client authentication

VCMSTools

Client certificate Server certificate

CMS

LDAPUser

repository



repository)

Secure pipe(SSL)

Secure pipe(SSL)

Client certificate

Server certificate



Security Roadmap

Once you have decided on the type of connection you want between the VCMS software and LDAP, the following security roadmap table outlines the steps required to make each type of connection:

Steps See

Non-secure connection

1 Configure the VCMS software with a distinguished name (DN) and password pair that has write permissions to the roles attributes of VCMS user entries.

2 Accept the default (non-secure connection) when prompted through the configuration tool.


Secure connection without client authentication

1 Configure the VCMS software with a distinguished name (DN) and password pair that has write permissions to the roles attributes of VCMS user entries.

2 Set up LDAP Secure Sockets Layer (SSL) certificates and keys.

Setting up LDAP SSL Certificates and Keys on page D-12

3 Choose a secure connection when prompted through the configuration tool.


4 Specify SSL certificate information when prompted through the configuration tool.

5 Choose not to use client authentication when prompted through the configuration tool.

Secure connection with client authentication

1 Configure the VCMS software with a client certificate, which maps to a user entry that has write permissions to the roles attribute of VCMS user entries.

Setting up LDAP SSL Certificates and Keys on page D-12

2 Set up LDAP SSL certificates and keys.



Setting up LDAP SSL Certificates and Keys

Overview

The VCMS software uses the Netscape Communicator 4.x certificate and private key file as the storage mechanism for LDAP Secure Sockets Layer (SSL) certificates and keys.

For a secured connection, at a minimum, you must install a server certificate on the LDAP server. If you want client authentication, you must also obtain a client certificate for the CMS and configure the CMS with the client certificate.

3 Choose a secure connection when prompted through the configuration tool.


4 Specify SSL certificate information when prompted through the configuration tool.

5 Choose client authentication when prompted through the configuration tool.

6 Specify client authentication information.

Summary: If you choose to have a secure connection between LDAP and the VCMS software, you’ll have to set up the appropriate certificates and keys.

Topics include: • Overview• Getting a Certificate• Accepting a Certificate• Installing a Certificate

See also: For more information about certificates and keys and LDAP, see http://developer.iplanet.com/docs/manuals/security/SSO/index.htm

Steps See



For both client and server certificates, you must:

1 Obtain the certificates through any source, provided that source creates a certificate that Netscape can read.

The certificate authority (CA) from which you can obtain a certificate or certificates depends on whether you are operating within an intranet or an internet:

— If operating within an intranet, you can request a certificate from your own CA, if you have one set up internal to your organization.

— If operating within an internet, your certificate should probably be issued from a public CA for optimal security.

2 Accept and install the certificates through Netscape Communicator 4.x.

You should also be aware of the following security issues:

See also: Getting a Certificate on page D-14, for one way to obtain a certificate

See also: Accepting a Certificate on page D-16 and Installing a Certificate on page D-16

Issue Description

Anonymous access LDAP configuration does not require a user ID or password (when configured without SSL client authentication). A null user ID or password results in an anonymous bind to the LDAP server. It’s unlikely that you will want to have an anonymous account with write permissions to a portion of your LDAP data (such as the role association information), but you could configure LDAP for anonymous access.

Client authentication Configuring SSL client authentication is difficult. Aside from using Netscape Communicator to load up the cert7.db and key3.db files, you have to:

• Configure the LDAP server to recognize the CA certificate of the client certificate used for authentication

• Configure the LDAP server to map pieces, parts, or the whole of the DN inside the client certificate to a valid LDAP entry with appropriate permissions for the VCMS software

Also, if you select SSL and then client authentication, you won’t be prompted for a DN and password with which to bind to LDAP because SSL client authentication is a higher level of security and is used instead of user ID and password authentication.



Getting a Certificate

You don’t need to get a certificate through Netscape. You can get a certificate from any source, provided that source creates a certificate that Netscape can read.

The following example shows you one way to obtain a certificate.

■ To obtain a server or client certificate:

1 Open Netscape Communicator (version 4.x).

2 In the Netscape Navigation Toolbar, click the Security button.

Certificate and key file formats used by Netscape LDAP servers

Netscape LDAP servers don’t use the same certificate and key file formats as Netscape Communicator. If you are using a Netscape LDAP server, you cannot use the same cert7.db and key3.db files for your LDAP server and your VCMS LDAP configuration; in other words, you must still use Netscape Communicator (4.x) to populate the cert7.db and key3.db files with which to configure the VCMS software to use LDAP.

Issue Description



Figure D-5: Security Info

3 In the Security Info page, select Certificates -> Yours.

The Your Certificates page is displayed.

4 Click Get a Certificate.

Once you have obtained a certificate, you must accept and install it. See the next section, Accepting a Certificate.



Accepting a Certificate

■ To accept the certificate and install it in the Netscape database:

1 Open Netscape Communicator (version 4.x).

2 In the Go to: field, type the name of the web server where the certificate you want to accept and install resides. Include the certificate name.

For example, if the certificate resides on the web server named seven and the certificate name is vign_ca_cert.cacer, you would type:

http://seven/vign_ca_cert.cacer

NOTE: No matter how you obtained the certificate, it must be of the mime type application/x-x509-ca-cert, which has a special meaning for Netscape Communicator 4.x.

3 On the New Certificate Authority window, click Next.

Once you have followed the process for accepting the certificate, you must install it in a place accessible by LDAP. See the next section, Installing a Certificate.

Installing a Certificate

■ To install a certificate:

1 Shut down Netscape Communicator.

2 Copy the cert7.db and key3.db files from the Netscape Communicator directory into a location convenient for LDAP configuration.

3 Ensure that the cert7.db and key3.db files provide read permissions to whatever user the CMS is configured to run as (for example, nobody).



Making LDAP Schema and Database ChangesBefore you use either the LDAP Configuration tool or config command to configure the VCMS software to work with LDAP, you must make changes to your LDAP schema, database, and database indexes.

Schema Changes

You must make changes to your LDAP schema so that LDAP can save roles for users.

At a minimum, it is recommended that you:

1 Create a new objectClass (perhaps named VgnUser) with a single required, multi-valued attribute (perhaps named roles).

NOTE: The roles attribute is required, but the attribute does not require an entry. For example, the default VCMS installation creates a guest user with no roles defined. You can import this guest user into LDAP as long as it has a roles attribute (even though the contents of this attribute will be empty).

2 Make this new objectClass (VgnUser) a subclass of your main person objectClass; for example, VgnUser inherits from Person (or organizationalPerson).

3 Export all users who are VCMS users and add them back in to LDAP with the VgnUser objectClass.

4 Configure LDAP to look for users with the VgnUser objectClass.



Alternately, you could simply add a multi-valued roles attribute to the user's entry in LDAP. For example, if the user’s entry in LDAP is named person, add a roles attribute to the person objectClass. This roles attribute takes one or more role values from the valid roles in the VCMS installation:

• System• Developer• Business Center Full• Business Center Limited

See the example shown in Figure D-6.

Figure D-6: Required LDAP schema change

Database Changes

Once you have made the schema change described in Schema Changes on page D-17, you must also ensure that you have one user in LDAP with a name of admin and a roles attribute of System, so that this user can administer other users. See Figure D-7.

You must also ensure that the users, groups, user-to-group associations, and user-to-role associations defined in the VCMS EUR match corresponding LDAP entries.

See also: Roles Authorization on page 5-5

See also: Managing Users for a New Installation on page 5-4

objectClass = personname = Ella Fitzgeraldroles = developer, system. . .



Figure D-7: Minimum required user in LDAP

NOTE: You can also set up all the user-roles associations through LDAP at this stage, or you can create the user-roles associations after you have performed the configuration.

Finally, you must ensure that the LDAP repository does not have a group name that is the same as a user name; for example, you can’t have an Admin user and an Admin group.

NOTE: Be aware that in LDAP, attribute names are often case-insensitive. To guarantee the uniqueness of names, make sure you set attribute names to be case-sensitive.

Once you have migrated to LDAP, you maintain groups through an LDAP client rather than through the VCMS software. Consequently, the VCMS software cannot enforce this requirement. So you, or your LDAP administrator, must make this check.

Index Changes

LDAP performance is largely governed by the configuration of indexes on the customer side; for example, you should configure indexes for:

• The roles attribute• The group’s name attribute• The user’s login attribute

objectClass = personname =adminroles=system. . .



Making Configuration Changes

The EUR_ENABLE_AUTO_REGISTRATION configuration variable. Before configuring the VCMS software to use LDAP, make sure the VCMS configuration variable EUR_ENABLE_AUTO_REGISTRATION is set to false, and remains false. EUR_ENABLE_AUTO_REGISTRATION is a variable that takes a Boolean value that determines whether a new user who is unknown to the VCMS software can log in to the CMS and automatically be added as a new user.

The default for new installations is false. Upgrade installations retain their current setting for auto-registration; that is, if auto-registration is enabled, that setting is retained during the upgrade to 6.0. If the VCMS software is configured for LDAP, EUR_ENABLE_AUTO_REGISTRATION is set to false, and should remain false.

Set this variable at the process level for the bob process. Set it before LDAP configuration; do not alter it after configuration.

CONNECT_RETRIES (entry of EUR_CONFIGURATION). The VCMS software includes a configuration variable called EUR_CONFIGURATION that you can use to describe information needed to access the user information repository. One of the variables you can set within EUR_CONFIGURATION is CONNECT_RETRIES, which identifies the number of times the VCMS software attempts each LDAP operation before returning an error. The default value of CONNECT_RETRIES is 3.

During an LDAP operation, if an operation fails because of an invalid LDAP connection handle, the LDAP EUR immediately tries to reconnect using the original bind information (user ID and password, or certificate information).

If the value of Search Timeout is non-zero (see Step 7: Setting up the LDAP Server on page D-33), then the maximum time that the VCMS software allows any particular operation before an absolute failure occurs is:

CONNECT_RETRIES * Search Timeout value = maximum time

If Search Timeout is set to 0 (this indicates infinite search times), then the VCMS software cannot determine the maximum time on the client side because server-side timeouts dictate when an operation will time out.

See also: Configuration Reference for information about editing configuration variables



LDAP and InternationalizationLDAP reads and writes information in UTF-8-encoded format. The Vignette Content Management Server (VCMS) also processes data in UTF-8-encoded format to support internationalization. Consequently, you can pass multilingual data, including multibyte data, to and from any LDAP server.

During LDAP configuration, you can specify a language preference when setting up the base queries that the CMS uses to access EUR information. Specifically, you can add an internationalization modifier to any DN template in the LDAP configuration script by adding a semi-colon (;), a lang specifier, a separator (-), and the language (and optional territory identifier).

To do this, use the ISO two-character format. For example, the following is valid:

CN;lang-fr-FR=<#>,OU=engineering,O=vignette,C=US

This specifies that any query involving the common name (CN) of a user should look for the French version of that name only.

NOTE: If you specify a language preference for a query, the LDAP server searches for entries that match that value specifier only. If other values in another language or an unspecified language exist, the LDAP server does not return them.

NOTE: Language specifiers are relatively new. Not all LDAP servers support them. The VCMS uses them if the LDAP EUR is configured to use them, but they only work if the underlying LDAP server supports them.

An LDAP client may use language codes in search filters and attribute lists. For example, an LDAP client may limit its search to only those attributes in the specific language it is interested in, and it may request that only specific languages be returned by specifying language codes in the list of attributes to be returned.

NOTE: There is no way to retrieve all dialects of a particular language code. For example, the attribute type cn;lang-en is not the same as the attribute type cn;lang-en-US. You must specifically request each dialect. In general, avoid the use of dialects.

See also: Configuration Reference, for more information about these configuration variables.



Attributes with language codes are treated as subtypes of attributes without language codes. For example, the attribute cn;lang-en is a subtype of the attribute cn. When you request the cn attribute, the server retrieves all language code variations of the cn attribute.

Configuring the VCMS Software to Use LDAPNo matter which configuration tool you choose—LDAP Configuration (a GUI available to Windows users only), or config (a command-line interface available to Windows and Solaris users)—you must follow the steps outlined in Figure D-8 to configure the VCMS software to use an LDAP user repository.



Figure D-8: Flow of steps to configure the VCMS software to use LDAP

STEP 1: Perform prerequisites

STEP 2: Choose secure or

non-secure connectionwith LDAP

STEP 3: Specify SSL certificate information

STEP 4:Choose client authentication

or not

STEP 5: Supply client

authentication information

STEP 6: Provide LDAP access information

non-secure

secure

client authentication

no client authentication

STEP 7: Provide LDAP server information

STEP 8: Provide user query information

STEP 9: Provide user attribute information

STEP 10: Provide group query information

STEP 11: Provide group attribute information

STEP 12: Verify the LDAP user repository

VCMS site configuredto use LDAP

Differences logfile generated

Fixdifferences

Success



If you choose not to use a secure connection between the VCMS software and LDAP, you’ll have fewer steps. The steps outlined in Figure D-8 correspond to the headings in the following sections.

Reconfiguration. You can change the VCMS software/LDAP configuration after an initial configuration. Reconfiguration lets you:

• Switch from a non-secure connection to a secure connection, and vice versa. Also, switch from a secure connection without client authentication to one with client authentication, and vice versa.

• Change any or all of the LDAP host information, which means you can change to a different LDAP vendor’s product.

NOTE: The verification step (see Step 12: Performing Repository Verification on page D-36) always verifies the LDAP user repository against the VCMS EUR, even if you are already configured to use an LDAP user repository. Subsequent configurations do not cause the VCMS software to compare one LDAP user repository to another.



Using LDAP Configuration (for Windows Users)

Overview

Through the LDAP Configuration, you:

• Set up the connection—non-secure or secure—between the VCMS software and LDAP. If you choose a secure connection, you can choose a client-authenticated connection or a non-client-authenticated connection. If you want a secured connection, you are prompted for security information.

• Set up LDAP access information such as user query filters.

• Set up user attribute names such as:

— What is the common name attribute called?

— What is the roles attribute called?

• Set up LDAP server information such as the host and port name of the LDAP server, and information about the admin user for LDAP.

Summary: The LDAP Configuration tool lets you configure the VCMS software to use LDAP to manage users and groups. This tool is available to Windows users only.

SOLARIS USERS: See Using the config Command (for Windows and Solaris Users) on page D-39.

Before you begin: See Configuring the VCMS Software to Use LDAP on page D-22, for a flow chart of the configuration steps

Topics include: • Overview• Step 1: Starting the LDAP Configuration• Step 2: Setting up the Connection between the VCMS

software and LDAP• Step 3: Specifying SSL Certificate Information• Step 4: Choosing Client Authentication• Step 5: Specifying Client Authentication Information• Step 6: Setting up LDAP Access Information• Step 7: Setting up the LDAP Server• Step 8: Setting up User Query Information• Step 9: Setting up User Attributes• Step 10: Setting up Group Query Information• Step 11: Setting up Group Attributes• Step 12: Performing Repository Verification



• Set up LDAP group information such as group query filters and group attribute names.

• Set up the name of the file to which you want any inconsistencies between the existing VCMS EUR and the LDAP user repository written.

As you set up this information, during LDAP configuration, the VCMS software ensures that:

1 A connection can be established with LDAP (SSL or non-SSL).

2 The VCMS software can bind through an established connection, either with a user ID and password pair or a certificate (depending upon which option was selected).

3 At least one user matches the specified search criteria.

4 The users in the current VCMS database are at least a subset of the users in LDAP (including their group and role associations).

NOTE: During LDAP configuration, the VCMS software does not look to see if there is at least one group because there don’t have to be any groups.

The following sections lead you through setting up the information required for LDAP migration.

NOTE: The examples here configure the VCMS software to use a Netscape LDAP server. The process is the same for any LDAP server, but the values typed are different depending on the particular LDAP server configuration.

Step 1: Starting the LDAP Configuration

This example configures the VCMS software to use a Netscape LDAP server. It follows the full path of configuring a secure connection to LDAP using client authentication.

■ To start LDAP Configuration:

1 From the Windows Start menu, select Programs->VCMS 6.0->Platform Manager.

See also: VCMS Installation and Configuration Guide (printed copy shipped with product)



2 As shown in Figure D-9, select Configure an existing Content Management Server and click OK.

Figure D-9: Configure an existing Content Management Server

3 Log in to the CMS using the admin user’s name and password.

4 The VCMS Manager is started. From the Tools menu, choose Configure for LDAP User Repository.

5 On the LDAP Configuration window that appears, you are reminded of preliminary steps required before configuring the VCMS software to run with LDAP. Once you have completed these steps, click Next to proceed to Step 2: Setting up the Connection between the VCMS software and LDAP on page D-28.

See also: The following sections to perform these steps:

• Setting up LDAP SSL Certificates and Keys on page D-12• Making LDAP Schema and Database Changes on page D-17



Step 2: Setting up the Connection between the VCMS software and LDAP

In this step, you choose to have a non-secured or a secured connection between the VCMS software and LDAP.

■ To choose the type of connection you want:

1 Click one of the following options in the Use of SSL window:

• Use SSL when connecting to the LDAP server.

• Do not use SSL when connecting to the LDAP server.

2 Click Next.

• If you chose to use SSL, proceed to Step 3: Specifying SSL Certificate Information.

• If you chose not to use SSL, proceed to Step 6: Setting up LDAP Access Information on page D-31.

Step 3: Specifying SSL Certificate Information

This step prompts you for SSL certificate information.

■ To specify SSL certificate information:

1 In the SSL Certificate Information window, specify the LDAP certificate file location in the Certificate DB Location field.

2 Click Next to proceed to Step 4: Choosing Client Authentication on page D-29.



Step 4: Choosing Client Authentication

■ To choose (or not choose) client authentication:

1 In the Use of SSL Client Authentication window, click one of these options:

• Use client authentication.

• Do not use client authentication.

2 Click Next.

• If you chose client authentication, proceed to Step 5: Specifying Client Authentication Information on page D-29.

• If you chose not to use client authentication, proceed to Step 6: Setting up LDAP Access Information on page D-31.

Step 5: Specifying Client Authentication Information

In this step, you specify client authentication information.

■ To specify client authentication information:

1 In the window shown in Figure D-10, specify the client authentication information as follows:

a In the Client Key DB Location field: Type the path and file name of the key file—in this case: d:\key3.db.

b In the Client Key DB Password field: Type the password for the database key file.

c In the Client Certificate Alias/Nickname field: Type the nickname for the client certificate.

2 Click Next to proceed to Step 7: Setting up the LDAP Server on page D-33.



Figure D-10: SSL Client Authentication Information



Step 6: Setting up LDAP Access Information

This step prompts you for LDAP access information.

■ To set up LDAP access information:

1 In the window shown in Figure D-11, type the following:

• In the DN field: Type the distinguished name of the user for the LDAP account that the VCMS software logs into (this is the privileged account that has been set up for the VCMS software to gain access to LDAP).

You must include the common name, the organizational unit, and the organization for the admin user in the DN field. Depending on your LDAP schema, the names of these fields are unique. In this example, the common name field is uid, the organizational unit field is ou, and the organization field is o. The entire string typed in the DN field is:

uid=veur,ou=Directory Administrators,o=vignette.com

NOTE: The VCMS software uses the DN information to log in to LDAP. The user specified in the DN does not have to be a VCMS user as long as the user specified has write permissions for role attributes.

• In the Password field: Type the password for the user for the LDAP account that the VCMS software logs into (this is the privileged account that has been set up for the VCMS software to gain access to LDAP).

2 Click Next. The VCMS software connects to LDAP and checks that the admin user exists. If successful, proceed to Step 7: Setting up the LDAP Server on page D-33.



Figure D-11: LDAP Access



Step 7: Setting up the LDAP Server

This step prompts you for LDAP server information.

■ To set up the LDAP Server:

1 In the LDAP Server window, type the following:

• In the Host field: Type the host name of the LDAP server.

• In the Port field: Type the port number (389 for a non-secure connection; 636 for a secure connection).

• In the Search Timeout (secs) field: Either accept the default (30) or enter a different value.

NOTE: The Search Timeout parameter controls how long the CMS blocks waiting for LDAP search results. The default value is 30 seconds. A zero (0) or empty value entered during configuration means that the search timeout is infinite—the CMS could potentially block forever if the LDAP server is unavailable. See also CONNECT_RETRIES (entry of EUR_CONFIGURATION) on page D-20.

2 Click Next to proceed to Step 8: Setting up User Query Information on page D-33.

Step 8: Setting up User Query Information

The LDAP search space is logically hierarchical, but is physically flat. The information you provide in this step determines how much of the server you’ll look at when searching for user information.

■ To set up user query information:

1 In the User Query window, type the following:

• In the objectClass field: Type the user object class name. In this case, it’s ssuser.

• In the Filter Base field: Type the ou (organizational unit) and o (organization) information (or other filtering information). The actual name of the organizational unit and organization fields may be different at your installation. In this example, the Filter Base is:

ou=People,o=vignette.com



2 In the DN Template field: Type the common name placeholder (always #?#) appended with the organization and country strings. In this example, the string is:

uid=#?#,ou=People,o=vignette.com

When an actual search is performed, the common name placeholder is filled in with an actual name for which to search (such as admin).

NOTE: During LDAP configuration, you must fill in a DN Template field for users and groups. The template placeholder (the string #?#) is used to separate the DN prefix and the DN suffix. In a given DN, the placeholder location in the DN template must also be where the user login attribute or the group name attribute would occur.

3 Click Next to proceed to Step 9: Setting up User Attributes on page D-34.

Step 9: Setting up User Attributes

This step prompts you for user attributes information.

■ To set up user attributes:

1 In the User Attributes window, type the following:

• In the Login field: Accept the default or type the name of the common name attribute field in LDAP. In this example, the common name attribute is uid.

• In the Email field: Accept the default or type the name of the e-mail attribute field in LDAP. In this example, the e-mail name attribute is mail.

• In the Description field: Accept the default or type the name of the description attribute field in LDAP. In this example, it is description.

• In the Roles field: Accept the default or type the name of the roles attribute field in LDAP. In this example, it is roles.

2 Click Next to proceed to Step 10: Setting up Group Query Information on page D-35.



Step 10: Setting up Group Query Information

The LDAP search space is logically hierarchical, but is physically flat. The information you provide in this step determines how much of the server you’ll look at when searching for group information.

■ To set up group query information:

1 In the Group Query window, type the following:

• In the objectClass field: Type groupofuniquenames. The objectClass field can contain either:

— A user ID or user IDs.

— DNs (distinguished names)

• In the Filter Base field: Type the ou (organizational unit) and o (organization) information (or any other filtering information).

NOTE: The actual name of the organizational unit and organization fields may be different at your installation. In this example, the Filter Base is:

ou=Groups,o=vignette.com

• In the DN Template field: Type the cn (common name) placeholder (always #?#) concatenated with the ou (organization unit) and o (organization) strings. In this example, this string is:

cn=#?#,ou=Groups,o=vignette.com

When a search is performed, the common name placeholder is filled in with an actual name to search for (such as admin).

NOTE: During LDAP configuration, you must fill in a DN Template field for both users and groups. The template placeholder (the string #?#) is used to separate the DN prefix and the DN suffix. In a given DN, the placeholder location in the DN template must also be where the user login attribute or the group name attribute would occur.

NOTE: Unlike searches for users, no connection is made with LDAP to verify the existence of the group because the group doesn’t have to exist.

2 Click Next to proceed to Step 11: Setting up Group Attributes on page D-36.



Step 11: Setting up Group Attributes

This step prompts you for group attribute information.

■ To set up group attributes:

1 In the Group Attributes window, type the following:

• In the Name field: Accept the default or type the name of the common name attribute field in LDAP. In this example, the common name attribute is cn.


• In the Membership field: Accept the default or type the name of the membership field in LDAP. In this example, it is uniquemember.

2 Click Next to proceed to Step 12: Performing Repository Verification on page D-36.

Step 12: Performing Repository Verification

This step lets you set the name of the file to which you want discrepancies written.

■ To perform repository verification:

1 In the window shown in Figure D-12, in the File field: Type the path and file name of the log file to which you want discrepancies written.

2 Click Finish. The VCMS software compares the CMS EUR with the LDAP user repository. One of the following occurs:

• If both repositories match, you have successfully configured the VCMS software to use LDAP. You are returned to the first window of the LDAP Configuration.

• If the VCMS software finds discrepancies (missing users, missing groups, missing user-to-group associations, or missing user-to-role associations in either the VCMS EUR or the LDAP user repository), the VCMS software writes discrepancies to the specified log file.



The log file is in LDIF (LDAP Data Interchange Format). The LDAP administrator can use this file for LDAP data repairs. (The LDIF file format was selected so that you can easily patch your LDAP entries to make a successful VCMS EUR migration.)

If a differences file is generated, eliminate the differences by either:

— Modifying the LDAP repository to match the VCMS EUR (you consider your VCMS EUR as absolute)

— Modifying the VCMS EUR to match LDAP (you consider your LDAP information as absolute)

After any differences are corrected, you can repeat step 2 (click Finish on the window shown in Figure D-12) to perform repository verification again. (You do not have to repeat all the previous steps of LDAP migration.)



Figure D-12: Repository Verification



Using the config Command (for Windows and Solaris Users)

Overview

The config command sets up the following:

• The connection—non-secure or secure—between the VCMS software and LDAP. If you choose a secure connection, you can choose a client-authenticated connection or a non-client-authenticated connection. If you want a secure connection, you are prompted for security information.

• LDAP access information such as user query filters.

• User attribute names such as:

— What is the common name attribute called?

— What is the roles attribute called?

• LDAP server information such as the host and port name of the LDAP server, and information about the admin user for LDAP.

Summary: The config command lets you configure the VCMS to use LDAP to manage users and groups. The config command is available to both Windows and Solaris users.

Before you begin: See Configuring the VCMS Software to Use LDAP on page D-22, for a flow chart of the configuration steps

Topics include: • Overview• Step 1: Starting the LDAP Configuration• Step 2: Setting up the Connection between the VCMS and

LDAP• Step 3: Specifying SSL Certificate Information• Step 4: Choosing Client Authentication• Step 5: Specifying Client Authentication Information• Step 6: Setting up LDAP Access Information• Step 7: Setting up the LDAP Server• Step 8: Setting up User Query Information• Step 9: Setting up User Attributes• Step 10: Setting up Group Query Information• Step 11: Setting up Group Attributes• Step 12: Performing Repository Verification



• LDAP group information such as group query filters and group attribute names.

• The name of the file to which you want any inconsistencies between the existing VCMS EUR and the LDAP user repository written.

As you set up this information, during LDAP configuration, the VCMS software ensures that:

1 A connection can be established with LDAP (SSL or non-SSL).

2 The VCMS software can bind through an established connection, either with a user ID and password pair or a certificate (depending upon which option was selected).

3 At least one user matches the specified search criteria.

4 The users in the current VCMS database are at least a subset of the users in LDAP (including their group and role associations).

NOTE: During LDAP configuration, the VCMS software does not look to see if there is at least one group because there don’t have to be any groups.

The following sections step you through setting up the information required for LDAP migration.



Step 1: Starting the LDAP Configuration

NOTE: This example configures a Netscape LDAP server.

■ To start config:

1 Run the config command from install-path/adm.

2 Type 3 to choose to Configure an existing Content Management Server (CMS), as shown in Figure D-13:

Figure D-13: Configure an existing Content Management Server (CMS)

3 Type 1 to Select a CMS, as shown in Figure D-14:

Figure D-14: Select a CMS

4 Log in to the CMS using the admin user’s name and password.

5 Once logged in, type 9 to Configure for LDAP User Repository.

See also: VCMS Installation and Configuration Guide (printed copy shipped with product)



6 A Vignette LDAP Configuration Requirements screen is displayed, which reminds you of the preliminary steps required before configuring the VCMS software to run with LDAP. Once you complete these steps, press Enter to proceed to Step 2: Setting up the Connection between the VCMS and LDAP on page D-42.

Step 2: Setting up the Connection between the VCMS and LDAP

In this step, you choose to have a non-secure or a secure connection between LDAP and the VCMS software.

■ To choose the type of connection you want between the VCMS and LDAP:

1 In the screen shown in Figure D-15, type one of the following:

• Type 1 to use SSL when connecting to the LDAP server.

• Type 2 to connect to the LDAP server without using SSL.

2 Press Enter.

• If you chose to use SSL, proceed to Step 3: Specifying SSL Certificate Information on page D-43.

• If you connect without SSL, proceed to Step 6: Setting up LDAP Access Information on page D-46.

See also: The following sections to perform these steps:

• Setting up LDAP SSL Certificates and Keys on page D-12• Making LDAP Schema and Database Changes on page D-17



Figure D-15: Use of SSL

Step 3: Specifying SSL Certificate Information

This step prompts you for SSL certificate information.

■ To specify SSL certificate information:

1 In the SSL Certificate Information screen, specify the LDAP certificate file location in the Certificate DB Location field. In this case, it is d:\cert7.db.

2 Press Enter to proceed to Step 4: Choosing Client Authentication on page D-44.



Step 4: Choosing Client Authentication

■ To choose client authentication (or not):

1 In the Use of SSL Client Authentication screen, type one of the following:

• Type 1 to use client authentication

• Type 2 to run without client authentication

2 Press Enter.

• If you chose client authentication, proceed to Step 5: Specifying Client Authentication Information on page D-44.

• If you chose not to use client authentication, proceed to Step 6: Setting up LDAP Access Information on page D-46.

Step 5: Specifying Client Authentication Information

In this step, you specify client authentication information.

■ To specify client authentication information:

1 On the screen shown in Figure D-16, specify the client authentication information as follows:

a In the Client Key DB Location field: Type the path and file name of the key file—in this case: d:\key3.db.

b In the Client Key DB Password field: Type the password for the database key file.

c In the Client Certificate Alias/Nickname field: Type the nickname for the client certificate.



2 Press Enter to proceed to Step 7: Setting up the LDAP Server on page D-47.

Figure D-16: SSL Client Authentication Information



Step 6: Setting up LDAP Access Information

This step prompts you for LDAP access information.

■ To set up LDAP access information:

1 In the LDAP Access screen, type the following:

• In the DN field: Type the distinguished name of the user for the LDAP account that the VCMS software logs into (this is the privileged account that has been set up for the VCMS software to gain access to LDAP).

You must include the common name, the organizational unit, and the organization for the admin user in the DN field. Depending on your LDAP schema, the names of these fields are unique. In this example, the common name field is uid, the organizational unit field is ou, and the organization field is o. The entire string typed in the DN field is:

uid=veur,ou=Directory Administrators,o=vignette.com

NOTE: The VCMS software uses the DN information to log in to LDAP. The user specified in the DN does not have to be a VCMS user as long as the user specified has write permissions for role attributes.

• In the Password field: Type the password for the user for the LDAP account that the VCMS software logs into (this is the privileged account that has been set up for the VCMS software to gain access to LDAP).

2 Press Enter. The VCMS software connects to LDAP and checks that the admin user exists. If successful, proceed to Step 7: Setting up the LDAP Server on page D-47.



Step 7: Setting up the LDAP Server

This step prompts you for LDAP server information.

■ To set up the LDAP Server:

1 In the LDAP Server screen, type the following:

• In the Host field: Type the host name of the LDAP server.

• In the Port field: Type the port number (389 for a non-secure connection; 636 for a secure connection).

• In the Search Timeout (secs) field: Either choose the default (30) or enter a different value.

NOTE: The Search Timeout parameter controls how long the CMS blocks waiting for LDAP search results. The default value is 30 seconds. A zero (0) or empty value entered during configuration means that the search timeout is infinite—the CMS could potentially block forever if the LDAP server is unavailable. See also CONNECT_RETRIES (entry of EUR_CONFIGURATION) on page D-20.

2 Press Enter to proceed to Step 8: Setting up User Query Information on page D-47.

Step 8: Setting up User Query Information

The LDAP search space is logically hierarchical, but is physically flat. The information you provide in this step determines how much of the server you’ll look at when searching for user information.

■ To set up user query information:

1 In the User Query screen, type the following:

• In the objectClass field: Type the user object class name. In this case, it’s ssuser.

• In the Filter Base field: Type the ou (organizational unit) and o (organization) information (or other filtering information). The actual name of the organizational unit and organization fields may be different at your installation. In this example, the Filter Base is:

ou=People,o=vignette.com



2 In the DN Template field: Type the common name placeholder (always #?#), appended with the organization and country strings. In this example, the string is:

uid=#?#,ou=People,o=vignette.com

When an actual search is performed, the common name placeholder is filled in with an actual name to search for (such as admin).


3 Press Enter to proceed to Step 9: Setting up User Attributes on page D-48.

Step 9: Setting up User Attributes

This step prompts you for user attribute information.

■ To set up user attributes:

1 In the User Attributes screen, type the following:

• In the Login field: Accept the default or type the name of the common name attribute field in LDAP. In this example, the common name attribute is uid.

• In the Email field: Accept the default or type the name of the e-mail attribute field in LDAP. In this example, the e-mail name attribute is mail.


• In the Roles field: Accept the default or type the name of the roles attribute field in LDAP. In this example, it is roles.

2 Press Enter to proceed to Step 10: Setting up Group Query Information on page D-49.



Step 10: Setting up Group Query Information

The LDAP search space is logically hierarchical, but is physically flat. The information you provide in this step determines how much of the server you’ll look at when searching for group information.

■ To set up group query information:

1 In the Group Query screen, type the following:

• In the objectClass field: Type the name of the group object class. In this case, it’s groupofuniquenames.

• In the Filter Base field: Type the ou (organizational unit) and o (organization) information (or any other filtering information).

NOTE: The actual name of the organizational unit and organization fields may be different at your installation. In this example, the Filter Base is:

ou=Groups,o=vignette.com

• In the DN Template field: Type the common name placeholder (always #?#) concatenated with the organization unit and organization strings. In this example, this string is:

cn=#?#,ou=Groups,o=vignette.com

When a search is performed, the common name placeholder is filled in with an actual name to search for (such as admin).


NOTE: Unlike searches for users, no connection is made with LDAP to verify the existence of the group because the group doesn’t have to exist.

2 Press Enter to proceed to Step 11: Setting up Group Attributes on page D-50.



Step 11: Setting up Group Attributes

This step prompts you for group attribute information.

■ To set up group attributes:

1 In the Group Attributes screen, type the following:

• In the Name field: Accept the default or type the name of the common name attribute field in LDAP. In this example, the common name attribute is cn.


• In the Membership field: Accept the default or type the name of the membership field in LDAP. In this example, it is uniquemember.

2 Press Enter to proceed to Step 12: Performing Repository Verification on page D-50.

Step 12: Performing Repository Verification

This step lets you set the name of the file to which you want discrepancies written.

■ To perform repository verification:

1 In the screen shown in Figure D-17, in the File field: Type the path and file name of the log file to which you want discrepancies written. In this case, it’s d:\ldapeur.

2 Press Enter. The VCMS software compares the CMS EUR with the LDAP user repository. One of the following occurs:

• If both repositories match, you have successfully configured the VCMS software to use LDAP.

• If the VCMS software finds discrepancies (missing users, missing groups, missing user-to-group associations, or missing user-to-role associations in either the VCMS EUR or the LDAP user repository), the VCMS software writes discrepancies to the specified log file.



The log file is in LDAP Data Interchange Format (LDIF). The LDAP administrator can use this file for LDAP data repairs. (The LDIF file format was selected so that you can easily patch your LDAP entries to make a successful VCMS EUR migration.)

If a differences file is generated, eliminate the differences by either:

— Modifying the LDAP repository to match the VCMS EUR (you consider your VCMS EUR as absolute)

— Modifying the VCMS EUR to match LDAP (you consider your LDAP information as absolute)

After any differences are corrected, you can repeat step 2 (press Enter on the screen shown in Figure D-17) to perform repository verification again. (You do not have to repeat all the previous steps of LDAP migration.)

Figure D-17: Repository Verification



Things to Do After Configuring the VCMS Software to Use LDAP

After configuration, you must be aware of the following:

Reconfiguration. You can change the VCMS software/LDAP configuration after an initial configuration. Reconfiguration lets you:

• Switch from a non-secure connection to a secure connection, and vice versa. Also, switch from a secure connection without client authentication to one with client authentication, and vice versa.

• Change any or all of the LDAP host information, which means you can change to a different LDAP vendor’s product.

NOTE: The verification step (see Step 12: Performing Repository Verification on page D-36) always verifies the LDAP user repository against the VCMS EUR, even if you already configured to use an LDAP user repository. Subsequent configurations do not cause the VCMS software to compare one LDAP user repository to another.

Also, although you can make configuration changes to an existing LDAP configuration, there is no automated configuration mechanism provided to go back to using the VCMS installation as your user repository.

However, after migration to LDAP, the VCMS EUR continues to exist (nothing is ever erased from any existing VCMS EUR). Though no longer used as a user repository, the VCMS EUR still serves these purposes:

• Role definitions storage: The VCMS EUR stores role names and their descriptions

• Password-related user management: The VCMS EUR stores login disabling and password history

Logging into the VCMS Site. Log into the VCMS site using the passwords of the accounts configured in LDAP; in other words, the VCMS software does not transfer VCMS database user passwords to LDAP.

User Manager changes. After you migrate to use LDAP, the User Manager changes slightly. To get to the User Manager click the User Manager icon on the Vignette VCMS Tools toolbar.



Before you configured the VCMS software to use LDAP, the User Manager contained Users, Groups, and Roles tabs as shown in Figure D-18:

Figure D-18: User Manager before LDAP migration



However, once you have configured for LDAP, the User Manager tool contains only a Roles tab as shown in Figure D-19:

Figure D-19: User Manager after LDAP migration

After LDAP migration, you manage users and groups through an LDAP client.

Also, when the CMS is configured with an LDAP user repository, the User Manager monitors the number of users and groups returned from a query and alters the window display accordingly:



• If the combined number of LDAP user repository users and groups exceeds 50, the User Manager lists the query results in a single text field separated by commas, as shown in Figure D-20:

Figure D-20: User Manager users and roles for more than 50 items



• If the combined number of users and groups returned from a query is 50 or less, the User Manager uses the list box metaphor to display the query results, as shown in Figure D-21:

Figure D-21: User Manager users and roles for less than 50 items

LDAP server-side limits. LDAP server-side limits (for example, lookthroughlimit or sizelimit) may produce unexpected results if configured VCMS queries return results that exceed them.

The VCMS software tries to display as many returned LDAP entries as possible. However, if a VCMS query exceeds an LDAP limit, one of the following happens:

• LDAP returns a limit error message and returns no entries: the VCMS software displays and logs an error message.

• LDAP returns a limit error message and returns some entries: the VCMS software logs the error, but does not notify the user.


E Remote Operations

Summary: Configuring systems with firewalls or proxy servers.


Before you begin: Chapter 9, Managing the VCMS Site

Topics include: • Overview• Enabling Communication between VCMS Components• Enabling Communication between VCMS Tools and

Components• Working with IP Aliases• Outbound Connections through HTTP Proxy• VCMS Tools Sessions Using SOCKS

August 2001 Vignette Confidential E-1

Remote Operations Administration Guide

OverviewThis appendix discusses various configurations for your VCMS installation.

You may want to configure your web servers on hosts outside your security firewall, and allow them to communicate with VCMS components inside the firewall. You can give the web servers read-only access to the docroot, thus reducing the CDS’s vulnerability to outside attackers. For details about this configuration, see the chapter about web server security in the Security Guide.

Another remote operation might be to run the VCMS Tools sessions 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 all of the CMS API commands.

NOTE: If your CMS, CDSs, OMS, or MCS are installed on machines with multiple host names, you may need to adjust configuration information for the processes that connect to those machines. See the section about multiple host names in the VCMS Installation and Configuration Guide (printed copy shipped with product).

E-2 Vignette Confidential August 2001

Administration Guide Remote Operations

Enabling Communication between VCMS ComponentsIn Figure E-1 (page E-6), the circled numbers serve as a key in the corresponding table. Follow the key to determine which processes within a component require connections for communication with other components and their processes.

You can use the information in the figure and the corresponding table to determine the number of ports you need to open and, depending on your configuration, the number of holes required in the firewall.

For example, if your configuration consists of all VCMS components on a single host, with the exception of the Docroot Manager and Web Server on a separate host outside the firewall, you can see that, for Web Server communications, numbers 1 and 6 from Figure E-1 apply. Go to the appropriate key in the corresponding table to see that you need to open ports for the following connections:

• Web Server to ctld (Tcl Page Generator)• Web Server to ASP Page Generator• Web Server to JSP Page Generator• Web Server to vrd (Router)

If the CDS includes multiple Page Generators, or the OMS includes multiple Routers, you need to open a port for each Page Generator and Router. And, for this example, you need a hole in the firewall for each connection since the Web Server is outside the firewall.

If your configuration consists of all VCMS components on a single host, with the exception of your CDS on a separate host outside the firewall, you can see that numbers 2, 4, 5, 6, 7, 10, and 15 from Figure E-1 apply. Go to the appropriate key in the corresponding table to understand the process-level connections that will require ports and holes in the firewall.



KeyComponent or subcomponent connection Process connections required

1 Web Server to CDS • Web Server to ctld (Tcl Page Generator) front door host/port

• Web Server to ASP Page Generator front door host/port

• Web Server to JSP Page Generator front door host/port

2 Application Engine to CMS(if using CMS Tcl Commands)

• ctld (Tcl Page Generator) to bob (Dispatch Service)

• ctld (Tcl Page Generator) to vhs (Request Service)

• ASP Page Generator to bob (Dispatch Service)

• ASP Page Generator to vhs (Request Service)

• JSP Page Generator to bob (Dispatch Service)

• JSP Page Generator to vhs (Request Service)

3 Application Engine to Docroot Manager

• tmd (Template Manager) to cmd (Cache Manager)

4 Application Engine to System Database

• tmd (Template Manager) to System Database

• ctld (Tcl Page Generator) to System Database

• ASP Page Generator to System Database

• JSP Page Generator to System Database

5 Application Engine to Content Database

• ctld (Tcl Page Generator) to Content Database

• ASP Page Generator to Content Database

• JSP Page Generator to Content Database

6 Application Engine to Visitor Database

• ctld (Tcl Page Generator) to Visitor Database



7 Web Server to OMS • Web Server to vrd (Router) via front door host/port

8 Application Engine to MCS(if using MCS commands)

• ctld (Tcl Page Generator) to mcd (Multi-Channel Delivery Agent) front door host/port

9 Docroot Manager to Web Server(IIS Web Servers only)

• cmd (Cache Manager) to Web Server

10 Application Engine to OMS • ctld (Tcl Page Generator) to vrd (Router) front door host/port

• ASP Page Generator to vrd (Router) front door host/port

• JSP Page Generator to vrd (Router) front door host/port

11 MCS to Application Engine(if association is configured)

• mcd (Multi-Channel Delivery Agent) to ctld (Tcl Page Generator) front door host/port

12 MCS to OMS • mcd (Multi-Channel Delivery Agent) to vrd (Router) front door host/port

13 OMS to Visitor Database • omd (Observation Manager) to Visitor Database

14 OMS to System Database • omd (Observation Manager) to System Database

• cld (Campaign Logging Agent) to System Database

15 CMS to CDS • vhs (Request Service) to tmd (Template Manager)

• vhs (Request Service) to pad (Placement Agent)

16 CMS to System Database • bob (Dispatch Service) to System Database

• vhs (Request Service) to System Database

KeyComponent or subcomponent connection Process connections required



Figure E-1: Ports required for component connections

DocrootManager

ApplicationEngine

CMS

SystemDB

CDS

1

OMS

3

WebServer

ContentDB

VisitorDB

6

5

4

MCS

7

10

12

13

14

15

16

2

8

9

11



Enabling Communication between VCMS Tools and Components

In Figure E-2, the circled numbers serve as a key in the corresponding table. Follow the key to determine the number of ports you need to open and, depending on your configuration, the number of holes required in the firewall.

The VCMS tools require connections to the VCMS components. You need to make a port available for each process connection that applies to your configuration. If your VCMS tools are on a separate host outside the firewall, you will also need a hole in the firewall for each process connection that applies to your configuration.

Key Tools to component connection Process connections required

1 VCMS tools (Production Center, Development Center, Business Center, and Admin Center) to the CMS

• Tools to bob (Dispatch Service)• Tools to vhs (Request Service)

2 Admin Center to CDS (for status information)

• Admin Center to ctld (Tcl Page Generator)

• Admin Center to ASP Page Generator

• Admin Center to JSP Page Generator

• Admin Center to tmd (Template Manager)

• Admin Center to pad (Placement Agent)

• Admin Center to cmd (Cache Manager)

3 Admin Center to OMS (for status information)

• Admin Center to vrd (Router)• Admin Center to omd (Observation

Manager)• Admin Center to cld (Campaign

Logging Agent)• Admin Center to vwd (Watchdog)

4 Admin Center to MCS (for status information)

• Admin Center to mcd (Multi-Channel Delivery Agent)

• Admin Center to vwd (Watchdog)



NOTE: The Production Center connects to the CDS (for content entry and template preview) through the web server, but does not require another port.

Figure E-2: Ports required for VCMS tools to component connections

DocrootManager

ApplicationEngine

VCMS Tools

CMS

1

OMS2

43

MCS

CDS



CDS File System AccessThe CDS’s Docroot Manager subcomponent requires write access to the Web Server’s document root (docroot) and the metafiles cache. The Application Engine subcomponent requires write access to the document root if you set the PG_WRITES_CACHED_PAGES configuration variable to true, that is, if you have configured the VCMS to enable the Page Generator to write cached pages. (By default, the Web Server writes cached pages.)

The docroot and metafiles cache can be on the same host as the Docroot Manager and Application Engine or they can be on a remote Web Server host. Additionally, your Docroot Manager and Application Engine can be on the same host or separate hosts. Consider your configuration and each host involved when ensuring that the CDS subcomponents have proper permissions to write to the docroot and metafiles cache.

NOTE: If your Docroot Manager and Web Server are on opposite sides of the firewall, you need to share the docroot and metafiles cache across the firewall.

Figure E-3: CDS File System Access

/docroot

DocrootManager

WebServer

ApplicationEngine

/metafiles cache



Working with IP AliasesIf certain VCMS components are installed on remote hosts outside the firewall in an environment that utilizes IP-aliasing, you need to override the values for the HOST configuration variable in the configuration file for the component that resides outside the firewall.

NOTE: The variable to override for the CMS component is named PM_HOST. For the MCS component, the variable is named MCS_HOST.

For example, if your Application Engine is installed on host foo inside the firewall (and it includes ctld and asp page generator processes), and the Web Server is on a remote host outside the firewall and that host uses an IP alias of fooext, you need to permanently override the HOST variable in the ws.cfg file, as follows:

1 Log in to the host where the Web Server resides.

2 Change to the directory where the Web Server is installed. For example, on Solaris, the default location for the Web Server is:

install-path/vignette/inst-name/conf/ws-name

3 Edit the Web Server’s configuration file. To do so, enter:

admin cfgedit ws.cfg

4 Set the /cds-name/ape/pg/ctld/HOST variable (front door for the ctld) to fooext (the IP alias). Use the set +o subcommand to put a permanent override on the variable.

5 Set the /cds-name/ape/pg/asp/HOST variable (front door for ASP Page Generator) to fooext. Use the set +o subcommand to put a permanent override on the variable.

See the chapter about the admin cfgedit utility in the Configuration Reference for detailed information about setting permanent overrides.



Outbound Connections through HTTP ProxyYou may decide to configure the VCMS software so that your live CDS is outside a firewall. If so, you can use an http proxy server to regulate outbound connections to this CDS.

Refer to Figure E-1 and the corresponding table to understand which component requests must pass through the proxy server (assuming that outbound connections through the firewall are restricted and must pass through the proxy server).

For example, using Figure E-1 and its corresponding table, you can determine that the CMS’s vhs process requires two ports to connect to a CDS’s tmd and pad processes. When a CDS is outside a firewall with an http proxy server, these requests must go through the http proxy server.

Refer to Figure E-2 and its corresponding table to understand which VCMS tools requests must pass through the proxy server (assuming that outbound connections through the firewall are restricted and must pass through the proxy server).

For example, using Figure E-2 and its corresponding table, you can determine that the Admin Center requires ports to connect with the cmd, ctld, ASP Page Generator, JSP Page Generator, pad, and tmd processes on each CDS. When a CDS is outside a firewall with an http proxy server, these requests must go through the http proxy server.

You must be a System role user to perform the following operation.

■ To configure a CDS outside the firewall with an http proxy:

1 Using the Platform Variable Editor, create and then set the PROXY_HOST and PROXY_PORT variables for the CDS. Create and set the variables at the /cds-name level of the configuration hierarchy. These variables do not exist by default. The values for these variables will be inherited by all CDS processes.

NOTE: You must specify the http proxy host’s fully qualified domain name and the port on which it communicates, for example, harvey.example.com using port number 1234.

See the Configuration Reference to learn how to create and edit configuration variables using the Platform Variable Editor.

2 Stop and restart the CMS to read the new information.



3 If a VCMS session is running, reconnect to the CMS. For more information, see the section on connecting to a CMS in Running the Vignette Content Management Tools.

NOTE: If the CMS communicates to the CDS through an http proxy, process-to-process authentication and encryption will not function. For details about security, see the Security Guide.

VCMS Tools Sessions Using SOCKSThe VCMS software supports VCMS tools session communication through a SOCKS proxy server. If you have a SOCKS proxy server set up, you can install the VCMS tools (user interface software) on a Windows 95, Windows NT, Windows 2000, or Solaris host outside a firewall to communicate through the SOCKS proxy with the CMS, CDSs, OMS, and MCS.

For example, imagine that the VCMS tools sessions shown in Figure E-2 are installed on a remote host outside the firewall with a SOCKS proxy server between them and the rest of the VCMS components (which all reside on the same host).

You must have the SOCKS proxy server configured and the VCMS 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.example.com:4567

Specifying the SOCKS Server

You can use a SOCKS proxy server for the VCMS tools session either by specifying the server on the command line or by changing the VCMS shortcut button.



Specifying the SOCKS Server Using Command-line Options

■ To specify the SOCKS proxy server using command-line options:

1 Open a DOS shell.

2 If necessary, change to the drive on which the VCMS tool software is installed.

3 Change to the bin directory of the VCMS tools. If you installed at the default location, you would enter:

cd \Program Files\Vignette\Tools\6.0\bin

4 Start the VCMS session:

ss -s shost:sport

where shost:sport is the fully qualified host domain and port on which the SOCKS server listens, for example: rambo.example.com:4567.

Changing the VCMS Platform Tools Shortcut Button

■ To specify the SOCKS proxy server by changing the Platform Tools shortcut button:

1 On the Windows desktop, right click the Platform Tools shortcut icon and select Properties. The Platform Tools Properties window opens.

2 Select the Shortcut tab. The Shortcut page opens. The Target text field will look similar to the following:

"C:\Program Files\Vignette\tools\6.0\bin\ss.exe"

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\tools\6.0\bin\ss.exe-s rambo.example.com:4567"

4 Save the changes to the shortcut and run the VCMS tools.


F Configuring Virtual Hosting

NOTE: Please be aware that your license may not permit you to do virtual hosting for third parties. Please consult your license paperwork.

Summary: How to set up virtual hosting for the web servers you use with the Vignette® Content Management Server V6 (VCMS) Content Delivery Servers (CDSs).

Audience: Administrators of the VCMS software

Before you begin: • Chapter 9, Managing the VCMS Site• Chapter 10, Working with Web Servers

Topics include: • Overview• Configuring Web Servers• Testing the Virtual Servers• Virtual Server Front Doors• Virtual Hosting and Development

August 2001 Vignette Confidential F-1

Configuring Virtual Hosting Administration Guide

OverviewWhen you configure the VCMS software for virtual hosting, you set up one CDS to serve multiple virtual web servers. Virtual hosting allows 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 F-1 shows a CDS 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 F-1: CDS set up for virtual hosting with two domains

Requests forDomain1

http: / /www.domain1.com

... /docroot

... /docroot/domain1

IP207.8.8.22

WebServer

Requests forDomain2

http: / /www.domain2.com

IP 2207.8.8.23

... /docroot/domain2

F-2 Vignette Confidential August 2001

Administration Guide Configuring Virtual Hosting

How Virtual Hosting Works with the VCMS Software

Virtual hosting with the VCMS software requires that you perform some additional configuration on the web server being used with your CDS.

NOTE: The VCMS software supports only hardware virtual hosting, that is, virtual hosting where you have several IP addresses, and you use a web server instance to set up virtual domains for those IP addresses. Software virtual hosting, that is, setting up a CDS with a single IP address and multiple port numbers, is not supported.

■ To set up virtual hosting with the VCMS software:

1 Start by configuring your web server and CDS in the default fashion as described in the VCMS Installation and 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 F-4 describes one way of setting up virtual web servers and communicating the appropriate information to the VCMS software. 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.

5 When working with templates, include the unique path that differentiates the virtual server as a prefix on the templates’ paths and the paths of any files you want associated with that virtual 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, associate the web server as you normally would with a CDS. For details, see the VCMS Installation and 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 CDS. For example:

WINDOWS If the document root directory for your web server is C:\docroot and you plan on two virtual hosts, domain1 and domain2, create the following directories:

C:\docroot\domain1

C:\docroot\domain2

SOLARIS/AIX If the document root directory for your web server is /docroot and you plan on two virtual hosts, domain1 and domain2, create the following directories:

/docroot/domain1

/docroot/domain2

NOTE: All directory names are case-sensitive.

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

NOTE: If visitor tracking by URL is enabled for your web site, exclude the vgn directory in each domain (/domain-path-prefix/vgn). See the chapter on preliminary configuration in the Visitor Services Guide for more information.

Topics include: • iPlanet Web Servers• Microsoft IIS Web Servers• Apache Web Servers (Solaris Only) and IHS Web Servers

(AIX Only)



iPlanet Web Servers

■ To configure an iPlanet web server to use virtual hosting with the VCMS software:

1 Open the browser-based iPlanet Web Server Administration Server interface for the web server.

NOTE: When you begin work in the interface, be sure to apply the changes the VCMS software made to your obj.conf file, the NSAPI configuration file for iPlanet web servers.

2 Make the following changes from within the iPlanet Web Server Administration Server interface, and save and apply your changes:

What How

Set bind-to address. Select web server, select Server Preferences then Network Settings, enter your main IP address in the Bind To Address field.

Set the Primary Document Directory.

Select Content Management for the web server. Ensure the docroot path of the main webserver is entered into the primary directory path. For example:

WINDOWS C:\docroot

SOLARIS/AIX /docroot

Set up the hardware virtual server.

Select Content Management then Hardware Virtual Servers. Enter the IP address of the virtual server in the IP Address field. Enter the complete path for the virtual server’s document directory associated with the IP address. For example: WINDOWS C:\docroot\domain1SOLARIS/AIX /docroot/domain1

Repeat this step for each virtual server you wish to set up.



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 the VCMS software.) 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"

4 Apply the manual edits to your obj.conf file in the browser Administration interface. Then, stop and start the web server.

Microsoft IIS Web Servers

After completing the steps in Configuring Web Servers on page F-4, follow these steps to configure a Microsoft IIS web server for virtual hosting:

1 Creating a Web Server Instance for Each Virtual Host Domain

2 Associating the Primary Web Server Instance with the CDS

3 Obtaining the Web Server Instance ID

4 Updating the Registry



Creating a Web Server Instance for Each Virtual Host Domain

From the Internet Services Manager (perhaps called the Microsoft Management Console, depending on your version of IIS), create a web server instance for each of your virtual host domains. (See the Microsoft documentation for information about how to create an IIS web server instance.)

When creating each web server instance, specify the following values:

Associating the Primary Web Server Instance with the CDS

Using the Platform Manager, associate the primary web server instance with the CDS. For information about the procedure, see the VCMS Installation and Configuration Guide (printed copy shipped with product).

What Value

IP address A unique IP address for this virtual domain’s web server instance.

Home directory The complete path for the virtual server's document directory—the one you created previously in Configuring Web Servers on page F-4. For example, if the home directory for the primary web server is C:\docroot, domain 1’s path might be C:\docroot\domain1.

Permissions Scripting permissions, to handle server-side includes required by the VCMS software.



Obtaining the Web Server Instance ID

You’ll need to use the web server instance ID later in the configuration process. To determine the ID for your web server instances, use the listiis utility:

install-path\6.0\bin\winnt\listiis

listiis lists the IIS web server instances and their IDs. The following sample shows a sample output from listiis:

Instance Name-------- ----1 Default Web Site2 Administration Web Site3 Primary Web Site4 Domain1 Virtual Web Site5 Domain2 Virtual Web Site

The web site called Primary Web Site (instance ID 3) is the primary web server instance that you associated with the CDS in Associating the Primary Web Server Instance with the CDS on page F-7. Using the same example as the previous paragraphs in this section, the docroot for the primary web server would be C:\docroot.

The Domain1 and Domain2 web servers (instance IDs 4 and 5) are the two virtual web sites that you defined in Creating a Web Server Instance for Each Virtual Host Domain on page F-7. Their docroot directories would be subdirectories of the primary web site’s docroot directory; for example, C:\docroot\domain1 and C:\docroot\domain2.



Updating the Registry

■ To complete configuration for IIS web servers

1 Edit the system registry using the Registry Editor (enter regedit32 at a command prompt).

2 Open the definition:

HKEY_LOCAL_MACHINE\SOFTWARE\Vignette\6.0\Platform\IIS_Plugin

There should be a registry entry that corresponds to the primary instance ID. Using the preceding example, the web-site ID key of that entry is 3.

Inside web-site ID key 3 are several string values:

SS Config File:REG_SZ:C:/Vignette/inst-tripart/ws-hecate/ws.cfgSS Config ID:REG_SZ:/ws-tripart/SS Version:REG_SZ:6.0

NOTE: These strings and values were created and populated by the Platform Manager when you associated the primary web server instance with the CDS.

3 Add each virtual web server instance to the IIS_Plugin registry entry, placing them after the existing primary key:

a Manually create a new web-site ID key registry entry for a virtual web server instance.

b Copy the primary web-site ID key’s strings and their values to the newly-created key’s registry entry.

c Repeat substeps a and b for each virtual web server instance.

When you finish, you should have a web-site ID key for the primary web site, followed by a key for each virtual web site. All keys should have identical string values.

Continuing the example from previous paragraphs, after you complete step 3, you would have web-site ID key 3 for the primary web site, key 4 for Domain1, and key 5 for Domain2. All three keys would have the string values listed in step 2.



4 For each virtual web-site ID key, add the following string-value pair:

For example, when you add Vgn_TplPrefix to web-site ID key 4 (Domain1), you would supply a value of /domain1 for that string. For key ID 5 (Domain2), that value would be /domain2. Now if you look at key ID 4, you would see the following:

SS Config File:REG_SZ:C:/Vignette/inst-tripart/ws-hecate/ws.cfgSS Config ID:REG_SZ:/ws-tripart/SS Version:REG_SZ:6.0Vgn_TplPrefix:REG_SZ:/domain1

Looking at key ID 5, you would see:

SS Config File:REG_SZ:C:/Vignette/inst-tripart/ws-hecate/ws.cfgSS Config ID:REG_SZ:/ws-tripart/SS Version:REG_SZ:6.0Vgn_TplPrefix:REG_SZ:/domain2

5 Stop and start the IIS World Wide Web Publishing Service from the Service Control Panel.

6 Stop and start the CDS.

String Value

Vgn_TplPrefix The subdirectory, in the primary web server instance home directory, dedicated to this virtual web server instance (and IP address)..



Apache Web Servers (Solaris Only) and IHS Web Servers (AIX Only)

To configure an Apache web server or an IBM HTTP Server web server to use virtual hosting with the VCMS software, you add a Vgn_Tplprefix definition to each VirtualHost segment you’ve defined in your web server configuration file.

■ To set up Apache or IHS virtual hosting with the VCMS software:

1 Edit the httpd.conf file for the web server configuration. This file is typically in the install-path/conf directory.

CAUTION: Do not use the IBM Administration Server GUI to edit the httpd.conf file! Because it may rearrange some lines in the file, it may disable the VCMS configuration information within that file.

2 At the bottom of the file, confirm that the following variable definitions have been added or uncommented:

• Vgn_SSConfigFile — The location of the ws.cfg file for the CDS. For example,

install-path/vignette/inst-name/conf/ws-name/ws.cfg

• Vgn_ShLibDir — The location of the shared library directory of your VCMS installation. For example,

install-path/vignette/6.0/lib/ostype/

where ostype is either solaris or aix. For information on file location variables, see Common Path Name Variables on page 1-5.

3 Add a VirtualHost entry for each virtual domain to be served by the web server using this format:

<VirtualHost ip-address> Vgn_SSConfigFile ws.cfg-path Vgn_SSConfigID ws-name Vgn_ShLibDir VCMS-shared-lib-path ServerName hostname DocumentRoot docroot-path/domain-path Vgn_Tplprefix /domain-path</VirtualHost>



Argument Description

ip-address IP address for the virtual web server. With virtual hosting, each machine has multiple IP addresses, each representing a different hostname.

ws.cfg-path Path of the ws.cfg file for the web server. 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.

ws-name The name of the web server instance. This is the same as the configuration identifier for the web server without the leading slash.

For more information about the configuration identifier, see the Configuration Reference.

VCMS-shared-lib-path Path of the shared library directory of your VCMS 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.

hostname The hostname that corresponds to ip-address, for example ws-fisher.

docroot-path Path to the web server document root directory (which you provided during configuration of the CDS).

domain-path Subdirectory in the document root that is dedicated to hostname.



The following example defines two virtual web servers with hostnames www.domain1.com and www.domain2.com. The primary web server document root is /opt/httpd/docroot, and it contains two subdirectories, domain1 and domain2.

<VirtualHost 192.168.8.8> Vgn_SSConfigFile /opt/vignette/inst-tripart/conf/ws-persephone/ws.cfg Vgn_SSConfigID ws-persephone Vgn_ShLibDir /opt/vignette/6.0/lib/solaris ServerName www.domain1.com DocumentRoot /opt/httpd/docroot/domain1 Vgn_Tplprefix /domain1</VirtualHost>

<VirtualHost 192.168.8.9> Vgn_SSConfigFile /opt/vignette/inst-tripart/conf/ws-persephone/ws.cfg Vgn_SSConfigID ws-persephone Vgn_ShLibDir /opt/vignette/6.0/lib/solaris/ ServerName www.domain2.com DocumentRoot /opt/httpd/docroot/domain2 Vgn_Tplprefix /domain2</VirtualHost>

In the example above, 192.168.8.8 is the IP address designated for www.domain1.com and 192.168.8.9 is the IP address designated for www.domain2.com.

4 Stop and start the Apache or IHS 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:

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.



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 the documentation root of your virtual server to a particular CURL.)

Virtual Hosting and Development

This section describes ways that virtual hosting impacts VCMS 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.

Setting up Development CDSs

If you configure your live CDS to use virtual servers, and if you want to mirror your live environment for testing, you’ll need to configure your development CDS with virtual servers as well.

You set up a development CDS with virtual servers as described in the section Configuring Web Servers on page F-4. 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.

Topics include: • Setting up Development CDSs• Creating Templates• Submitting Static Files



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:

WINDOWSC:\docroot\domain1C:\docRoot\domain2

SOLARIS/AIX/docroot/domain1/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 CDS 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 that you defined. Each template path for a given virtual server must be prefixed by the Vgn_TplPrefix value of that virtual server. For example, if you have a template named dataEntry, and that template is to be referenced from:

• A virtual host that has a Vgn_TplPrefix of /domain1—You must specify a template path of /domain1/dataEntry.

• A virtual host that has a Vgn_TplPrefix of /domain2—You must specify a template path of /domain2/dataEntry.

• The main webserver—You must specify a template path of /dataEntry.

You must specify the correct path for each server that will reference the template. For example, if all three hosts in the preceding bullets will reference the template, you must specify all three template paths for the template.

In addition, the CURL API commands provide keywords to enable you to reference across virtual web servers. For more information, refer to the VCMS documentation for your template environment (Tcl, COM, or Java).



Submitting Static Files

Because virtual servers each use a unique subdirectory in the web server document root, it’s important to specify the correct path when submitting 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


Index

Symbols%2f (in template path) B-32, B-33, B-44

Aaccepting

a certificate D-16accessing

CDS file system E-9content database of different type 7-7

adjustingtimeouts 11-3variable settings to tune the VCMS

installation 11-2Admin Center

closing tools 3-7concepts 1-3enabling self-registration 5-12expanding displays 3-5getting help 3-7interfaces 3-5Preferences file 6-17sorting entries 3-5starting tools 3-2terms 1-3tool directories 6-16using 3-4using tabs 5-3viewing processes 3-5

Admin Center toolsConfiguration View 3-2User Manager 3-2

admin commandcfgedit A-12changing the log level A-14chlog A-13for all VCMS processes A-5for the CDS A-6for the CMS A-8for the MCS A-9for the OMS A-10refreshfromdb 8-6, A-16starting Template Manager 8-5stopping Template Manager 8-5using to start processes 8-3using to stop processes 8-3

admin refreshfromdb command A-16location for all processes A-16location for specific components A-16options A-14, A-18

admin user 3-2, 5-4administration tasks

getting started 2-2adminutil.cfg file B-6ALLOWED_IP_ADDRESSES variable

11-10Apache

parsing 10-8Application Engine

configuration information 4-10write access to docroot E-9

asp (Active Server Pages) 10-8scripts 10-11

ASP Page Generatorconfiguration information 4-11

asp-id.log filelocation B-7

August 2001 Vignette Confidential Index-1

Index Administration Guide

B-b option

for the transferproject command 12-17Base Project

can’t delete 12-29management ID 12-24owners 5-4, 5-16

basic setup 1-3bob (Dispatch Service)

configuration information 4-4process description A-18

bob.log filelocation B-8

bob.pid filelocation B-9

browsercapabilities 10-2Preferences file 6-17, B-38

Business Center Full role 5-6Business Center Partial role 5-6BY_STATUS template command 7-22

CCA (Certificate Authority) D-13Cache Manager (cmd) process A-20campadmin program task

location A-19Campaign Logging Agent (cld) process

A-20CDS

adjusting page generation timeouts 11-3

cmd (Cache Manager) process A-20configuring outside firewall with http

proxy E-11considerations when stopping 8-5ctld (Tcl Page Generator) process A-21development mirroring live F-14files and directories 6-14

flushing cache 10-9increasing page generation requests

11-2increasing page generation slave

processes 11-2mapping front door CURL 10-2obtaining status 8-7outside firewall E-4pad (Placement Agent) process A-34preview preferences file 6-16process information

in Details Window 4-8in Primary window 4-8

process names 3-6restricting access 11-10setting up virtual hosting F-1starting using Platform Manager 8-9static files B-40stopping using Platform Manager 8-9subcomponents 3-6tmd (Template Manager) process A-40tools client security file 6-16using proxy server for outbound

connections to E-11viewing information about 4-5viewing process information 4-7

cds.cfg filelocation B-10

cert7.db security file D-14Certificate Authority (CA) 6-17, D-13certificates

accepting D-16and keys for LDAP security D-12gencert command A-27installing D-16

cfgedit (with admin command) A-12, A-13cfgpassword.log file

location B-11cgutil command A-19

Index-2 Vignette Confidential August 2001

Administration Guide Index

changingdefault content database 7-26log level A-13

ci_mgmt_id A-33cld (Campaign Logging Agent)


cld-id.log filelocation B-12

cld-id.pid filelocation B-13

cld-id-timestamp.log filelocation B-14

CLEAR_CACHE template command 10-9, A-25

clearingdisk cache for docroot 11-6pages from root path 10-9

client certificategetting D-14

closingAdmin Center tools 3-7

cmd (Cache Manager)behavior when page regeneration fails

11-9configuration information 4-8enabling cached page regeneration

11-8method used to regenerate cached

pages 11-8process description A-20setting POOL_SIZE variable 11-6threads to flush cache 11-6triggering events for flushing cache

11-6cmd.log file

location B-15cmd.pid file

location B-16CMD_ACTION variable 10-9

CMS(bob) Dispatch Service process A-18(ted) Event Service process A-39(vhs) Request Service process A-54commands 5-2considerations when stopping 8-5files and directories 6-13increasing request handling 11-6obtaining status 8-7process information

in Details window 4-4in Primary window 4-3

process names 3-6restricting access 11-10starting using Platform Manager 8-9starting using Start menu 8-8stopping using Platform Manager 8-9stopping using Start menu 8-8viewing information about 4-2viewing process information 4-3

CMS commandsusers and groups 5-2

cms.cfg file 6-4, B-16location B-16

cmscppapi.cfg filelocation B-17

commandcgutil A-19encrypt A-22gencert A-27RESET_TIMEOUT 11-3transferproject A-40

common variables 1-5communication

between components E-4between processes E-4enabling between components E-3enabling between tools and

components E-7tools to component E-7tools to process E-7



COMPONENT command 10-3components

starting and stopping 8-2config utility A-21

location A-21, A-56using to configure the VCMS software

to use LDAP D-39config.log file

location B-18configuration file

cds.cfg B-10cms.cfg B-16cmscppapi.cfg B-17host.cfg B-23insts.cfg B-24manifest B-27mcs.cfg B-30obj.conf B-33oms.cfg B-36paths 6-5refreshing variables 8-6security.cfg B-39ws.cfg B-52

configuration informationape (Application Engine) 4-10ASP Page Generator 4-11bob (Dispatch Service) 4-4cld (Campaign Logging Agent) 4-16cmd (Cache Manager) 4-8ctld (Tcl Page Generator) 4-11mcd (Multi-Channel Delivery Agent)

4-20MCS plug-in 4-21omd (Observation Manager) 4-17pad (Placement Agent) 4-9ted (Timed Event Service) 4-4tmd (Template Manager) 4-10vhs (Request Service) 4-4vrd (Router) 4-17

vwd (MCS Watchdog) 4-20vwd (OMS Watchdog) 4-18web server 4-13

configuration toolconfig utility A-21, A-55

configuration variableCONNECT_RETRIES D-20EUR_ENABLE_AUTO_REGISTRA

TION D-20configuration variables

CONTENT_DB_CONNECTION_CLASS 7-28

CONTENT_DB_CONNECTION_URL 7-29

Configuration Viewprimary window 3-3

configuringCDS outside firewall with http proxy

E-11CDS to docroot access E-9CDS to metafiles cache access E-9considerations for high-demand pages

11-8development CDS with virtual servers

F-14number of required ports E-3, E-7one or more content databases separate

from the system database 7-13ports for process communication E-3ports for tools communication E-7the VCMS software and LDAP

connectionroadmap D-11

the VCMS software to use LDAProadmap D-3

VCMS software to use LDAP D-1post-requisite steps D-52

VCMS tools outside firewall with SOCKS proxy E-12

virtual hosting F-1



virtual hosting for Apache or IHS web servers F-11

virtual hosting for IIS web servers F-6virtual hosting for iPlanet web servers

F-5CONNECT_RETRIES configuration

variable D-4, D-20content

database 1-3file system 1-3

content databaseand production management 7-17changing default 7-26configuring multiple 7-13different type from system database

7-7name collisions with multiple 7-18performance issues for separate 7-15

content types 1-3CONTENT_DB_* variables 7-3creating

records for legacy data 7-34ctld (Tcl Page Generator)

configuration information 4-11process description A-21templates directory B-43

ctld.tcl file 6-5, B-21location B-21path 6-6

CTLD_INTERP_INTERVAL variable 6-5ctld-id.#.infolog file

location B-19ctld-id.#.log B-20ctld-id.pid file

location B-21, B-26CURL command F-15

Ddatabase

authorization 7-5changing table ownership 7-9configuration variables 7-6content tables 7-2content types 1-3granting SELECT permissions 7-10password encryption 7-5permissions 7-4second login 7-8size 7-5system tables 7-2, C-2versioned content 7-31

database environment variablesfor transferproject command 12-17

database password encryptionencrypt command 7-11in templates 7-23

database variablessetting in templates 7-19setting to default values 7-22

deletingdatabase content with transferproject

12-30project data with transferproject 12-29

delivery.tcl file 6-5, B-22path 6-6

Developer role 5-5directory

metafiles B-32metatemplates-id B-32staticfiles B-40tedtasksworkingdir B-43templates-id B-43



disablinginterpretation of COMPONENT

results 10-5parsing on iPlanet 10-4server-side includes 10-5

Dispatch Service (bob) process A-18dist directory

with transferproject command 12-42DN (distinguished name) D-11docroot

restoring 9-6docroot directory B-23

location B-23read-only access from web servers E-2setting up for virtual hosting F-4

Docroot Managerwrite access to docroot E-9write access to metafiles cache E-9

E-e option

for the transferproject command 12-4editing

iPlanet obj.conf file 10-5e-mail

enabling notifications 5-13SMTP server 5-13

enablingcmd to regenerate cached pages 11-8communication between components

E-3communication between tools and

components E-7parsing 10-3

encrypt command 7-11, A-22location A-22

encryptiondatabase password 7-5in templates 7-13

environment variablessetting for transferproject 12-17

error logging 6-10levels 6-11

error logging levels A-14error messages

syslogd(1M) on Solaris 6-10, B-31viewing 6-11

EUR_ENABLE_AUTO_REGISTRATION configuration variable D-4, D-20

Event Service (ted)process description A-39tedtasksworkingdir directory B-43

Event Viewer 6-11EventLog service 6-10expire program task A-23

location A-23options A-24-r option A-23

exportingdatabase content with transferproject

command 12-25project data with transferproject 12-20

F-f option

for transferproject command 12-41file

CDS 6-14CMS 6-13for configuration 6-4for Tcl interpreter 6-5in transferproject project package

12-13listing 6-2logs 6-9obj.conf 10-4path for configuration 6-5



pid 6-9Preferences 6-16security.cfg 6-16

firewallconfiguring CDS outside with http

proxy E-11holes required for remote processes

E-3holes required for remote VCMS tools

E-7VCMS tools outside with SOCKS

proxy E-12flushcache program task

location A-25options A-26scheduling 10-10

forcingcomponents to reread configuration

file 8-2front door

mapping to CURL 10-2virtual hosting F-14

Ggencert command A-27

location A-27options A-28

general concepts 1-3GET_NEXT_ID command 7-18getting

a server or client certificate D-14group

adding entry 5-15Admin 5-4attributes 5-7cloning entry 5-15defined 5-2deleting entry 5-15

editing entry 5-15name guidelines 5-15reserved ID 5-4

guest user 5-4

HHOST variable

altering value for IP alias E-10host.cfg file

location B-23HTTP proxy server

using to regulate outbound connections E-11

HTTPD_COMPONENTSCAN variable 10-5

HTTPD_FDCURL variable 10-2

I-i option

for the transferproject command 12-26IIS

parsing 10-7importing

database content with transferproject command 12-25

project data with transferproject command 12-23

importing projectsconflicts 12-18

improvingperformance for high-demand pages

11-8inboundmail program task A-29

options A-30INCLUDE LIB command and transferring

projects 12-32



increasingallowed static file submissions 11-6allowed template operations 11-6request handling 11-6

increasing performancemethods for different configurations

11-2installing

a certificate D-16install-path variable 1-5insts.cfg file

location B-24Internal-use-only template

launch A-32internationalization, with LDAP D-21IP address

access to servers 11-10for virtual hosting F-3

IP aliasesconfiguring VCMS installation for

their use E-10iPlanet

disabling server-side includes 10-5NSAPI configuration file B-33obj.conf file 10-4parsing 10-4

IUSR_hostname 10-8

Jjsp-id.log file

location B-25

K-k option

for the transferproject command 12-27key3.db security file D-14keys

gencert command A-27

Llaunch program task A-32


LD_LIBRARY_PATH environment variable

for transferproject command 12-17LDAP

and internationalization D-21and localization D-21and the User Manager 5-1configuration D-3, D-25defined D-1making schema and database changes

D-17non-secure connection to the CMS D-7password-related user management

with D-52performing user and group

administration with D-5roadmap for configuring connection

with the CMS D-11roadmap for configuring the VCMS

software to use D-3role definitions D-52secure connection D-9server-side limit

lookthroughlimit D-56sizelimit D-56

SSL certificates and keys D-12steps for configuration D-23using config utility to configure for

VCMS software use D-39legacy data

making available to VCMS installation 7-33

templates provided to handle 7-34lightweight directory access protocol

(LDAP) D-1listiis utility F-8



loadingproject package using config program

9-4project package using Platform

Manager 9-3localization, with LDAP D-21log file 6-9

asp-id.log B-7bob.log B-8cfgpassword.log B-11cld-id.log B-12cld-id-timestamp.log B-14cmd.log B-15config.log B-18ctld-id.#.infolog B-19ctld-id.#.log B-20for each process 6-9for numbered slave processes 6-9jsp-id.log B-25level of logging 6-10maximum size 6-10mcd-id.#.log B-29mcd-id.deliver.log B-28messages file B-31omd-id.log B-34pad.#.log B-37path to 6-9ted.log B-41tmd-id.log B-44upgrade.log B-46vhs.#.log B-47vrd-id.log B-48vwd.log B-50

LOG template command B-19LOG_LEVEL variable 6-10login defaults file B-38lookthroughlimit

LDAP server-side limit D-56

MMacro Editor

UsrMacroData.xml file B-46macros

created by user B-46making

a non-secure connection to LDAP D-7LDAP schema and database changes

D-17management ID

of Base Project 12-24managing

groups 5-15roles 5-18users 5-4

manifest filelocation B-27

mappingroot path to front door CURL 10-2

MAX_LOG_SIZE variable 6-10mcd (Multi-Channel Delivery Agent)


mcd-id.#.log filelocation B-29

mcd-id.deliver.log filelocation B-28

mcd-id.pid filelocation B-30

MCSmcd (Multi-Channel Delivery Agent)

process A-34obtaining status 8-7process information


process names 3-6stopping using Platform Manager 8-9viewing information about 4-18



viewing process information 4-19vwd (Watchdog) process A-55

MCS plug-inconfiguration information 4-21

mcs.cfg file 6-4location B-30

messages file 6-10location B-31

metafiles directorylocation B-32

metatemplates-id directorylocation B-32

methodsfor starting and stopping processes 8-2

movingtransferproject project package 12-31

N-n option

for the transferproject command 12-35next_id table

with transferproject command 12-12NSAPI

obj.conf file B-33

Oobj.conf file

location B-33Observation Manager (omd) process A-34omd (Observation Manager)


omd-id.log filelocation B-34

omd-id.pid filelocation B-35

OMScld (Campaign Logging Agent)

process A-20obtaining status 8-7omd (Observation Manager) process

A-34process information


process names 3-6starting using Platform Manager 8-9stopping using Platform Manager 8-9viewing information about 4-14viewing process information 4-15vrd (Router) process A-54vwd (Watchdog) process A-55

oms.cfg file 6-4, B-36location B-36

optimizingparse-html on iPlanet 10-6

ORACLE_HOME environment variablefor transferproject command 12-17

Ppad (Placement Agent)


pad.#.log filelocation B-37

pad.pid filelocation B-38

Page Generatoradjusting timeouts 11-3ctld.tcl file B-22delivery.tcl file B-22increasing requests 11-2increasing slave processes 11-2setting timeout in templates 11-4setting timeouts 11-3templates directory B-43timeouts 11-3



pagesconfiguring for high demand 11-8

parse-html function 10-4parsing

control for IIS 10-7disabling on iPlanet 10-4enabled by default on iPlanet 10-4enabling 10-3on Apache 10-8

passworddefault for admin 5-11for database 7-5setting admin 5-11

password-related user managementwith LDAP D-52

performance concernsrequest handling 11-6

performinguser and group administration using

LDAP D-5permissions

CDS to write to docroot E-9CDS to write to metafiles cache E-9

PG_WRITES_CACHED_PAGES variable E-9

pid file 6-9bob.pid B-9cld-id.pid B-13cmd.pid B-16ctld-id.pid B-21, B-26mcd-id.pid B-30omd-id.pid B-35pad.pid B-38path 6-9ted.pid B-42tmd-id.pid B-45vhs.pid B-48vrd-id.pid B-49vwd.pid B-51

Placement Agent (pad) process A-34

Platform Managerprivileges required to use 9-2using for configuration tasks 9-2using to load project 9-3using to restore docroot 9-6

PM_CONTENT_DB_NUMBER variable 7-31

PM_CONTENT_DBn_DATABASE variable 7-31

PM_CONTENT_DBn_PASSWORD variable 7-31

PM_CONTENT_DBn_PASSWORD_ENCRYPTED variable 7-31

PM_CONTENT_DBn_RWDBLIB variable 7-31

PM_CONTENT_DBn_SERVER variable 7-32

PM_CONTENT_DBn_SERVERNAME variable 7-32

PM_CONTENT_DBn_SID variable 7-32PM_CONTENT_DBn_TEXTSIZE

variable 7-32PM_CONTENT_DBn_USERNAME

variable 7-32PM_CONTENT_DBx_TYPE variable

7-32POOL_SIZE variable 11-6ports

configuring for process communication E-3

configuring for tools communication E-7

Preferences file 6-16, B-38private keys

gencert command A-27process

bob (Dispatch Service) A-18changing log level A-13cld (Campaign Logging Agent) A-20cmd (Campaign Logging Agent) A-20



ctld (Tcl Page Generator) process A-21mcd (Multi-Channel Delivery Agent)

A-34omd (Observation Manager) A-34pad (Placement Agent) A-34tmd (Template Manager) A-40vhs (Request Service) A-54vrd (Router) A-54vwd (Watchdog) A-55

processesstarting and stopping 8-2viewing 3-5viewing using Configuration View 4-2

Production Centerflushcache program task 10-9, A-25inboundmail program task A-29launch program task A-32Preferences file 6-17setting e-mail preferences 5-12tool directories 6-16transferproject command A-40

PROFILE_MARK template command 7-22

program taskcampadmin A-19expire A-23flushcache A-25inboundmail A-29launch A-32pzndelete A-35reseteur A-37, D-5sgutil A-39version A-49

project IDswith transferproject command 12-19

project packagecontents with transferproject command

12-41description of files with transferproject

command 12-13

dist directory with transferproject command 12-42

loading 9-3loading using config program 9-4loading using Platform Manager 9-3moving with transferproject command

12-31removing 9-3with transferproject command 12-10

project_mgmt_id A-33projects

Base Project management ID 12-20, A-43

finding IDs 12-19transferring between CMSs 12-1VCMS project data and database

content 12-11proxy server

HTTP E-11SOCKS E-12

PROXY_HOST variable E-11PROXY_PORT variable E-11pzndelete program task A-35

examples A-36options A-36syntax A-35

R-R option

for the transferproject command 12-22-r option

for the transferproject command 12-22reconfiguring

initial VCMS software/LDAP configuration D-24, D-52

recordnecessary for production management

7-17special meaning to VCMS software

7-16



referenced configuration variables 8-6refreshfromdb (with admin command)

A-16refreshing configuration variables

with values from the database 8-6, A-16

REGENERATE_ACCESS_TIME variable 11-8

REGENERATE_CONCURRENCY_LIMIT variable 11-9

REGENERATE_CONCURRENCY_WAIT variable 11-9

REGENERATE_PAGE variable 11-8removing

pages from CDS cache 10-9project package using config program

9-5project package using Platform

Manager 9-4Request Service (vhs)

process description A-54staticfiles directory B-40

requirements and restrictionsfor transferring projects between

CMSs 12-3RESET_TIMEOUT command 11-4

syntax 11-4reseteur program task A-37, D-5


restoringcorrupted docroot 9-6

roadmapfor configuring a connection between

the CMS and LDAP D-11for configuring the VCMS software to

use LDAP D-3

roleadding entry 5-19attributes 5-8authorization 5-5Business Center Full 5-6Business Center Partial 5-6cloning entry 5-19defined 5-2definitions when using LDAP D-52deleting entry 5-19Developer 5-5editing entry 5-19if user has none 5-6name guidelines 5-19System 5-5

rootmapping front door 10-2

Router (vrd) process A-54row

special meaning to VCMS software 7-16

S-s option

for the transferproject command 12-4schema restrictions

checking when importing with transferproject 12-28

search timeout setting D-20secure connection between LDAP and the

CMS D-9security.cfg file 6-16

location B-39self-registration

enabling 5-12server certificate

getting D-14



server componentsviewing using Configuration View 4-2

service dependencies 2-3setting

database variables in templates 7-19page generation timeouts 11-3pages regenerated by cmd 11-8TEMPLATE_SYSTEM_DB_*

variables 7-9variables for default content database

7-27sgutil program task A-39sizelimit

LDAP server-side limit D-56SMTP server 4-3, 5-13SOCKS proxy server

specify by changing VCMS tools shortcut E-13

specify using command line E-13using for outbound connections to

VCMS tools E-12Solaris

pid files 6-9Solaris configuration tool

config program 9-3SSL certificates and keys D-12starting

processes using admin command 8-3staticfiles directory

location B-40status

of transferred content items 12-39steps

to configure the VCMS software to use LDAP D-23

stoppingprocesses using admin command 8-3

stopping CDSspecial considerations 8-5

stopping CMSspecial considerations 8-5

summary of chapters 1-3SYBASE environment variable

for transferproject command 12-17syntax

transferproject command 12-14syslogd(1M) 6-10, B-31system database

logical parts 7-2system content 7-2user content 7-2visitor information 7-2

system database tablescomplete list of C-2description of each C-2

System role 3-2, 5-5system tables

granting SELECT permissions 7-10SYSTEM_DB_* variables 7-3

T-t option

for the transferproject command 12-24tables

system database C-2tar format

with transferproject command 12-41tasks

ongoing 2-3post-installation 2-2

Tcl interpreter files 6-5Tcl Page Generator (ctld) process A-21ted (Event Service)

configuration information 4-4process description A-39tedtasksworkingdir B-43

ted.log filelocation B-41



ted.pid filelocation B-42

tedtasksworkingdir directorylocation B-43

Template DeveloperPreferences file 6-17

template environmentconfiguring second login 7-8

template location B-32, B-33, B-44Template Manager (tmd)

process description A-40templates directory B-43

TEMPLATE_SYSTEM_DB_* variables 7-3

TEMPLATE_SYSTEM_DB_USERNAME variable 7-9

templatesand virtual web servers F-15asp scripts 10-11database password encryption 7-23directory B-43encryption 7-13legacy 7-34provided to create records 7-34using RESET_TIMEOUT command

11-4templates-id directory

location B-43testing

virtual hosting F-13threads

available for clearing cache 11-6timeouts

for the web server 11-4setting for Page Generator 11-3

tmd (Template Manager)configuration information 4-10process description A-40stopping and starting 8-5templates directory B-43

tmd-id.log filelocation B-44

tmd-id.pid filelocation B-45

tool directories 6-16tools client

Certificate Authority 6-17transferproject command 9-3, A-40

-b option 12-17Base Project 12-6Base Project management ID 12-20,

A-43can’t delete Base Project 12-29case sensitivity 12-28column sizes 12-28conflicts 12-18content status 12-40contents of project package 12-41datatypes 12-28DB2_DIR environment variable 12-17deleting content data 12-30deleting database content 12-30deleting project data 12-29dist directory 12-42-e option 12-40environment variables on Solaris 12-17export 12-5exporting database content 12-25exporting project data 12-20exporting project data and database

content together 12-21-f option 12-41file properties 12-37files in project package 12-13finding project IDs 12-19-i option 12-26import 12-5import conflicts 12-18importing database content 12-25importing project data 12-23INCLUDE LIB command 12-32



items that must be unique 12-18-k option 12-27keywords

projects 12-33records 12-37templates 12-36

LD_LIBRARY_PATH environment variable 12-17

location 12-14moving the project package 12-31-n option 12-38next_id table 12-26options A-42ORACLE_HOME environment

variable 12-17overview 12-5permissions, user IDs, and

authorizations 12-16project and content item properties

transferred 12-33project data and database content 12-11project package 12-10project properties 12-33properties transferred, inherited, and

replaced 12-33purge file 12-30-R option 12-22-r option 12-22record properties 12-36requirements and restrictions 12-3-s option 12-4schema restrictions 12-28sequence 12-10status codes A-41status of transferred content items

12-39SYBASE environment variable 12-17syntax 12-14, A-41-t option 12-24tar and zip format 12-41

template IDs 12-26import conflicts 12-18

things to do after transferring 12-32transferring one or more content items

12-21types of transfer 12-10VCMS project data and database

content 12-11versioned content 12-38versions of 12-3workflow 12-37-z option 12-18

tuningtips for VCMS software 11-2

Uupgrade.log file

location B-46user

adding entry 5-9admin 5-4attributes 5-7authorization 5-4cloning entry 5-9defined 5-2deleting entry 5-9editing entry 5-9e-mail preferences 5-12enabling self-registration 5-12name guidelines 5-9reserved IDs 5-4viewing information 5-2without roles 5-6

user and group administrationusing LDAP D-1

User Manager 3-2primary window 3-4



usingan existing LDAP user repository D-3CURLS 10-2LDAP to perform user and group

administration D-1legacy templates 7-34

UsrMacroData.xml file B-46utility

config A-21, A-55

Vvariable

for paths 1-5refreshing 8-6settings 11-1

variations 10-2VCMS software

documentation B-23VCMS tools

configuring outside firewall with SOCKS proxy E-12

Help menu 3-7launch bar 3-2online help 3-7outside the firewall E-7

version program task A-49location A-49options A-50project task defaults A-52workflow task defaults A-52

versioningand databases 7-31

vhs (Request Service)configuration information 4-4process description A-54staticfiles directory B-40

vhs.#.log filelocation B-47

vhs.pid filelocation B-48

VhsProtoDocRoot directory B-40viewing

log information on Solaris 6-10log information on Windows 6-11VCMS processes 3-5

Vignette subdirectory B-39virtual hosting

Apache and IHS web servers F-11configuring F-1iPlanet web servers F-5Microsoft IIS web servers F-6testing F-13

virtual web serverdevelopment CDS F-14front door F-14static files F-16

visitor databaseseparate 7-10

VISITOR_DB_* variables 7-3vrd (Router)


vrd-id.log filelocation B-48

vrd-id.pid filelocation B-49

vwd (MCS Watchdog)configuration information 4-20

vwd (OMS Watchdog)configuration information 4-18

vwd (Watchdog) process A-55vwd.log file

location for MCS B-50location for OMS B-50

vwd.pid filelocation for MCS B-51location for OMS B-51



WWatchdog (vwd) process A-55web server 10-5

adjusting number of processes 11-9configuration information 4-13configuring virtual hosting F-2disabling iPlanet parsing 10-4disabling server-side includes 10-5docroot directory B-23iPlanet obj.conf.vgnbak file B-33mapping front door 10-2outside the firewall E-3parse-html function 10-4parsing 10-3parsing on Apache 10-8parsing with IIS 10-7preview preferences file 6-17setting the timeout 11-4

Windows configuration toolPlatform Manager 9-2

write accessApplication Engine to docroot E-9Docroot Manager to docroot E-9Docroot Manager to metafiles cache

E-9ws.cfg file 6-4

location B-52

Z-z option

for the transferproject command 12-6zip format

with transferproject command 12-41


vignette content management server v6 administration guide

Documents