Vignette Content Management Server V6 Administration Guide

Vignette Content Management Server V6
Administration Guide
Version 6.0
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 publications@vignette.com. A member of the Publications team will acknowledge your mail as soon as possible. You can also reach us at the following address: Vignette Corporation 901 South Mo Pac Expressway Building III Austin, TX 78746-5776
ii
Vignette Confidential
August 2001
Contents
1 VCMS Software Basic Concepts
Using This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 Concepts and Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Content Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Basic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3 Common Path Name Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
2 Roadmaps for Getting Started

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

Starting the VCMS Admin Center Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 Using the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 Sorting Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 Expanding Server Entries in Configuration View . . . . . . . . . . . . . . . . . . . . . .3-5 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Closing the Admin Center Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7
4 Viewing VCMS Servers and Processes

Viewing Servers and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 Viewing CMS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 CMS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 Viewing CMS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3 CMS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . . .4-3 CMS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . . .4-4 Viewing CDS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 CDS Information in the Primary Window . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 CDS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 Viewing CDS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7 CDS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . . .4-8 CDS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . . .4-8
August 2001
iii
Contents
Viewing OMS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14 OMS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14 Viewing OMS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15 OMS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . .4-15 OMS Process Information in the Details Window . . . . . . . . . . . . . . . . . . . . .4-16 Viewing VMCS Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18 MCS Information in the Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18 Viewing VMCS Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19 MCS Process Information in the Primary Window . . . . . . . . . . . . . . . . . . . .4-19 VMCS Process Information in the Details Window . . . . . . . . . . . . . . . . . . .4-20
5 Managing VCMS Users, Groups, and Roles

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 Managing Users for a New Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4 Roles Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 The VCMS Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 Monitoring Users, Groups, and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 Viewing User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7 Viewing Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7 Viewing Role Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 Rules for User Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 Adding, Cloning, Editing, or Deleting Users . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10 Enabling Self-registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 Setting E-mail Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15 Rules for Group Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15 Adding, Cloning, Editing, or Deleting Groups . . . . . . . . . . . . . . . . . . . . . . .5-15 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16 Managing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18 Rules for Role Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19 Adding, Cloning, Editing, or Deleting Roles . . . . . . . . . . . . . . . . . . . . . . . . .5-19 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
iv
August 2001
Contents
6 Managing VCMS Files

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 Understanding Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2 Overview of Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3 Initialization Files for the Tcl Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5 log Files and pid Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8 log and pid File Names and Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8 Viewing VCMS Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10 Debugging Templates with the LOG Template Command . . . . . . . . . . . . . . . . .6-12 Other Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13 Other CMS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13 Other CDS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14 Understanding Tool Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16 Understanding Preference Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16 The security.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17 Preferences File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17
7 Managing System and Content Databases

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 System Database Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4 Database Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4 Database Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5 Database Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6 Content Databases of Different Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7 Configuring a Second Login for the Template Environment . . . . . . . . . . . . . .7-8 Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-11 Database Access Through Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13 Configuring One or More Content Databases Separate From the System Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13 Performance and Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-15 Records and Rows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16 Database Content with or without Production Management . . . . . . . . . . . . .7-17 GET_NEXT_ID with Multiple Content Databases . . . . . . . . . . . . . . . . . . . .7-18 Setting Database Variables in Tcl Templates . . . . . . . . . . . . . . . . . . . . . . . .7-19
August 2001
Contents
Changing the Default Content Database . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-26 The Dispatch Service (bob) and Separate Content Databases . . . . . . . . . .7-31 Handling Legacy Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-33 Using the Legacy Record Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-34 Modifying the Legacy Save Template for a Nondefault Database . . . . . . . .7-35 Creating the Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-36 Making the Record Content Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-37
8 Managing VCMS Processes

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 Using the admin Command to Stop and Start Processes . . . . . . . . . . . . . . . . . . . .8-3 CMS Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 CDS Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 Using the admin Command to Reset the Template Manager . . . . . . . . . . . . . . . .8-5 Refreshing Referenced Configuration Variables. . . . . . . . . . . . . . . . . . . . . . . . . .8-6 Obtaining Process StatusSolaris Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7 Checking Page Generator Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 Stopping and Starting a CMS from the Start MenuWindows Only . . . . . . . . .8-8 Starting and Stopping with the Platform ManagerWindows Only . . . . . . . . . .8-9
9 Managing the VCMS Site

Accessing the Platform ManagerWindows Only . . . . . . . . . . . . . . . . . . . . . . .9-2 Loading or Removing a Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3 Synchronizing a Docroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 Gathering Tcl Template Performance Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
10
Working with Web Servers

Mapping the Root Path (/) to a Front Door CURL . . . . . . . . . . . . . . . . . . . . . . .10-2 Working with Web Server Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3 VCMS Software Changes to the obj.conf File on iPlanet . . . . . . . . . . . . . . .10-4 Disabling Parsing on iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4 Optimizing the parse-html Function on iPlanet . . . . . . . . . . . . . . . . . . . . . . .10-6 Parsing on IISWindows Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7 Parsing on Apache (Solaris Only) or IHS (AIX Only) . . . . . . . . . . . . . . . . .10-8 Clearing Pages from a Root Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9 Using ASP Scripts in TemplatesWindows Only . . . . . . . . . . . . . . . . . . . . . .10-11
vi
August 2001
Contents
11
Tuning Your VCMS Installation

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 Increasing Tcl Page Generator (ctld) Requests . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 Adjusting Page Generator Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 Setting Page Generation Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 Using the RESET_TIMEOUT Template Command . . . . . . . . . . . . . . . . . . .11-4 Accommodating Large Database Retrievals . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-5 Increasing Request Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 Setting the Thread Pool Size for the Cache Manager . . . . . . . . . . . . . . . . . . . . .11-6 Enabling the Cache Manager to Regenerate Cached Pages . . . . . . . . . . . . . . . .11-8 Adjusting the Number of Concurrent Web Server Processes . . . . . . . . . . . . . . .11-9 Restricting Access to the Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10 Enabling VCMS Status Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-11
12
Transferring Projects and Tables between CMSs

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 Requirements, Assumptions, and Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 How to Transfer Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5 Exporting and Importing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5 Typical Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10 VCMS Project Data and Database Content . . . . . . . . . . . . . . . . . . . . . . . . .12-11 Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13 transferproject Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14 Transferring Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16 transferproject Permissions and Other Requirements . . . . . . . . . . . . . . . . .12-16 Setting Environment Variables on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . .12-17 Import Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18 Finding Project IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19 Exporting Project Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20 Exporting VCMS Project Data and Database Content Together . . . . . . . . .12-21 Importing VCMS Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-23 Exporting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25 Importing Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25 Deleting Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29 Deleting Database Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-30 Moving a Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-31
August 2001
vii
Contents
Things to Do after Transferring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-32 What Is Transferred and What Isnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-33 General Information about Transferring Projects . . . . . . . . . . . . . . . . . . . . . . .12-38 VCMS Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-38 Parent Project and Status of Imported Content Items . . . . . . . . . . . . . . . . .12-39 Contents of Project Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-41
A VCMS Process Reference

Process Reference Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2 admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5 admin (CDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6 admin (CMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8 admin (VMCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9 admin (OMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10 admin cfgedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12 admin chlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13 admin refreshfromdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16 bob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18 campadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19 cgutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19 cld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20 cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20 config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21 ctld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21 encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-22 expire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23 flushcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25 gencert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-27 inboundmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-29 launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-32 mcd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34 omd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34 pad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34 pzndelete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35 reseteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-37 sgutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39
viii
August 2001
Contents
ted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . transferproject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vhs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . wscfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-39 A-40 A-40 A-49 A-54 A-54 A-55 A-55
B VCMS File Reference

File Reference Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2 adminutil.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6 asp-id.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7 bob.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8 bob.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9 cds.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10 cfgpassword.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11 cld-id.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12 cld-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13 cld-id-timestamp.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14 cmd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15 cmd.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16 cms.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16 cmscppapi.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-17 config.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18 ctld-id.#.infolog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19 ctld-id.#.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20 ctld-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21 ctld.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21 delivery.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-22 docroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-23 host.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-23 insts.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-24 jsp-id.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-25 jsp-id.pid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-26 manifest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-27
August 2001
ix
Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-28 B-29 B-30 B-30 B-31 B-32 B-32 B-33 B-34 B-35 B-36 B-37 B-38 B-38 B-39 B-40 B-41 B-42 B-43 B-43 B-44 B-45 B-46 B-46 B-47 B-48 B-48 B-49 B-50 B-51 B-52 B-53 B-53
August 2001
Contents
C System Database Tables

VCMS System Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
D Configuring the VCMS Software to Use an LDAP User Repository

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3 Understanding How the VCMS Software Integrates with LDAP . . . . . . . . . . . . D-5 Using the VCMS Software without LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . D-5 Using the VCMS Software with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-6 Making a Non-secure Connection to LDAP . . . . . . . . . . . . . . . . . . . . . . . . . D-7 Making a Secure Connection to LDAP without Client Authentication . . . . . D-9 Making a Secure Connection to LDAP with Client Authentication . . . . . . D-10 Security Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-11 Setting up LDAP SSL Certificates and Keys . . . . . . . . . . . . . . . . . . . . . . . . . . D-12 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-12 Getting a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-14 Accepting a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-16 Installing a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-16 Making LDAP Schema and Database Changes . . . . . . . . . . . . . . . . . . . . . . . . D-17 Schema Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-17 Database Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-18 Index Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-19 Making Configuration Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-20 LDAP and Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-21 Configuring the VCMS Software to Use LDAP . . . . . . . . . . . . . . . . . . . . . . . . D-22 Using LDAP Configuration (for Windows Users) . . . . . . . . . . . . . . . . . . . . . . D-25 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-25 Step 1: Starting the LDAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . D-26 Step 2: Setting up the Connection between the VCMS software and LDAP D-28 Step 3: Specifying SSL Certificate Information . . . . . . . . . . . . . . . . . . . . . D-28 Step 4: Choosing Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-29 Step 5: Specifying Client Authentication Information . . . . . . . . . . . . . . . . . D-29 Step 6: Setting up LDAP Access Information . . . . . . . . . . . . . . . . . . . . . . . D-31 Step 7: Setting up the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-33 Step 8: Setting up User Query Information . . . . . . . . . . . . . . . . . . . . . . . . . D-33 Step 9: Setting up User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-34 Step 10: Setting up Group Query Information . . . . . . . . . . . . . . . . . . . . . . . D-35
August 2001
xi
Contents
Step 11: Setting up Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 12: Performing Repository Verification. . . . . . . . . . . . . . . . . . . . . . . . Using the config Command (for Windows and Solaris Users) . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . . . . . . Things to Do After Configuring the VCMS Software to Use LDAP . . . . . . . .
D-36 D-36 D-39 D-39 D-41 D-42 D-43 D-44 D-44 D-46 D-47 D-47 D-48 D-49 D-50 D-50 D-52
Remote Operations
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2 Enabling Communication between VCMS Components . . . . . . . . . . . . . . . . . . E-3 Enabling Communication between VCMS Tools and Components . . . . . . . . . . E-7 CDS File System Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-9 Working with IP Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-10 Outbound Connections through HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . E-11 VCMS Tools Sessions Using SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-12 Specifying the SOCKS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-12
xii
August 2001
Contents
F Configuring Virtual Hosting

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-2 How Virtual Hosting Works with the VCMS Software . . . . . . . . . . . . . . . . . .F-3 Configuring Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-4 iPlanet Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-5 Microsoft IIS Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-6 Apache Web Servers (Solaris Only) and IHS Web Servers (AIX Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-11 Testing the Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-13 Virtual Server Front Doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-14 Virtual Hosting and Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-14 Setting up Development CDSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-14 Creating Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-15 Submitting Static Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-16
Index
August 2001
xiii
Contents
xiv
August 2001
1
Summary: Audience:
VCMS Software Basic Concepts
Basic concepts for administering the Vignette Content Management Server V6 (VCMS) software and a high-level view of tasks. 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 Using This Book Concepts and Terms
Topics include:
August 2001
1-1
Using This Book

This book provides information for both the authorized administrator and other users.
Part I (Chapters 1 through 5) provides an introduction to the 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
August 2001
Concepts and Terms

This 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.
Database content File system content Content that you can sort by database queries. Ideally this includes much of your site content. Content stored directly in the file system, including such static files as graphic, audio, and HTML files that dont change or dont need templates. The web server configured with a CDS delivers these static files in the conventional way.
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.
August 2001
1-3
Figure 1-1:
VCMS components
Host 1 Web Server for Development CDS cds-a Host 2 Web Server for Live CDS cds-b Live CDS cds-b Docroot Manager cmd pad
. . . Multiple Web Servers for cds-b on Multiple Hosts
Host 3 CMS bob vhs ted
Host 4 Development CDS cds-a Docroot Manager cmd pad
Host 5 Live CDS cds-b Application Engine ape-1 tmd-1 ctld-1 asp-1
Application Engine ape-1 tmd-1 jsp-1 ctld-1 asp-1
jsp-1
Host 6 OMS vrd-1 cld-1 omd-1 vwdhost6
Host 7 MCS vwdmcd-1 host7 plug-in
1-4
August 2001
Common Path Name Variables

The common file location (path name) variables used in this book include:
Variable install-path Indicates The path name of the folder or directory in which the VCMS or tools software is installed. For example:

inst-name
W INDOWS C:\Vignette S OLARIS /opt
The name of the VCMS installation, entered at initial installation. Each installation has:

cds-name oms-name mcs-name ws-name
One CMS One or more CDSs and web server modules One OMS (optional) One VMCS (optional)
The name of a CDS, entered when the CDS is configured. The name of an OMS, entered when the OMS is configured. The name of a VMCS, entered when the VMCS is configured The name of a web server module, entered when the web server module is configured.
See also:
Chapter 2, Roadmaps for Getting Started
August 2001
1-5
1-6
August 2001
2
Summary: Audience:
Roadmaps for Getting Started
Two tables for helping you get underway with the Admin Center. Administrators and other users of the Vignette Content Management Server V6 (VCMS) software See Chapter 1, VCMS Software Basic Concepts
Before you begin: Topics include:
Roadmaps
August 2001
2-1
Roadmaps
The 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
1 Familiarize yourself
Description Take some time to learn the Admin Center interface. The admin user and members of the Admin group have wide-ranging privileges. Carefully control administrator authorization. You determine which users will be able to perform various jobs. Assigning authorization by group allows you to give multiple users the same privileges or responsibilities.
See Chapter 3, Understanding the Admin Center Tools Editing a User Entry on page 5-11
with the Admin Center Tools.

2 Change the password
for the admin user ID and (optionally) the guest user ID.
3 Create user entries and
a separate group entry (recommended) for the owners of the Base Project in the Production Center tool set.
4 Determine whether
Chapter 5, Managing VCMS Users, Groups, and Roles
self- registration should be allowed.

5 Set electronic mail
Allow self-registration if users unknown to the database should be able to log in to the VCMS. 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.
Enabling Self-registration on page 5-12 Setting E-mail Preferences on page 5-12
preferences.
2-2
August 2001
What to do
6 Set VCMS-wide
Description 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.
See Initialization Files for the Tcl Interpreter on page 6-5
variables and procedures.
The following table is not arranged sequentially. The list represents a variety of procedures that the admin user might perform.
What to do View configuration information for the CMS, CDS, OMS, VMCS, and their 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. If you are using the Business Center tools, establish authorization for users to operate in the visitor records database. Manage VCMS files. Description The Configuration View provides a quick source of information about the various servers and processes running on your system. Certain services cannot start correctly unless the database service is already running. See Chapter 4, Viewing VCMS Servers and Processes
VCMS Installation and Configuration Guide (printed copy shipped with product)
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
When you install and configure the software and tool sets, the VCMS software creates directories and files used by the various processes. 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 6, Managing VCMS Files and Appendix B, VCMS File Reference Chapter 10, Working with Web Servers
Fine tune your web server.
August 2001
2-3
What to do Manage VCMS processes.
Description 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. 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. 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. You can modify variable settings to increase performance or adjust for different content or products you might be accessing. If your company has multiple CMSs, you may need at times to transfercopya project from one CMS to another. 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. Virtual hosting allows you to set up one CDS to serve multiple virtual web servers.
See Chapter 8, Managing VCMS Processes and Appendix A, VCMS Process Reference Chapter 7, Managing System and Content Databases
Understand the VCMS database.
Delete or restore project packages created with the transferproject utility. Adjust VCMS variables.
Loading or Removing a Project Package on page 9-3 Chapter 11, Tuning Your VCMS Installation Chapter 12, Transferring Projects and Tables between CMSs Appendix E, Remote Operations
Transfer projects from one CMS to another. Configure VCMS hosts outside the firewall.
Set up virtual hosting.
Appendix F, Configuring Virtual Hosting
See also:
Chapter 3, Understanding the Admin Center Tools
2-4
August 2001
3
Summary: Audience:
Understanding the Admin Center Tools
Overview of the Vignette Content Management Server V6 (VCMS) Admin Tools. Administrators and other users of the VCMS software
Before you begin:
See Chapter 1, VCMS Software Basic Concepts See Chapter 2, Roadmaps for Getting Started Starting the VCMS Admin Center Tools Using the Tools Getting Help Closing the Admin Center Tools
Topics include:
August 2001
3-1
Starting the VCMS Admin Center Tools

You 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.
3-2
August 2001
Figure 3-2:
Configuration View primary window
August 2001
3-3
Figure 3-3:
User Manager primary window
3-4
August 2001
Using the Tools

Topics include:
Sorting Entries Expanding Server Entries in Configuration View
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 MultiChannel 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.
See also:
Chapter 4, Viewing VCMS Servers and Processes Chapter 5, Managing VCMS Users, Groups, and Roles
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 CMSs associated processes are not already shown, you can expand the entry to show the CMSs 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.
August 2001
3-5
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)
3-6
August 2001
Getting Help
You 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 Tools

You can exit an individual Admin Center tool from the File menu Close option in the tools primary window. All the tools windows close. You can also close Admin Center tools (and all other 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.
August 2001
3-7
3-8
August 2001
4
Summary: Audience:
Viewing VCMS Servers and Processes
How to use the Configuration View to view more information about CMS, CDS, OMS, and VMCS servers, and associated software processes. Administrators and other users of the Vignette Content Management Server V6 (VCMS) software See Chapter 3, Understanding the Admin Center Tools
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: Note:
The Configuration View primary window updates dynamically when changes are made to the VCMS servers information. The same information available through the Configuration View appears in the Platform Manager. See Accessing the Platform ManagerWindows Only on page 9-2.
August 2001
4-1
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
s To view information about the CMS to which the Configuration View is currently connected: 1 2
In the Configuration View primary window, select the Content Management Server entry. With the cursor on the selected entry, click the right mouse button, and select Details from the menu. The CMS Details window opens with the following fields:
Shows the host and path name where the CMS is installed. For example: W INDOWS isis.example.com:d:\Vignette\ S OLARIS isis.example.com:/opt/vignette/6.0/
Installation:
4-2
August 2001
Name: SMTP Server:
Shows the name of this component, which is Content Management Server (CMS). 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.
Click OK or Cancel to close the window. (Clicking OK commits any changes made by an admin user.)
Viewing CMS Process Information

Summary: Topics include: The Configuration View provides information about each CMS process.
CMS Process Information in the Primary Window CMS Process Information in the Details Window
CMS Process Information in the Primary Window

The columns of the Configuration View primary window display the following information about each CMS process:
Name Host Shows the name of the CMS process (Dispatch Service, Timed Event Service, Request Service) 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
August 2001
4-3
CMS Process Information in the Details Window

The Configuration View primary window shows three processes for the CMS:
Dispatch Service (bob) Timed Event Service (ted) Request Service (vhs) Dispatches all CMS transactions. Tracks timed events for the Dispatch Service. Manages requests for the Dispatch Service.
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.
Installation: Shows the path to the CMS that this process belongs to. For example: isis.example.com/C:/Vignette Name Configuration Identifier: Shows the type of process. Valid types include Dispatch Service, Timed Event Service, and Request Service. Shows the configuration identifier for each CMS process. For example: /cms/bob /cms/ted /cms/vhs Version: for Dispatch Service for Timed Event Service for Request Service
Shows which version of the process is present. For example: 6.0
Host:
Shows the host name and domain that this process executes on. For example: isis.example.com
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 Services working directory. For example: C:/Vignette/inst-kallisto0826 /working/cms/tedtasksworkingdir/
4-4
August 2001
Proto-Docroot: For the Request Service process only
Shows where the static files are stored. For example: C:/Vignette/inst-kallisto0826/working/cms/staticfiles/
Viewing CDS Information

Summary: Topics include: The Configuration View provides information about each CDS connected to a CMS.
CDS Information in the Primary Window CDS Information in the Details Window
CDS Information in the Primary Window

The columns of the Configuration View primary window display the following information about the CDS:
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).
CDS Information in the Details Window

s To view CDS information in the Configuration View primary window: 1
In the Configuration View primary window, select a CDS entry.
August 2001
4-5
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:
Shows the host and path name where the CMS for the CDS is installed. For example: W INDOWS isis.example.com/C:/Vignette/ S OLARIS isis.example.com:/opt/vignette/6.0/
Installation:
Name:
Shows the name of the CDS in cds-hostname format. For example: cds-dev_osiris
Configuration Identifier: Docroot Path:
Shows the configuration identifier for this CDS. For example: /cds-dev_osiris Shows the location of the directory mapped to the web server s front door. For example: W INDOWS c:\kallisto S OLARIS /install/isis/docroot/ourdocs
Type: Observation Management Server: Database Name:
Shows the designation of the CDS, either Development (inaccessible from the web) or Live (accessible from the web). Shows the Observation Management Server (OMS) that is associated with this CDS. For example: /oms-osiris 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: W INDOWS DB2, MSSqlServer, Oracle, Sybase S OLARIS DB2, Oracle, Sybase AIX DB2
Database User:
Shows the user login for accessing this database. For example: kallisto2
4-6
August 2001
Viewing CDS Process Information

Summary: Topics include: The Configuration View provides information about each CDS process.
CDS Process Information in the Primary Window CDS Process Information in the Details Window
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:
Docroot Manager (dm) Cache Manager (cmd) Placement Agent (pad) Application Engine (ape) Template Manager (tmd) Page Generator (ctld) Contains the cmd (Cache Manager) and pad (Placement Agent) for a CDS instance. Maintains cached content so that only dynamic information needs to be generated from the database. See also cmd on page A-20. 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. Contains the tmd (Template Manager) and page generator processes. There can be one or more Application Engines associated with a CDS. Manages templates and updates the page generator concerning new or modified templates. See also tmd on page A-40. 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. 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.
Web Server (ws)
August 2001
4-7
CDS Process Information in the Primary Window

The columns of the Configuration View primary window display the following information about each CDS process:
Name: Host: Shows the name of the process: Cache Manager, Page Generator, Template Manager, Placement Manager, Web Server (for example, ws-isisnet451). Shows the host and domain on which the process runs. For example: isis.example.com Port: Shows the port number that the process uses. For example: 3740
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
Installation: Shows the pathname to the CMS with which this CDS is associated. For example: isis.example.com:C:/Vignette/ Content Delivery Server (CDS): Process: Configuration Identifier: Version: Specifies the CDS of which this process is a part. For example: cds-dev_osiris 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 Shows which version of the process is present. 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
4-8
August 2001
Port:
Shows the port number over which this process communicates. For example: 3741
Docroot Path:
Shows the location of the directory mapped to the web server s front door. For example: W INDOWS C:\kallisto S OLARIS /install/isis/docroot/ourdocs
Status:
Shows OK if this process is running. If the process is not running, an error message opens.
Placement Agent Details

Installation: Shows the pathname to the CMS with which this CDS is associated. For example: isis.example.com:C:/Vignette/ Content Delivery Server (CDS): Process: Configuration Identifier: Version: Specifies the CDS of which this process is a part. For example: cds-dev_osiris Shows the name of this process, which is Placement Agent. Shows the configuration identifier for this CDS process. For example: /cds-dev_osiris/dm/pad Shows which version of the process is present. 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 Port: Shows the port number over which this process communicates. For example: 3739 Docroot Path: Shows the location of the directory mapped to the web server s front door. For example: W INDOWS c:\kallisto S OLARIS /install/nemo/docroot/ourdocs Status: Shows OK if this process is running. If the process is not running, an error message opens.
August 2001
4-9
Application Engine Details

Name: COM Extensions Enabled: Java Extensions Enabled: Shows the name of this component, which is Application Engine. If true, template developers can access Windows COM objects from their Tcl templates. See the Tcl: COM Extension Programmers Guide and Reference for more information. If true, template developers can include Java within their Tcl templates. See the Tcl: Java Extension Programmers Guide and Reference for more information.
Template Manager Details

Installation: Shows the pathname to the CMS with which this CDS is associated. For example: isis.example.com:C:/Vignette/ Content Delivery Server (CDS): Process: Configuration Identifier: Version: Specifies the CDS of which this process is a part. For example: cds-dev_osiris Shows the name of this process, which is Template Manager. Shows the configuration identifier for this CDS process. For example: /cds-dev_osiris/ape/tmd/tmd-1 Shows which version of the process is present. 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 Port: Shows the port number over which this process communicates. For example: 3740 Status: Shows OK if this process is running. If the process is not running, an error message opens.
4-10
August 2001
Tcl Page Generator Details

Installation: Shows the pathname to the CMS with which this CDS is associated. For example: isis.example.com:C:/Vignette/ Content Delivery Server (CDS): Process: Configuration Identifier: Version: Specifies the CDS of which this process is a part. For example: cds-dev_osiris Shows the name of this process, which is TCL Page Generator. Shows the configuration identifier for this CDS process. For example: /cds-dev_osiris/ape/pg/ctld/ctld-1 Shows which version of the process is present. 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 Port: Shows the port number over which this process communicates. 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. Shows OK if this process is running. If the process is not running, an error message opens.
Status:
August 2001
4-11
JSP Page Generator Details

Installation: Shows the pathname of the VCMS installation. For example: C:/Vignette/ Content Delivery Server (CDS): Process: Configuration Identifier: Version: Specifies the CDS of which this process is a part. For example: cds-dev_osiris Shows the name of this process, which is JSP Page Generator. Shows the configuration identifier for this CDS process. For example: /cds-dev_osiris/ape/pg/jsp/jsp-1 Shows which version of the process is present. For example: 6.0 Host: Shows the host name where the JSP Page Generator process runs. For example: isis.example.com Port: Shows the web server port number over which this process communicates. For example: 7001 Writes Cached Pages: Template Cache: falseA JSP Page Generator never writes cached pages to the web server docroot; the web server associated with the JSP Page Generator does. 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: Context Prefix: The port used by the VCMS software to notify the Servlet Engine of JSP template changes. For example: 4680 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 Status: Shows OK if this process is running. If the process is not running, an error message opens.
4-12
August 2001
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. For example: isis.example.com Port: Shows the port number over which the process communicates. For example: 8080 Docroot Path: Shows the location of the directory mapped to the web server s front door. For example: W INDOWS c:\isis\home S OLARIS /install/isis/docroot/ourdocs Type: Shows what type of web server this is: iPlanet, Apache, Microsoft Internet Information Server (IIS), or IBM HTTP Server (IHS):

Instance:
NSAPI for iPlanet APACHE for Apache ISAPI for IIS IBMHTTP for IHS
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/
August 2001
4-13
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: Configuration Identifier: Host: Shows the name of this component, which is Observation Management Server (OMS). Shows the configuration identifier for this CDS process. For example: /oms-osiris Shows the host name and domain on which this OMS runs. For example: isis.example.com 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.
4-14
August 2001
Viewing OMS Process Information

Summary: Topics include: The Configuration View provides information about each OMS process.
OMS Process Information in the Primary Window OMS Process Information in the Details Window
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:
Campaign Logging Agent (cld) Observation Manager (omd) Router (vrd) Watchdog (vwd) Logs visitor, visitor context, and profile mark information that is used as feedback data for campaigns. Manages visitor records and visitor context objects. Routes external messages to the other OMS processes. Monitors the other OMS processes.
OMS Process Information in the Primary Window

The columns of the Configuration View primary window display the following information about each OMS process:
Name: Host: Shows the name of the process: Campaign Logging Agent, Router, Observation Manager, Watchdog (for example, vwd-isis.example.com). Shows the host and domain on which the process runs. For example: isis.example.com Port: Shows the port number that the process uses. For example: 3740
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.
August 2001
4-15
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: Configuration Identifier: Version: Shows the name of this process, which is Campaign Logging Agent. Shows the configuration identifier for this process. For example: /oms-dev_osiris/cld 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: isis.example.com Port: Shows the port number over which this process communicates. For example: 3741 Status: Shows OK if this process is running. If the process is not running, an error message opens.
4-16
August 2001
Router Details
Name: Configuration Identifier: Version: Shows the name of this process, which is Router. Shows the configuration identifier for this process. For example: /oms-dev_osiris/vrd/vrd-1 Shows which version of this process is present. For example: 6.0 Host: Port: Shows the host name and domain on which this process runs. For example: isis.example.com Shows the port number over which this process communicates. For example: 3741 Status: Shows OK if this process is running. If the process is not running, an error message opens.
Observation Manager Details

Name: Configuration Identifier: Version: Shows the name of this process, which is Observation Manager. Shows the configuration identifier for this process. For example: /oms-dev_osiris/omd/omd-1 Shows which version of this process is present. For example: 6.0 Host: Port: Shows the host name and domain on which this process runs. For example: isis.example.com Shows the port number over which this process communicates. For example: 3741 Status: Shows OK if this process is running. If the process is not running, an error message opens.
August 2001
4-17
Watchdog Details
Name: Configuration Identifier: Version: Shows the name of this process, which is Watchdog. Shows the configuration identifier for this process. For example: /oms-dev_osiris/vwd/vwd-isis.example.com Shows which version of this process is present. For example: 6.0 Host: Port: Shows the host name and domain on which this process runs. For example: isis.example.com Shows the port number over which this process communicates. For example: 3741
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: Configuration Identifier: Host: Shows the name of this component, which is Multi-Channel Server (VMCS). Shows the configuration identifier for the VMCS. For example: /mcs-1 Shows the host name and domain on which the VMCS runs. For example: isis.example.com Port: Shows the port number that the VMCS uses. For example: 3746
4-18
August 2001
Viewing VMCS Process Information

Summary: Topics include: The Configuration View provides information about each VMCS process.
MCS Process Information in the Primary Window VMCS Process Information in the Details Window
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:
Multi-Channel Delivery Agent (mcd) Delivery Channel Plug-in (dcp) Watchdog (vwd) Delivers delivery documents generated by style templates to the Delivery Channel Plug-ins. Delivers delivery documents via multiple delivery channels. Monitors the other VMCS processes.
MCS Process Information in the Primary Window

The columns of the Configuration View primary window display the following information about each VMCS process:
Name: Host: Shows the name of the process: Multi-Channel Delivery Agent, Delivery Channel Plug-in, Watchdog (for example, vwd-isis.example.com). Shows the host and domain on which this process runs. For example: isis.example.com Port: Shows the port number that the process uses. For example: 3740
August 2001
4-19
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
Name: Configuration Identifier: Version: Shows the name of this process, which is Multi-Channel Delivery Agent. Shows the configuration identifier for this process. For example: /mcs-1/mcd/mcd-1 Shows which version of this process is present. For example: 6.0 Host: Port: Shows the host name and domain on which this process runs. For example: isis.example.com Shows the port number over which this process communicates. For example: 3741 Status: Shows OK if this process is running. If the process is not running, an error message opens.
Watchdog Details
Name: Configuration Identifier: Version: Shows the name of this process, which is Watchdog. Shows the configuration identifier for this process. For example: /mcs-1/vwd/vwd-isis.example.com Shows which version of this process is present. For example: 6.0
4-20
August 2001
Delivery Channel Plug-in Details

Name: Shows the name of this process, which depends on the plugin that is installed. For example: Email (SMTP) Configuration Identifier: Host: Port: Shows the configuration identifier for this process. For example: /mcs-1/plugins/plugin-1 Shows the host name and domain on which this process runs. For example: isis.example.com Shows the port number over which this process communicates. For example: 25
August 2001
4-21
4-22
August 2001
5
Summary: Audience:
Managing VCMS Users, Groups, and Roles
You can view and change lists of users, groups, and roles through the Admin Center s User Manager tool. Administrators and other users of the Vignette Content Management Server V6 (VCMS) software See Chapter 1, VCMS Software Basic Concepts
Overview Managing Users for a New Installation Roles Authorization Monitoring Users, Groups, and Roles Managing Users Managing Groups Managing 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.
August 2001
5-1
Overview
Each 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.
5-2
August 2001
The User Manager primary window contains information for these aspects of VCMS, each contained in a page with a tab at the top:
Users Shows information about the currently valid users recognized by the VCMS database. From this tab:

Groups
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.
Shows information about the currently valid groups recognized by the VCMS database. From this tab:

Roles
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.
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.
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.
August 2001
5-3
Managing Users for a New Installation

At 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 selfregistration 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
5-4
August 2001
Roles Authorization
The 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 System Enables the user to 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.
August 2001
5-5
Role Business Center Full
Enables the user to 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.
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

Topics include:
Viewing User Attributes Viewing Group Attributes Viewing Role Attributes
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.
5-6
August 2001
Viewing User Attributes

The columns of the User Manager show the following read-only information about current users:
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. (Optional) The user s full name, or more descriptive information about the user. (Optional) The user s e-mail address. (Optional) The groups of which the user is a member. Groups provide a quick way to assign several users to a project or task without listing each one separately.
Description E-mail Address Groups
Viewing Group Attributes

The columns of the User Manager show the following read-only information about current groups:
Group Name Description The VCMS software establishes and maintains the group name within the database. (Optional) Descriptive information about the group.
August 2001
5-7
Viewing Role Attributes

The columns of the User Manager show the following read-only information about current roles:
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:

Description
Business Center Full Business Center Partial Developer System (Any custom roles added to your installation)
Descriptive information about the role.
Managing Users
Topics include:
Rules for User Entries Adding, Cloning, Editing, or Deleting Users Additional Information Enabling Self-registration Setting E-mail Preferences
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.
5-8
August 2001
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 Description E-mail Address Password Expires 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. A full name or more detail about the user. (Optional) The e-mail address that is used by the CMS for project notifications. (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.
August 2001
5-9
User can modify password Password valid only once Account enabled
(Optional) This option inherits its default setting from the PW_CHANGE_PASSWORD_DEFAULT configuration variable. See the Configuration Reference. (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. (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. 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. Again, only asterisks display in the window.
New password
Confirm password
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.
5-10
August 2001
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.
August 2001
5-11
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.
s 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

Topics include:
Setting the SMTP Server Enabling E-mail Notifications
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.
5-12
August 2001
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.
s To set the SMTP server for a CMS:
1 In the Configuration View primary
window, right-click the Content Management Server entry, and select Details from the menu.
2 Enter the fully qualified domain
The Content Management Server Details window opens.
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 sites SMTP server. For example: pan.example.com Specifies the mail server s port number, usually 25.
name and port number of the SMTP server to use when sending e-mail notification.
port
3 Click OK to submit the change to
the database.
NOTE: There is no native SMTP server in the Windows 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:
For One-time tasks Workflow tasks Recurring tasks (first in the schedule) The appropriate users are notified Immediately after the task is created. When the task rises to the top of the workflow (that is, when it becomes the current task). When the recurring task is created.
August 2001
5-13
For Recurring tasks (subsequent tasks in the schedule) Failed program tasks
The appropriate users are notified When the previous task is completed or when the previous task becomes late, whichever comes first. (Project owners only) When a program task in the project or workflow is unsuccessful.
If a user prefers not to receive e-mail regarding any task, you can delete the 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.
s To enable or disable e-mail notification for a CMS:
1 In the Configuration View primary
window, right-click the Content Management Server entry, and select Details from the pop-up menu.
2 Set E-mail Notifications to On or Off:
The Content Management Server Details window opens.
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.
5-14
August 2001
Managing Groups
Group 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.
Topics include:
Rules for Group Entries Adding, Cloning, Editing, or Deleting Groups Additional Information
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)

Can include upper- and lowercase characters Cannot have spaces (ASCII character code 32) or apostrophes (ASCII
character code 39)

Cannot have more than 64 characters
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.
August 2001
5-15
When adding, cloning, or editing a group, the appropriate dialog opens, containing the following fields:
Group Description The group name. To add a group, follow the guidelines described in Rules for Group Entries on page 5-15. Details about the group.
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 groups information.
5-16
August 2001
Editing a Group Entry
System role users can change a groups description in the Details for Group window, but they cannot alter the Group field. The groups name cannot be changed. (To change the groups name, you must delete the group and re-enter the information.) You can edit only one group entry at a time. 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.
August 2001
5-17
Managing Roles
Managing 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.
Role Description The role name. If youre adding a role, follow the guidelines described in Rules for Role Entries on page 5-19. Detail about the role.
You can add users to the role through the Users tab.
Topics include:
Rules for Role Entries Adding, Cloning, Editing, or Deleting Roles Additional Information
5-18
August 2001
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).
Can include upper- and lowercase characters Must begin with a character or number Cannot have more than 64 characters
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:
Role Description If youre adding a role, follow the guideline described in Rules for Role Entries on page 5-19. Detail about the role.
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.
August 2001
5-19
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 roles name. (To change the roles 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.
5-20
August 2001
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.
August 2001
5-21
5-22
August 2001
6
Summary: Audience:
Managing VCMS Files
How to manage various directories and files that the Vignette Content Management Server V6 (VCMS) software creates when you install and configure your servers. Administrators of VCMS See Chapter 1, VCMS Software Basic Concepts
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
August 2001
6-1
Managing VCMS Files
Overview
When 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.
See also:
Appendix B, VCMS File Reference Appendix A, VCMS Process Reference
Understanding Configuration Files

This 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.
Topics include:
Overview of Configuration Files Initialization Files for the Tcl Interpreter
6-2
August 2001
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.
August 2001
6-3
Managing VCMS Files
The following table shows the VCMS components and their processes, and it shows the configuration file for each component.
VCMS component Configuration Management Server (CMS) Content Delivery Server (CDS) Consists of the following subcomponents and processes Configuration file cms.cfg
bob (Dispatch Service) vhs (Request Service) ted (Event Service) 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 omd (Observation Manager) cld (Campaign Logging Agent) vrd (Router) vwd (OMS Watchdog) mcd (Multi-Channel Delivery Agent) vwd (VMCS Watchdog) Web server module
cds.cfg
Observation Management Server (OMS)
oms.cfg
Multi-Channel Communication Server (VMCS) Web Server module
mcs.cfg
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.
6-4
August 2001
Managing VCMS Files
The following table shows the paths to the configuration files for each component.
Component Configuration Management Server (CMS) Content Delivery Server (CDS) Observation Management Server (OMS) Multi-Channel Server (VMCS) Web Server module Path to configuration files W INDOWS install-path\inst-name\conf\cms\cms.cfg S OLARIS install-path/vignette/inst-name/conf/cms/cms.cfg W INDOWS install-path\inst-name\conf\cds-name\cds.cfg S OLARIS install-path/vignette/inst-name/conf/cds-name/cds.cfg W INDOWS install-path\inst-name\conf\oms-name\oms.cfg S OLARIS install-path/vignette/inst-name/conf/oms-name/oms.cfg W INDOWS install-path\inst-name\conf\mcs-name\mcs.cfg S OLARIS install-path/vignette/inst-name/conf/mcs-name/mcs.cfg W INDOWS install-path\inst-name\conf\ws-name\ws.cfg S OLARIS install-path/vignette/inst-name/conf/ws-name/ws.cfg
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.
August 2001
6-5
Managing VCMS Files
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.
Name delivery.tcl W INDOWS install-path\inst-name\conf\ S OLARIS install-path/vignette/inst-name/conf/ ctld.tcl W INDOWS install-path\inst-name\conf\cds-name\ S OLARIS install-path/vignette/inst-name/conf/cds-name/
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.
6-6
August 2001
Managing VCMS Files
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).
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
Enter a variable of the format: set variable string For example:

set myDino "Brontosaurus dog"
3 4
Save your changes to the file and exit the editor. 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
August 2001
6-7
Managing VCMS Files
log Files and pid Files

The 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 depthhow to set the level of logging, and how to view the logging information.
Topics include:
log and pid File Names and Locations Viewing VCMS Log 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.
6-8
August 2001
Managing VCMS Files
The following table shows the paths to the log and pid files. The files in the table are given relative to the following directories:
W INDOWS install-path\inst-name\logs\ S OLARIS install-path/vignette/inst-name/logs/ path to log on W INDOWS \cms\ path to log or pid on S OLARIS /cms/
Process name
log file
Dispatch Service Request Service Event Service Placement Agent Template Manager Cache Manager Tcl Page Generator ASP Page Generator JSP Page Generator Campaign Logging Agent Observation Manager Router OMS Watchdog Multi-Channel Delivery Agent VMCS Watchdog
bob.log vhs.#.log ted.log pad.#.log tmd-id.log cmd.log ctld-id.#.log asp-id.log jsp-id.log cld-id.log omd-id.log vrd-id.log vwd.log mcd-id.#.log vwd.log
\cds-name\
/cds-name/
\oms-name\
/oms-name/
\mcs-name\
\mcs-name\
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.
August 2001
6-9
Managing VCMS Files
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.
See also: Configuration Reference
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: W INDOWS The EventLog service lists events, errors, and messages. S OLARIS 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.
6-10
August 2001
Managing VCMS Files
The following table shows the VCMS log levels and message distribution.
Written to Log Level 1 2 3 4 Message Type error warning audit debug W INDOWS EventLog service EventLog service process log file process log file S OLARIS messages messages process log file process log file
Topics include:
Viewing the EventLog Event Viewer on Windows Viewing the messages file on Solaris
Viewing the EventLog Event Viewer on Windows

s To view the VCMS errors and messages (levels 1 or 2) on Windows: 1 2 3
Using your preferred method, open the Event Viewer. From the Log menu, select Application. 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.
Close the Event Viewer.
August 2001
6-11
Managing VCMS Files
Viewing the messages file on Solaris

s 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/ Read the contents of the messages file with your preferred text viewer.
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
Debugging Templates with the LOG Template Command

In 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:
W INDOWS install-path\inst-name\logs\cds-name\ctld-id.#.infolog S OLARIS 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:
Tcl: Template Command Reference Tcl: Template Cookbook
6-12
August 2001
Managing VCMS Files
Other Files and Directories

In 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.
Topics include:
Other CMS Files and Directories Other CDS Files and Directories
Other CMS Files and Directories

The CMS files and directories in the table are given relative to the following directories:
W INDOWS install-path\
for example:
D:\Program Files\Vignette\ S OLARIS install-path/vignette/
for example:
/opt/vignette/ File or Directory Name File or Directory Location W INDOWS admin.bat inst-name\conf\cms\ expire.exe 6.0\taskbin\winnt\ flushcache.bat 6.0\taskbin\winnt\ launch.exe 6.0\taskbin\winnt\ S OLARIS admin inst-name/conf/cms/ expire 6.0/taskbin/solaris/ flushcache 6.0/taskbin/solaris/ launch 6.0/taskbin/solaris/ Expires records, files, and templates Flushes cached pages Launches records, files, and templates Stops or starts CMS Function
August 2001
6-13
Managing VCMS Files
File or Directory Name File or Directory Location W INDOWS staticfiles inst-name\working\cms\ S OLARIS staticfiles inst-name/working/cms/
Function
Directory for Request Service working copies of static files it has processed Working directory for Event Service program tasks Versions records, files, and templates
tedtasksworkingdir inst-name\working\cms\ version.exe 6.0\taskbin\winnt\
tedtasksworkingdirs inst-name/working/cms/ version 6.0/taskbin/solaris
Other CDS Files and Directories

The files for a CDS shown below are given relative to the following install path:
W INDOWS install-path\
for example:
D:\Program Files\Vignette\ S OLARIS install-path/vignette/
for example:
/opt/vignette/ File or Directory Name File or Directory Location W INDOWS admin.bat inst-name\conf\cds-name\ S OLARIS admin inst-name/conf/cds-name/ Stops or starts CDS Function
6-14
August 2001
Managing VCMS Files
File or Directory Name File or Directory Location W INDOWS docroot 6.0\ S OLARIS docroot 6.0/
Function
Contains on-line VCMS information (development CDS only) that your web browser can access Contains Tcl template variations
metafiles inst-name\working\ cds-name\ metatemplates inst-name\working\ cds-name\ obj.conf.vgnbak inst-name\working\ ws-name\ iPlanet servers only templates-id inst-name\working\ cds-name\
metafiles inst-name/working/ cds-name/ metatemplates inst-name\working\ cds-name\ obj.conf.vgnbak inst-name/working/ws-name/ iPlanet servers only templates-id inst-name/working/ cds-name/
Contains template meta-data
Backup copy of NSAPI configuration file for iPlanet server
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
August 2001
6-15
Managing VCMS Files
Understanding Tool Directories

The VCMS software creates folders (directories) for its tool files when the tool sets are installed. The following folders are installed in these default locations:
C:\Program Files\Vignette\Tools\bin\ Contains the executable (ss.exe) for the VCMS tools and shortcut for the VCMS launch bar. Contains Java files and directories for the tools, as well as licensing and copyright information. Contains files used by the tool programs.
C:\Program Files\Vignette\Tools\java\
C:\Program Files\Vignette\Tools\lib\
See also:
Appendix B, VCMS File Reference Appendix A, VCMS Process Reference Understanding Preference Files on page 6-16
Understanding Preference Files

Topics include:
The security.cfg File Preferences File
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.
6-16
August 2001
Managing VCMS Files
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.
See also:
security.cfg on page B-39 Tools client security chapter of the Security Guide Configuration Reference
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.
August 2001
6-17
Managing VCMS Files
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
6-18
August 2001
7
Summary; Audience: See also:
Managing System and Content Databases
How to manage the Vignette Content Management Server V6 (VCMS) system database and how to configure separate content databases. Administrators and DBAs for the VCMS software See Chapter 1, VCMS Software Basic Concepts
Overview System Database Requirements Database Access Configuring One or More Content Databases Separate From the System Database Handling Legacy Data Appendix C, System Database Tables Visitor Services Guide Production Center Guide Configuration Reference
August 2001
7-1
Overview
When 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.
7-2
August 2001
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:
VCMS System DB
VCMS Content DB
Visitor DB
System tables require the SYSTEM_DB_* variables for login
Visitor databases Content databases require the require the VISITOR_DB_* CONTENT_DB_* variables for login and PM_CONTENT_DB_* variables for login The template environment uses the TEMPLATE_SYSTEM_DB_* variables for login
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.
August 2001
7-3
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 Requirements

The 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.
Topics include:
Database Permissions Database Size
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.
7-4
August 2001
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
Topics include:
Database Configuration Variables Content Databases of Different Types Configuring a Second Login for the Template Environment Password Encryption Database Access Through Templates
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 CMSs configuration information. If the database access information is for a content database, the VCMS software maintains the information with the CDSs 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.
August 2001
7-5
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:
VCMS process 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) Dispatch Service (bob) Tcl Page Generator (ctld) ASP Page Generator (IIS web server instance) JSP Page Generator The content database tables Must have access to The system database tables
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.
7-6
August 2001
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.
s To enable access to a content database of a different type: 1 2
Log in to the Page Generator s host as the VCMS administrator. For each Page Generator that accesses the content database, modify that Page Generator s configuration information to include the path to the databases 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 doesnt 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.
Stop and restart the CDS processes using the admin command:
cd install-path/vignette/inst-name/conf/cds-name ./admin restart
August 2001
7-7
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.
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
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:
W INDOWS/ S OLARIS/ AIX DB2 W INDOWS Microsoft SQL Server Create two users in the database. Neither user should be the instance owner or have database administrator authority. 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). Set up two users with the same default table space.
W INDOWS /S OLARIS Oracle W INDOWS/ S OLARIS 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).
You must assign both users the permissions described in Database Permissions on page 7-4.
7-8
August 2001
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 databasethat is, if the SYSTEM_DB_* variables for the CMS match the CONTENT_DB_* variables for the CDSthen 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.
W INDOWS install-path\6.0\adm\sql\ S OLARIS install-path/vignette/6.0/adm/sql/
August 2001
7-9
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.
7-10
August 2001
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:
S OLARIS
install-path/vignette/6.0/bin/solaris/
W INDOWS
install-path\6.0\bin\winnt s 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
August 2001
7-11
Substitute the encrypted system database password for the cleartext password in the variables that apply to your configuration.
Variable name SYSTEM_DB_PASSWORD TEMPLATE_SYSTEM_DB_PASSWORD CONTENT_DB_PASSWORD PM_CONTENT_DBn_PASSWORD VISITOR_DB_PASSWORD Configuration file cms.cfg cms.cfg cds.cfg cms.cfg oms.cfg
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 4
If you have changed from a cleartext password to an encrypted one, set the corresponding *_DB_PASSWORD_ENCRYPTED variable to yes. 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.
7-12
August 2001
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
Summary: Topics include: Describes the ways that you can configure one or more content databases separate from the system database.
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
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.
August 2001
7-13
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 CDSs 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 sites 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.
7-14
August 2001
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 cant connect, page generation fails with a processing error.
August 2001
7-15
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 isnt available when the CMS starts, the CMS still starts successfully. It will log an error that it couldnt 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 isnt 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 metadatamanagement informationassociated 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 contentthe 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 metadatathe 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 records modification history and, depending on the records status, may restart its workflow.
7-16
August 2001
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 dont 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 doesnt 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 doesnt 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.
August 2001
7-17
The implications for the ROW* and RECORD commands:

To add and update database content (rows) that doesnt 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 records 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 templates Primary table (in the templates 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 softwares 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.
7-18
August 2001
Table name collisions can occur if your site has multiple content databases, because the next_id table doesnt 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 CDSs 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.
August 2001
7-19
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 dont need the CONNECT command in the Tcl template. VCMS commands that access the database, like SEARCH TABLE or NEEDS, establish the connection themselves.
2 3
Do what you need to while connected to the database (insert rows, select, and so on). 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 [SET [SET [SET [SET USERNAME $CONTENT_DB_USER] PASSWORD $CONTENT_DB_PASSWORD] SERVER $CONTENT_DB_SERVER] DATABASE $CONTENT_DB_DATABASE] 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.
7-20
August 2001
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 DB2 7.1 Operating system Solaris and AIX Windows 2000 and NT Microsoft SQL Server 2000 Oracle 8.1.6 Windows 2000 and NT Solaris Windows 2000 and NT Access library librwdb2_mt.so mddb2dgmt.dll
mdmodbcdmt.dll
librwora816_mt.so mdo816dmt.dll
August 2001
7-21
Database and version Oracle 8.1.7
Operating system Solaris Windows 2000 and NT
Access library
librwora817_mt.so mdo817dmt.dll
librwctlib_mt.so
Sybase 12
Solaris Windows 2000 and NT
mdscdmt.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 dont 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 cant connect and will fail. Follow this sequence with PROFILE_MARK:
1 2 3 4
Save the state of vdbmsg(password_encrypted). Set up variables to access the different database. Reset vdbmsg(password_encrypted) to its original value. Use PROFILE_MARK.
7-22
August 2001
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.
August 2001
7-23
Examples
Example 1 shows Tcl template code that inserts a new row into a content database thats not the default content database (that is, the database defined in the configuration information for the CDS). This example does the following:
1 2 3
Sets the database to the content database xad2 on the database server 3rdbase. Inserts a new row into the content database (ROW_INSERT). 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]} } ]]
7-24
August 2001
[# 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]
August 2001
7-25
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 sites 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 hasnt 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 doesnt 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.
7-26
August 2001
Setting the Variables

s 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.) 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.
August 2001
7-27
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 DB2 Oracle Sybase Microsoft SQL Server JDBC driver com.ibm.db2.jdbc.app.DB2Driver oracle.jdbc.driver.OracleDriver com.sybase.jdbc2.jdbc.SybDriver com.inet.tds.TdsDriver
7-28
August 2001
CONTENT_DB_CONNECTION_URL connection-url where connection-url is the JDBC connection URL. Connection URL formats include:
Database DB2 Oracle Sybase Microsoft SQL Server JDBC connection URL jdbc:db2:hostname:port/dbname jdbc:oracle:thin:@hostname:port:sid jdbc:sybase:Tds:hostname:port/dbname jdbc:inetdae:hostname:port?database=dbname
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 and version DB2 7.1 Operating system Solaris or AIX Windows 2000 and NT Microsoft SQL Server 2000 Windows 2000 and NT Oracle 8.1.6 Solaris Windows 2000 and NT Oracle 8.1.7 Solaris Windows 2000 and NT Access library librwdb2_mt.so mddb2dgmt.dll mdmodbcdmt.dll librwora816_mt.so mdo816dmt.dll librwora817_mt.so mdo817dmt.dll
August 2001
7-29
Database and version Sybase 12
Operating system Solaris Windows 2000 and NT
Access library librwctlib_mt.so mdscdmt.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.so CONTENT_DB_TYPE DB2 CONTENT_DB_SERVER KALLISTO CONTENT_DB_DATABASE "VignContent" CONTENT_DB_SID "" CONTENT_DB_USERNAME arcas1 CONTENT_DB_PASSWORD 413rE99gYY3
For an Oracle database on Solaris:

CONTENT_DB_RWDBLIB CONTENT_DB_TYPE CONTENT_DB_SERVER CONTENT_DB_DATABASE CONTENT_DB_SID CONTENT_DB_USERNAME CONTENT_DB_PASSWORD librwora816_mt.so Oracle MADRONE "" ora8_tcp tst1 2ZZrBYjUfVw1
For a Microsoft SQL Server database:

CONTENT_DB_RWDBLIB CONTENT_DB_TYPE CONTENT_DB_SERVER CONTENT_DB_DATABASE CONTENT_DB_USERNAME CONTENT_DB_PASSWORD
mdmodbcdmt.dll
MSSQLServer SQLSERV "lapaz" amigo migas
7-30
August 2001
For a Sybase database on Windows NT:

CONTENT_DB_RWDBLIB CONTENT_DB_TYPE CONTENT_DB_SERVER CONTENT_DB_DATABASE CONTENT_DB_USERNAME CONTENT_DB_PASSWORD mdscdmt.dll Sybase REDBUD "syb11" syber 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 The total number of content databases in your VCMS system. The remaining variables will appear once for each content database, iterated by numberthe value of n. The content database name. Password required for the Dispatch Service (bob) to access the content database for content versioning information. Whether PM_CONTENT_DBn_PASSWORD is encrypted. The RogueWave library used to access the content database. Variable name PM_CONTENT_DB_NUMBER
PM_CONTENT_DBn_DATABASE PM_CONTENT_DBn_PASSWORD
PM_CONTENT_DBn_PASSWORD_ENCRYPTED PM_CONTENT_DBn_RWDBLIB
August 2001
7-31
Database parameter For Oracle, DB2, and Sybase databases, the database server name for the content database. For Microsoft SQL Server databases, the Data Source Name (DSN). For Microsoft SQL Server databases, the name of the server for the content database. This variable applies to Microsoft SQL Server databases only. The system identifier for the database. This variable applies to Oracle databases only. 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. The type of the content database. Can be DB2, or MSSqlServer, Oracle, or Sybase. The user name used to access the content database.
Variable name PM_CONTENT_DBn_SERVER
PM_CONTENT_DBn_SERVERNAME
PM_CONTENT_DBn_SID PM_CONTENT_DBn_TEXTSIZE
PM_CONTENT_DBn_TYPE PM_CONTENT_DBn_USERNAME
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 2 PM_CONTENT_DB1_TYPE Oracle PM_CONTENT_DB1_SERVER orant_a2 PM_CONTENT_DB1_DATABASE "" PM_CONTENT_DB1_SID ORCL11 PM_CONTENT_DB1_USERNAME loc_user PM_CONTENT_DB1_PASSWORD 2:1eLHcW PM_CONTENT_DB1_PASSWORD_ENCRYPTED yes PM_CONTENT_DB1_RWDBLIB mdor8dmt.dll PM_CONTENT_DB1_TEXTSIZE 1,000,000 PM_CONTENT_DB2_TYPE Oracle PM_CONTENT_DB2_SERVER ora1_tcp PM_CONTENT_DB2_DATABASE "" PM_CONTENT_DB2_SID ora1
7-32
August 2001
PM_CONTENT_DB2_USERNAME bro PM_CONTENT_DB2_PASSWORD 2.:oRzdfSL,44ezA PM_CONTENT_DB2_PASSWORD_ENCRYPTED yes PM_CONTENT_DB2_RWDBLIB mdor8dmt.dll PM_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

Summary: Topics include: Describes to make your legacy data available to the VCMS software.
Using the Legacy Record Templates Modifying the Legacy Save Template for a Nondefault Database Creating the Records Making the Record Content Live
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.
August 2001
7-33
In either case, identify the content database in the templates that generate pages from the rows, if the rows arent 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 CDSs default content database (the one identified by the CDSs 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 youre creating records for rows in the default content database, go directly to the Creating the Records section. If youre 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 CDSs 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.
7-34
August 2001
Modifying the Legacy Save Template for a Nondefault Database

To create management records for rows that are not in the CDSs default content database, you first edit the legacy save template to identify the database where the rows are stored.
s To edit the legacy save template: 1 2 3 4
Start the VCMS Tools. Open the Project Manager, and open the legacy records save template for editing. Its in the System project. Save a version of the template, with the File>Save Version command in the Template Editor. (This step is optional but a good idea.) 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 SET SET SET SET SERVER giant DATABASE sybHR USERNAME sybuserHR vdbmsg(password_encrypted) no PASSWORD hrgrp
Find this line in the template:

[RECORD UPDATE [FIELD [SHOW primaryKey]] [SHOW table] "" "" [SHOW primaryKey] [SHOW userProject] ""]
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] ""]
Below the line you modified, find this line:

[RECORD UPDATE [FIELD [SHOW primaryKey]] [SHOW table] "" "" [SHOW primaryKey] [SHOW userProject] [FIELD [SHOW nameKey]]]
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]]]
August 2001
7-35
Save your changes and close the template.
Now you can create the records, as explained below.
Creating the Records

s To create management records for rows in the CDSs default content database: 1 2
Start the VCMS Tools, if you havent already. 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. Open the Project Manager, if you havent already. If you havent already created a project or projects for the records youre adding, do that now. 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.
3 4 5
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-36
August 2001
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 9
Click Submit. 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.
August 2001
7-37
7-38
August 2001
8
Summary: Audience:
Managing VCMS Processes
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. Administrators of the VCMS software
Before you begin:
See Chapter 1, VCMS Software Basic Concepts See Chapter 4, Viewing VCMS Servers and Processes 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 StatusSolaris Only Checking Page Generator Status Stopping and Starting a CMS from the Start MenuWindows Only Starting and Stopping with the Platform ManagerWindows Only
Topics include:
August 2001
8-1
Overview
This 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 components 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:
admin command-line utility (using admin restart or admin stop and admin start) Start menu option for the CMS component Platform Manager Available on Windows Available on Windows Available on Windows and Solaris
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 components processes. (See admin on page A-5.)
8-2
August 2001
Using the admin Command to Stop and Start Processes

The 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:
W INDOWS install-path\inst-name\conf\admin.bat S OLARIS 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 ManagerWindows Only on page 8-9.
August 2001
8-3
s 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 3
From a command line, navigate to the directory where the admin command is located. 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
8-4
August 2001
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 theyre 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.
s 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.
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.
August 2001
8-5
Enter the following command at the prompt:

admin restart configid
where configid is the configuration ID for the Template Manager.
Refreshing Referenced Configuration Variables

As 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.
8-6
August 2001
Obtaining Process StatusSolaris Only

For 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 cmd cmd [Port:3742] ... Up Since: Tue Aug 14 16:45:31 2001 [Port:3741] ... Up Since: Tue Aug 14 16:45:39 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.
August 2001
8-7
Checking Page Generator Status

You can confirm that the Page Generators youve configured are working properly by browsing to their status pages:
Page Generator ASP JSP Tcl (ctld) Status Page URL http://host:port/vgn/asp/status http://host:port/vgn/jsp/jspstatus http://host:port/vgn/login
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).
s 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 3
Select Start CMS or Stop CMS, depending on the action you want. You can verify in the Services Control Panel (Start -> Settings -> Control Panel -> Services) that the services have stopped or started. The service name shows a blank status field when the service is stopped. For service names, see Appendix A.
8-8
August 2001
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 s To stop or start a component using the Platform Manager: 1 2
Open the Platform Manager. 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. 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.
August 2001
8-9
8-10
August 2001
9
Summary: Audience: Note:
Managing the VCMS Site
Procedures for various management tasks Administrators of the Vignette Content Management Server V6 (VCMS) site See Chapter 1, VCMS Software Basic Concepts
Accessing the Platform ManagerWindows Only Loading or Removing a Project Package Synchronizing a Docroot Gathering Tcl Template Performance Data
For information on removing server software, see the VCMS Installation and Configuration Guide (printed copy shipped with product).
August 2001
9-1
Accessing the Platform ManagerWindows Only

The 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 2
Log in as system admin user on the host where the VCMS is installed. Open the Start menu and select the following options:
Programs ->Vignette Content Management V6 -> Platform Manager
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 View the details and status of the components and their processes See the VCMS Installation and Configuration Guide (printed copy shipped with product). 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.) See Appendix D, Configuring the VCMS Software to Use an LDAP User Repository. See the following section.
Configure an LDAP user repository Load or remove a project package
9-2
August 2001
Loading or Removing a Project Package

The 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: W INDOWS With the Platform Manager. S OLARIS 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.
s To load a Project Package using the Platform Manageron Windows: 1 2
Log in to the appropriate CMS. 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. Select the project package that you want to load from the list, and click Next.
August 2001
9-3
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.
Click Finish. The VCMS software imports the package contents.
s To remove a Project Package using the Platform Manageron 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. Select the project package that you want to remove from the list. 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. Click Finish. The VCMS software removes the selected project.
2 3
s To load a Project Package using the config programon 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 3 4 5 6
Select Configure an existing CMS. Select the CMS you want to load the demonstration package into. Log in to the CMS. You must be a System role user to gain access. The Configure CMS menu opens. Select Add Package. The Project Packages menu opens. Select the project package that you want to load and verify your choice.
9-4
August 2001
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.
Verify that you want to commit the configuration. The VCMS software imports the package contents.
s To remove a Project Package using the config programon Solaris: 1

2 3 4 5 6
Select Configure an existing CMS. Select the CMS you want to remove the demonstration package from. Log in to the CMS. You must be a System role user to gain access. The Configure CMS menu opens. Select Remove Package. The Project Packages menu opens. 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 8
Verify your choice. Verify that you want to commit the configuration. The VCMS software removes the project package.
August 2001
9-5
Synchronizing a Docroot
Use 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.
s To synchronize a docroot using the Platform Manageron Windows: 1 2 3 4
Log in to the appropriate CMS. In the Platform Manager, select the CDS that contains the web server docroot you want to synchronize. Select Configure > CDS > Synchronize docroot. The Vignette(R) Content Management Server V6: Sync the docroot window opens. Click Finish to verify that you want to perform the operation. The VCMS software synchronizes the docroot.
s To synchronize a docroot using the config programon Solaris: 1

2 3 4 5 6 7 8
Select Configure an existing CMS. Select a CMS. Log in to the CMS. You must be a System role user to gain access. The Configure CMS menu opens. Select Configure an existing CDS. Select the CDS that contains the web server docroot you want to synchronize. Select Sync the docroot. Verify that you want to commit the configuration. The VCMS software synchronizes the docroot.
9-6
August 2001
Gathering Tcl Template Performance Data

The 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 Online 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.
August 2001
9-7
9-8
August 2001
10
Summary: Audience:
How to modify certain features of the web server. 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 Mapping the Root Path (/) to a Front Door CURL Working with Web Server Parsing Clearing Pages from a Root Path Using ASP Scripts in TemplatesWindows Only
Topics include:
August 2001
10-1
Mapping the Root Path (/) to a Front Door CURL

Mapping the root documentation path to a particular CURL for your web sites front door 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.
10-2
August 2001
Working with Web Server Parsing

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 IISWindows Only Parsing on Apache (Solaris Only) or IHS (AIX Only)
The VCMS component templates offer a valuable way to increase your web server performance by taking advantage of the VCMS softwares 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: Dont 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.
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
August 2001
10-3
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) wont work.
Disabling Parsing on iPlanet

Topics include:
Disabling interpretation of COMPONENT results Disabling server-side includes on iPlanet
NOTE: Dont 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.
10-4
August 2001
Disabling interpretation of COMPONENT results
NOTE: For IIS web servers, see Parsing on IISWindows Only on page 10-7. To disable your iPlanet web server so that it doesnt 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
s To disable server-side includes (parse-html) completely, edit the iPlanet web servers obj.conf file: 1 2
Log in as a user with system admin user privileges to the host where the web server and CDS that you want to modify are running. Open a command line and navigate to the directory:
W INDOWS ws-install-path\ws-instance\config\ S OLARIS ws-install-path/ws-instance/config/
For example, if you installed the web server in the default location:
W INDOWS cd \Netscape\Server\https-myhost\config S OLARIS 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
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
August 2001
10-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 7
Save the changes to the web server s obj.conf file. From the iPlanet Web Server Administration Server interface, apply the changes with the Apply and Load Configuration Files commands. To make the web server use the new values, stop and restart the web server.
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.
s To optimize parse-html on iPlanet: 1 2
Use the iPlanet Web Server Administration Server to change the Parse HTML setting to the desired type of file (files with the extension .shtml). 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 4
Save the changes to the web server s obj.conf file. From the iPlanet Web Server Administration Server interface, apply the changes with the Apply and Load Configuration Files commands. Stop and restart your web server. Change the default extension for templates containing COMPONENT commands to .shtml so the web server will parse them.
5 6
10-6
August 2001
Parsing on IISWindows 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.
s To control parsing with the IIS web servers: 1 2
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. Open the Microsoft Management Console (this may be referred to as Internet Service Manager in your menu), right-click on your web server instance and select Properties. With WWW Service selected, click the Edit button. Select the Home Directory tab. In the Permissions section, select the Script option if it isnt already selected. This option allows scripts to be run on the web server. Select Configuration. A list of Application Mappings is displayed. To enable ssinc.dll for .html and .htm, add two lines to the properties that look similar to this, depending on your configuration:
.htm .html C:\WINNT\System32\inetsrv\ssinc.dll C:\WINNT\System32\inetsrv\ssinc.dll
3 4 5 6 7
This change is necessary in order for templates to process form posts. Without the change, you will receive an HTTP error 405.
8 9 10 11
Make sure that no exclusions exist for either .htm or .html file types. Click OK in the Configuration window, then Apply in the Microsoft Management Console. Repeat these steps for each web server instance on this host for which you will configure a CDS. In Windows Explorer, select the web server s docroot entry and open its Properties window.
August 2001
10-7
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 b
Confirm that the user name Type of access is set to Change (which provides read, write, delete, and execute permissions). Select both the Replace Permissions on Subdirectories and Replace Permissions on Existing Files option fields, if theyre not already selected.
13 14
Click OK in the Directory Permissions window and OK in the Properties window. Stop and restart your web server. NOTE: The IIS web server also supports server-side-include parsing for HTTP GETs. If you still want to be able to scan particular pages, create 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).
10-8
August 2001
Clearing Pages from a Root Path

After you make changes to a set of content that appears in cached pages, you can use the flushcache command to flush previously generated pages from a CDSs 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 isnt generated for some reason. To have flushcache remove cached pages from the cache, change the value to DELETE. For more information on changing values of configuration variables, see the Configuration Reference.
s 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 its not already selected. The text field becomes available. In the Program task text field, type flushcache and the options you want. The format is:
flushcache -h host -p port [-H proxy_host] [-P proxy port] -h host -p port path ...
Specifies the host where the web server whose document root you want to clear is running. Specifies the Cache Manager s port number on the CDS associated with the web server document root.
August 2001
10-9
-H proxy_host
Optional. If your CDS is outside the firewall and youre using a proxy server to regulate outbound connections to it, specify the name of the proxy server. Optional. If your CDS is outside the firewall and youre using a proxy server to regulate outbound connections to it, specify the port number used for communications with the Cache Manager. Specifies one or more directories relative to the document root containing the pages you want to clear.
-P proxy port
path
NOTE: If you are using a proxy server, you cannot use secure authenticated or encrypted connections. For example, to clear pages from the directory:
W INDOWS \OurSite\Books S OLARIS /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:
W INDOWS flushcache farley 13625 \OurSite\Books S OLARIS flushcache farley 13625 /OurSite/Books
To flush multiple paths with one command:

W INDOWS flushcache farley 13625 \OurSite\Books \OurSite\Magazines S OLARIS 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. Its also prudent to stagger flushes of different areas or caches to avoid severe competition for system resources.
When you have completed any other changes to the Details window, click OK. The flushcache command runs when you specified in the program task.
10-10
August 2001
Using ASP Scripts in TemplatesWindows Only

Make 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).
August 2001
10-11
10-12
August 2001
11
Summary: Audience:
Variable settings that you can modify to increase performance or adjust for different content or products. 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 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
Topics include:
August 2001
11-1
Overview
To 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) Requests

You 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.
11-2
August 2001
Adjusting Page Generator Timeouts

Topics include:
Setting Page Generation Timeouts Using the RESET_TIMEOUT Template Command
Setting a time limit for page generation prevents a template with a programming error, such as an infinite loop, from tying up a CDSs 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 its 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 modules 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.
August 2001
11-3
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. Its especially useful in library templates. For example, you know a library subroutine takes 10 seconds, but you dont know the other time requirements of the templates that may include the library template. Using [RESET_TIMEOUT +10] in the library template will add enough time for the library subroutine evaluation in whatever template includes it. The maximum value allowed for n with either form is 2147483647 (the standard Tcl limit).
11-4
August 2001
Some suggestions for using RESET_TIMEOUT:

Keep in mind that RESET_TIMEOUT must be evaluated before the current
timeout expires.
Place RESET_TIMEOUT near the beginning of the template. You dont have to reset the timeout back to the default: the value is changed
only in the context of the 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 Retrievals

You 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.
August 2001
11-5
Increasing Request Handling

The request handling service allows a specified number of requests for template operations or static file (re)submissions to be made at a time. You can increase this number by modifying the 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 timeconsuming 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 Manager

If 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.
11-6
August 2001
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 2 3
/news/local /news/local /news/local/images
Then separate threads can simultaneously service the requests to flush paths 1 and 3, but the second request to flush /news/local must wait until the first request to flush that path completes. If the Page Generator receives 10 requests to flush a single path, only one thread will run at a time, even if 10 threads are available.
August 2001
11-7
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.
11-8
August 2001
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.
August 2001
11-9
Restricting Access to the Servers

By 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.
11-10
August 2001
Enabling VCMS Status Notification

You 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.
HOST PORT TO The outgoing e-mail host. For example, mailhost.company.com. The outgoing e-mail port. The default value is 25. 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. 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. Specifies the level of status for which notification e-mail is sent. Possible values include:
FROM
NOTIFY_LEVEL
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.
To learn more about the configuration variables discussed in this section and how to edit them, see the Configuration Reference.
August 2001
11-11
11-12
August 2001
12
Summary: Audience: See also:
How to transfer projects and database tables from one Content Management Server (CMS) to another. Administrators of the Vignette Content Management Server V6 (VCMS) software See Chapter 7, Managing System and Content Databases
Overview Requirements, Assumptions, and Restrictions How to Transfer Projects transferproject Syntax Transferring Projects Things to Do after Transferring What Is Transferred and What Isnt General Information about Transferring Projects transferproject on page A-40
August 2001
12-1
Overview
If your company has multiple VCMS CMSs, you may need at times to transfercopya 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 projectincluding 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.
12-2
August 2001
Requirements, Assumptions, and Restrictions

Some 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 VCMSs 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.
August 2001
12-3
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 projectsespecially large onesat off-peak times.
transferproject doesnt 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 Isnt 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 doesnt 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.
12-4
August 2001
How to Transfer Projects

Topics include:
Exporting and Importing Projects Typical Transfers VCMS Project Data and Database Content Project Package
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:
export export (-r|-R) exportData import importData Exports project data Exports project data and any database content referenced by records Exports all database content for the project Imports project data Imports database content
NOTE: You will have to use both import and importData to unpack a single project package created with export -r. Some characteristics of project transfer:
When you import a project, it is immediately available on the CMS. If you
are connected to the CMS, 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.
August 2001
12-5
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 projects
content management ID. The package created includes that project and all its subprojects, if any, and all their subprojects, and so on. When you import a project, you specify the management ID of an existing project on the destination CMS. That project will be the parent project of the imported project. 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 CMSs project hierarchy and imported into different parts of the destination CMSs project hierarchy.
12-6
August 2001
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 source CMS
project package
to destination CMS
August 2001
12-7
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 source CMS
project package
to destination CMS
12-8
August 2001
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 didnt transfer to the destination project.
Figure 12-3: Project contents
project on source CMS
project package project on destination CMS
August 2001
12-9
Typical Transfers
There are three basic situations for project transfer:
Youre adding a project to a destination CMS, and the project doesnt
already exist on that CMS. For example, you may have added a CMS in another area and want to transfer certain projects to it.
Youre replacing a project on the destination CMS with some variation of
the same project. For example, you may have redesigned the projects templates on a CMS reserved for development work and now want to update the original project.
You want to add the contents of a project to another project on a different
CMS. You can 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. Heres a typical sequence for transferring a project. It assumes that youre importing a project thats new to the destination CMS, not updating an existing project or adding contents to an existing project.
s 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. Using transferprojects 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 Isnt 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.
Using transferprojects exportData operation, export the database content for the project from the source CMS.
12-10
August 2001
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 dont want the transferred content items to go Live immediately. See transferproject on page A-40. Import the database content to the destination CMS using transferprojects importData operation. The import operation exits if it finds a conflict between the source database content and the destination database (such as duplicate table names). Resolve the conflict and 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.
5 6
Import the VCMS project data to the destination CMS using transferprojects import operation. You specify the parent project for the transferred project. If the import operation finds conflicts between the source and destination projects (such as duplicate template names or file path names), it lists the conflicts and exits, unless you use the -z option to specify how to handle object conflicts. If you do not use -z, you will want to resolve any conflicts and run the command again. See transferproject on page A-40. 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.
August 2001
12-11
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, theres no need to transfer the tables. If the content database isnt accessible to the destination CMS, you can transfer the database content with transferprojector with a database tool, such as Sybases bcp. Or suppose a project contains templates that reference content (for example, with the SEARCH command), but you havent created any records for the content. (A database row requires a record only if you want to manage its productionworkflow, launch schedule, and so onusing the VCMS Production Center.) In that case, theres 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 projectto have sample content available as you develop templates, for example. NOTE: If a transferred template lists a primary table in its Details window, the destination CMS creates an entry for that table (if one doesnt already exist) in the next_id table in its 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 projects 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, its preferable to import a projects database content before its VCMS project data, so the content will be available when templates are accessed.
12-12
August 2001
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 transferprojects 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.data vignxfer.purge vignxfer.sch.db2 vignxfer.sch.mss vignxfer.sch.ora vignxfer.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. transferprojects deleteData operation processes the SQL to delete the tables from the destination database.
Each of the remaining files (*.sch.*) is a schema file specific to the
Sybase, Microsoft SQL Server, DB2, or Oracle database type. These files contain SQL statements for creating the tables the project needs in the destination database.
August 2001
12-13
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 Syntax
The transferproject command resides in the VCMS operating-system directory below the bin directory. The default locations:
S OLARIS
install-path/vignette/6.0/bin/solaris/
W INDOWS
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] [-?]
12-14
August 2001
You specify the operation that transferproject performsexport the VCMS project data, export the database content, import the VCMS project data, and so onwith 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 -?
August 2001
12-15
Transferring Projects
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
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.
12-16
August 2001
Setting Environment Variables on Solaris

On Solaris, the transferproject utility requires that some environment variables be set if youre exporting, importing, or deleting database content:
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 transferprojects -b option (the source CMS with the exportData operation and the destination CMS with the importData and deleteData operations). The variable must be valid on the machine where transferproject is run. Set the variable to the path of the database client installation, as explained in the database client documentation. If the database variable isnt 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 isnt 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 ...
August 2001
12-17
Import Conflicts
Before importing a project, transferprojects import operation checks for conflicts between the project data and the VCMS data for the destination CMSs projects. By default, if it finds conflicts, it reports them and exits. You can adjust this behavior by using the -z option with the transferproject command. See transferproject on page A-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 youre importing contains a template named Catalog Insert. If a template with that name already exists on the destination CMS, the transfer wont work. transferproject will report that a template of the same name already exists. transferproject -o import checks for all conflicts 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.
12-18
August 2001
transferproject treats project names differently from template names, template paths, template IDs, file path names, and record definitions. The VCMS software doesnt permit two subprojects of the same parent project to have the same name, but transferproject will import a project that has the same name as a subproject of the destination parent project. However, instead of creating a separate project, transferproject adds the contents of the transferred project to the existing project on the destination system. The constraints for template names, template paths, 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 projects VCMS project data, you must know the VCMS management ID of the project to export. When you import a projects project data, you need the ID of the project to put the new project under. To delete a project, you also need its ID.
s To find project IDs: 1 2
From the VCMS Tools launch bar, open the Production Center s Project Manager. Check the projects management ID in either of these ways:
Select the project, open its Details window, and go to the Misc tab.
Youll see this line: Management ID: /pr/number.

Select the projects parent project in the Projects pane. The management
ID of the project youre looking for is probably listed in the Contents pane. If it isnt, select the Set Visible Columns button and add Mgmt ID to the list of columns selected for display. The button looks like this:
August 2001
12-19
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 projects 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 its 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
12-20
August 2001
As a last example, the following command uses the -t option to export a subset of contentin 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 projects project data and its database content, you can specify the -r option or the -R option when you run transferprojects 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 projects 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.
August 2001
12-21
To import the project at the destination system, you use both the import operation and the importData operation, just as you would if you had exported the 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 projects data and its database content:
transferproject -o export -r -b sable:37500:/pr/22 -p /prog/prtransfer -l Admin:Bnutmeg31
If transferproject cant find the row data corresponding to a content item record, a message reports an error querying the record data and identifies the database and record ID. This message also appears:
Error getting object record: No such row
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.
12-22
August 2001
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

s 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 arent transferred. Depending on how the automatic launch attribute is set in the parent project, templates, records, and files will be Live or Ready To Launch immediately after the project is imported (except for internal use only templates, which always transfer as Ready For Internal Use). See Parent Project and Status of Imported Content Items on page 12-39. NOTE: To keep imported content items from launching immediately, make sure the automatic launch attribute is not selected in the parent projects 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.
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.
August 2001
12-23
If the project package isnt accessible to the machine where it will be imported, move the project package to an accessible location. See Moving a Project Package on page 12-31. 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 youre importing. See transferproject on page A-40 for other argument descriptions. As transferproject imports the project package, it reports that its transferring project, template, record, and file information and creating the file distribution for the project. When the transfer completes, the transferred project will be available through the Production Center. The database rows corresponding to the project records wont be available unless theyve already been imported from a project package with the importData operation. NOTE: The management ID of the Base Project is always /pr/a. Specify /pr/a as the project ID if you want the imported package to be immediately below the Base Project in the project hierarchy. 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 importthis 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.
12-24
August 2001
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. If the project package isnt accessible to the machine where it will be imported, move the project package to an accessible location. See Moving a Project Package on page 12-31. 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 its processing the schema file. See Using the k Option on page 12-27. For other argument descriptions, see transferproject on page A-40.
August 2001
12-25
If any table with the same name as one of the imported tables already exists in the destination database (and you havent specified the -k option), transferproject reports the error and exits after the first error. For other errors that prevent the import operation from completing, see Schema Restrictions on page 12-28. The following example imports the project package thats 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. 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.
12-26
August 2001
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 cant create a table because the table already exists in the destination database, importData will continue, even though the table creation failed. Similarly, the deleteData operation executes SQL statements from the purge file in the project package and exits by default if an error occurs. The -k option forces deleteData to continue even if a processing error occurs. Some examples of using -k:
After exporting the content data, you manually dropped one of the tables
listed in the project packages purge file. With -k, deleteData deletes the remaining tables, even though it couldnt delete the one you dropped.
Youre importing three tables, and one of them already exists in the
destination VCMS system database. With -k, importData creates the other two tables, even though it couldnt create the third.
Youre importing a table with 50 rows, and the same table exists in the
destination 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 couldnt create the table and even though the other 40 attempts to insert a row failed. Keep in mind that sequence affects what actually happens if a processing error occurs and you havent specified -k. Take the middle example aboveyoure importing three tables, and one of them already exists in the destination VCMS system database. If the existing table is the last one specified in the project package schema file, then the processing error doesnt occur until after the importData operation has created the two other tables. If the 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.
August 2001
12-27
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.
12-28
August 2001
Deleting Project Data

You delete a projects data with transferprojects delete operation. The project data includes all the projects contents and the subprojects under it in the project hierarchy. When you delete projects, be sure youre deleting at the right level of the project hierarchy. Remember that the delete operation will delete not only the specified project, but all its subprojects, their subprojects, and so on down the hierarchy. Before deleting a project, be sure that its all right to delete its contents and the contents of all its subprojects. Check for new templates, records, or files that VCMS users may have added. To delete a projects 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 cant delete the Base Project, /pr/a. If you try to delete it, transferproject displays a message that deleting the Base Project isnt allowed.
August 2001
12-29
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 whats in them. To see what tables deleteData will drop, check the package-directoryname.purge file in the project package. (See Contents of Project Package on page 12-41.) Before executing deleteData, make sure that the tables can be dropped. Back them up if necessary. To delete a projects 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.
12-30
August 2001
The third command imports the database content from the project package created by the first command. The tables are imported to CMS host ducat at port 66650.
transferproject -o exportData -b samson:78900 -p /baker/systems/xfer -t "PartNo Catalog" -l H98_ay4Np:jQ18p transferproject -o deleteData -b ducat:66650 -p /baker/systems/xfer -l janeR:snowstorm transferproject -o importData -b ducat:66650 -p /baker/systems/xfer -l janeR:snowstorm
NOTE: The deleteData step above is optional.
Moving a Project Package

After you create a project package with transferprojects -o export operation or -o exportData operation, move it if the project package directory isnt accessible to the destination CMS. NOTE: transferproject requires that the project package directory name and the base name of the project package files be the same.
s 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).
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.
August 2001
12-31
Things to Do after Transferring

Some 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.
12-32
August 2001
What Is Transferred and What Isnt

The tables that follow show which project, template, record, and file properties are transferred to the destination project. The tables also show how the properties that arent transferred are handled. The following table shows which project properties transferproject transfers.
Project property parent project name attributes (final review by owner, automatic launch, automatic versioning on launch) project owners authorized users default template paths default workflows Transferred? no yes no Inherited from destination parent project Inherited from destination parent project Inherited from destination parent project Inherited or replaced? Replaced with destination parent project
no no yes no
Inherited from destination parent project See Parent Project and Status of Imported Content Items on page 12-39.
management ID history keywords
no no yes/no
Inherited from destination parent project 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.
August 2001
12-33
Project property versions
Transferred? no
Inherited or replaced? No See transferproject on page A-40 for information about the -n option.
notes tasks subprojects templates files records rows (database content)
no no yes yes yes yes yes (with export -r, export -R, or exportData)
No No
NOTE: transferproject exports the current copy (last saved copy) of records, files, and templates. The following table shows which template properties transferproject transfers.
Template property name cache setting body internal-use-only setting paths primary table file extension category Transferred? yes yes yes yes yes yes yes yes Inherited or replaced?
12-34
August 2001
Template property template ID
Transferred? no
Inherited or replaced? Replaced with new one (unless the -i option is specified with the import operation.) See Using the i Option on page 12-26. Replaced with new one No See Parent Project and Status of Imported Content Items on page 12-39. See Using the s and e Options to alter content status and workflow on page 12-40.
management ID workflow
no no
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.
See Parent Project and Status of Imported Content Items on page 12-39. 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 versions no no No No See transferproject on page A-40 for information about the -n option.
August 2001
12-35
Template property keywords
Transferred? yes
Inherited or replaced? Category:keyword information is maintained in transferred templates and the Keyword Manager for the destination CMS is updated with any new information. No
notes
no
The following table shows which record properties transferproject transfers.

Record property name table name database information (server, database name, primary key name) database management ID workflow Transferred? yes yes no Replaced with destination server s database information Replaced with new one Replaced with new one No See Parent Project and Status of Imported Content Items on page 12-39. See Using the s and e Options to alter content status and workflow on page 12-40. status yes/no If was Live, becomes Live (unless you use the -s or -e option). See Parent Project and Status of Imported Content Items on page 12-39. See Using the s and e Options to alter content status and workflow on page 12-40. history no No Inherited or replaced?
no no no
12-36
August 2001
Record property versions
Transferred? no
Inherited or replaced? No See transferproject on page A-40 for information about the -n option.
keywords
yes
Category:keyword information is maintained in transferred records, and the Keyword Manager for the destination CMS is updated with any new information. No
notes
no
The following table shows which file properties transferproject transfers.

File Property name content path management ID workflow Transferred? yes yes yes no no Replaced with new one No See Parent Project and Status of Imported Content Items on page 12-39. See Using the s and e Options to alter content status and workflow on page 12-40. status yes/no If was Live, becomes Live (unless you use the -s or -e option. See Parent Project and Status of Imported Content Items on page 12-39. See Using the s and e Options to alter content status and workflow on page 12-40. history no No Inherited or Replaced?
August 2001
12-37
File Property versions
Transferred? no
Inherited or Replaced? No See transferproject on page A-40 for information about the -n option.
notes
no
No
General Information about Transferring Projects

Topics covered:
VCMS Authorizations Parent Project and Status of Imported Content Items Contents of Project Package
VCMS Authorizations
The following table shows the required VCMS authorizations for transferproject operations. Members of the System role are authorized for all operations.
Operation delete VCMS authorization needed Owner of destination projects parent project, and authorized to delete the templates, records, and files in the project (content owner, owner of project to be deleted, or member of the System role) Any VCMS user of the destination CMS Any VCMS user of the source CMS Any VCMS user of the source CMS Owner of the parent project on the destination CMS Any VCMS user of the destination CMS
deleteData export exportData import importData
NOTE: For database interactions, transferproject assumes the database permissions of the VCMS database user.
12-38
August 2001
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 doesnt 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:
Content item Record, file, or launchable template Status before export (on source CMS) Live Status after import (on destination CMS) Live (unless you use the -s option, in which case Live becomes Ready to Launch) 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 targetCMS and the templates are different, the template goes to Working status. Record, file, or launchable template Internal use only template Ready To Launch, Awaiting Final Review, or Working Ready for Internal Use, Awaiting Final Review, or Working Ready To Launch
Ready For Internal Use
As the table shows, the status of all imported records, files, and templates (except for internal use only templates) will be either Live or Ready To Launch. If the parent project of the imported project is set to launch content automatically, then all that content will immediately become Live, unless the -s option is used in which case all Live content becomes Ready to Launch.
August 2001
12-39
Its advisable to set up a safe parent project when you first begin working with transferproject: a project that isnt set to launch content automatically. The autolaunch attribute is set on the General page of the projects 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.
12-40
August 2001
Contents of Project Package

With an export option, transferproject creates a project package that contains several files with different extensions: package-directory-name.attr package-directory-name.file-format package-directory-name.data package-directory-name.purge package-directory-name.sch.syb package-directory-name.sch.mss package-directory-name.sch.ora package-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 .attr Operation export Description 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 .zip .data export export exportData export -r export Contains a tar distribution package of the files added to the project as content items. On Solaris, this is the default format. Contains a zip distribution package of the files added to the project as content items. On Windows, this is the default format. Contains formatted data for the tables identified with exportData or export -r.
August 2001
12-41
Extension .purge
Operation exportData export -r export exportData export -r export exportData export -r export exportData export -r export exportData export -r export
Description Contains information for removing the tables specified with exportData or export -r. Empty if export is specified without -r. Contains create table functions in MS SQLServer format for installing the tables specified with exportData. Empty if export is specified without -r. Contains create table functions in Oracle format for installing the tables specified with exportData. Empty if export is specified without -r. Contains create table functions in Sybase format for installing the tables specified with exportData. Empty if export is specified without -r. Contains create table functions in DB2 format for installing the tables specified with exportData. Empty if export is specified without -r.
.sch.mss
.sch.ora
.sch.syb
.sch.db2
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 files path. After running tar or zip to complete the project package, the export operation removes the dist directory. Similarly, the import operation recreates the file paths under a dist directory and removes the dist directory when it completes. If the export or import operation is interrupted before it completes, it may not remove the dist directory. If that happens, just remove the directory yourself with the method appropriate for your operating system.
12-42
August 2001
A
Summary: Audience:
VCMS Process Reference
A quick reference for processes followed by detailed information for each. Administrators and other users of the Vignette Content Management Server V6 (VCMS) software See Chapter 8, Managing VCMS Processes
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
A-1
Process Reference Overview

This 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 admin admin (CDS) admin (CMS) admin (VMCS) admin (OMS) admin cfgedit Command-line utility Sets and changes configuration variables. See also the Configuration Reference. Changes the log level setting for components and their processes. Refreshes configuration file variable values with values from the system database Dispatch Service Used with the Vignette Relationship Management Server (VRMS). Checks for broken campaigns. See also the Business Center Guide. Type Command-line utility Command-line utility Description Stops, starts, or checks status for all VCMS components on the local host Stops, starts, or checks status for the CDS, CMS, VMCS, or OMS processes. See also admin cfgedit and admin refreshfromdb.
admin chlog admin refreshfromdb
Command-line utility Command-line utility
bob campadmin
CMS process Program task
A-2
August 2001
Process cgutil
Type Command-line utility
Description Used with the Vignette Relationship Management Server (VRMS). Imports content groups. See also the Business Center Guide. Campaign Logging Agent Cache Manager Configures VCMS components Tcl Page Generator Creates encrypted strings Expires records, files, or templates Clears cached pages from a specified location Generates keys and certificate requests. See also the Security Guide. Converts e-mail data into multi-part form data and issues a post to a URL Launches records, files, and templates Multi-Channel Delivery Agent Observation Manager Placement Agent Removes visitor information from the visitor records database. Clears the user and group cache of the EUR (external user repository). Used with the Vignette Relationship Management Server (VRMS). Retrieves segments and their populations from a netCustomer web server. See the Business Center Guide. Event Service
cld cm W INDOWS cmd S OLARIS config ctld encrypt expire flushcache gencert inboundmail launch mcd omd pad pzndelete reseteur sgutil
OMS process CDS process Interactive program CDS process Command-line utility Program task Program task Command-line utility Program task Program task VMCS process OMS process CDS process Program task Program task Program task
ted
CMS process
August 2001
A-3
Process tmd transferproject version vhs vrd vwd wscfg AIX
Type CDS process Command-line utility Program task CMS process OMS process OMS and VMCS process Command-line utility
Description Template Manager Transfers project info from one CMS to another Creates, names, restores, or deletes versions of files, records, or templates Request Service Router Watchdog Associates or disassociates a web server on a dissimilar host with a CDS on a standard host in a heterogeneous configuration.
NOTE: For information on file location variables, see Common Path Name Variables on page 1-5.
A-4
August 2001
admin
Stops, 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.
August 2001
A-5
status S OLARIS 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.
A-6
August 2001
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 S OLARIS 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.
August 2001
A-7
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.
A-8
August 2001
status S OLARIS 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.
August 2001
A-9
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 S OLARIS 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]
A-10
August 2001
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 S OLARIS Returns status on all processes of the OMS. stop Stops all OMS processes.
August 2001
A-11
admin cfgedit
Allows 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.
A-12
August 2001
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
August 2001
A-13
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.
Written to Log level 1 2 3 4 Message type error warning audit debug W INDOWS EventLog service Eventlog service process log file process log file S OLARIS messages messages process log file process log file
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.
A-14
August 2001
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 webserver 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 components 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 components 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.
August 2001
A-15
admin refreshfromdb
The 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
A-16
August 2001

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.
August 2001
A-17
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.
bob
Dispatches 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.
A-18
August 2001
campadmin
A 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.
cgutil
The 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 commands syntax and sample input.
August 2001
A-19
cld
A 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.
A-20
August 2001
config
Configures 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.
ctld
The 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)
August 2001
A-21
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 cds.cfg file maintains configuration information for this process. See cds.cfg on page B-10. The delivery.tcl and ctld.tcl files initialize the template interpreter. See Initialization Files for the Tcl Interpreter on page 6-5.
encrypt
A 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.
A-22
August 2001
expire
A 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.
August 2001
A-23
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:
W INDOWS install-path\inst-name\conf\adminutil\adminutil.cfg S OLARIS 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.
A-24
August 2001
flushcache
A 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.
August 2001
A-25
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 youre 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 youre 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
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.
A-26
August 2001
gencert
A 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.
August 2001
A-27
Options
Option -a alias Function 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) -e Optional. Specifies the number of bits in the generated key. If the argument is not specified, it defaults to 512. 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. Optional. Reads the contents of filename into the prompts for the certificates 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
-f filename
A-28
August 2001
Option -s
Function 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.
inboundmail
A 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]
August 2001
A-29
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.
A-30
August 2001
-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.
Example
inboundmail -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
August 2001
A-31
launch
A 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.
A-32
August 2001
Options
-r Recursively launches all records, files, and templates that are available to be launched through all subprojects and at the top project level. project_mgmt_id | ci_mgmt_id The management ID for the project or content. You can find this ID in the Management ID field of the Misc 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 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:
W INDOWS install-path\inst-name\conf\adminutil\adminutil.cfg S OLARIS 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. For a full description of the adminutil.cfg file, see the Security Guide.
Example
Almost all the options of the launch command are handled by selections in the Task Manager or Project Manager. In this example, you specify individual subprojects (project_mgmt_id) and templates, records, or files (ci_mgmt_ids) in a program task for a project-level launch, where you can also set a Repeat command:
launch /pr/106 /ci/21d /ci/404g /ci/783f
NOTE: The forward slash (/) is part of the ID, not a path, and should be used whether specifying the task for a Windows or Solaris-based engine.
August 2001
A-33
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.
mcd
The 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.
omd
The Observation Manager (omd) is an OMS process that manages visitor records and visitor context objects. The oms.cfg file maintains configuration information for this process. See oms.cfg on page B-36.
pad
The CDS process that deploys static content when needed for web page generation.

Vignette 6.0 Placement Agent (inst-name cds-name dm)
A-34
August 2001
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. The cds.cfg file maintains configuration information for this process. See cds.cfg on page B-10.
pzndelete
Use the pzndelete executable to help manage the Vignette Relationship Management Servers 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 its specified with -v or -m.)
Syntax
pzndelete [-e] [-l length-in-days -v | -m]
August 2001
A-35
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 havent visited your site for the number of days specified in length-in-days. For example, this command removes all information about visitors who havent 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 havent 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
A-36
August 2001
If a visitor whose profile marker information has been deleted (but whose registration information wasnt 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.
reseteur
A 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]
August 2001
A-37
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-torole 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. -w adminutil.cfg-path 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. For a full description of the adminutil.cfg file, see the Security Guide.
A-38
August 2001
sgutil
A 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.
ted
A 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. The cms.cfg file maintains configuration information for this process. See cms.cfg on page B-16.
August 2001
A-39
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. The cds.cfg file maintains configuration information for this process. See cds.cfg on page B-10.
transferproject
An 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 copya 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.
A-40
August 2001
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 0 1 2 3 4 5 6 7 8 9 10 11 Status Success Fatal error Conflicts found (import with the -z 4 option) Error retrieving SQL schema information for table Error occurred while writing SQL file Error occurred while writing the purge file Error retrieving record data Error requesting visual template file contents Error occurred while opening a file in the distribution directory Error requesting file contents Error occurred while writing a file in the distribution directory Error occurred while creating the distribution directory
August 2001
A-41
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 projects database type.
A-42
August 2001
-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.
August 2001
A-43
-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.
A-44
August 2001
-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
August 2001
A-45
-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 items 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.
A-46
August 2001
-t content item-list or list file Optional with the export operation. Allows users to transfer a subset of a projects 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 CMSs 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.
August 2001
A-47
-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. -w adminutil.cfg-path 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. For a full description of the adminutil.cfg file, see the Security Guide. -z option Optional with import. Specifies how to handle object conflicts on import:
-z 0 Dont transfer any objects if there is a single conflict (default
behavior).
-z 1 Dont transfer any objects which conflict, but transfer the rest of
the objects in the project package.

-z 2 Replace conflicting target objects with source object data. -z 3 Like -z 2, but version conflicting target objects before updating.
See -n "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.
A-48
August 2001
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 projects 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.
August 2001
A-49
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.
A-50
August 2001
-r Optional. Recursively performs a version operation on 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. 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 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:
W INDOWS install-path\inst-name\conf\adminutil\adminutil.cfg S OLARIS 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. For a full description of the adminutil.cfg file, see the Security Guide.
Defaults
The VCMS software provides some defaults when you invoke a version program task.
August 2001
A-51
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 youre 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 youre currently connected The authorization that your current login has been given The -o saveExisting option, which creates a version for those
content items in the project which have been versioned previously

The current project ID
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
A-52
August 2001
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
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 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
August 2001
A-53
vhs
A 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 processesfor 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. The cms.cfg file maintains configuration information for this process. See cms.cfg on page B-16.
vrd
The 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). The oms.cfg file maintains configuration information for this process. See oms.cfg on page B-36.
A-54
August 2001
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.
wscfg
Associates 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.
August 2001
A-55
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 sites 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. .
A-56
August 2001
B
Summary: Audience:
VCMS File Reference

A reference for Vignette Content Management Server V6 (VCMS) files and directories. Administrators and other users of the VCMS software Chapter 6, Managing VCMS Files
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
B-1
VCMS File Reference
File Reference Overview

This 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 adminutil.cfg asp-id.log bob.log bob.pid S OLARIS cds.cfg cfgpassword.log cld-id.log cld-id.pid S OLARIS cld-id-timestamp.log Type Configuration file Log file Log file Process ID file Configuration file Log file Log file Process ID file Log file Description Configuration information for the VCMS utilities and program tasks One log file for each ASP Page Generator Log file for the bob (Dispatch Service) process The process identification number for the bob (Dispatch Service) process Configuration information for the Content Delivery Server (CDS) and its processes Log file for errors encountered retrieving or storing passwords for the configuration files One log file for each cld (Campaign Logging Agent) process The process identification number for each cld (Campaign Logging Agent) process Log file passed to the netCustomer Analysis Engine by the cld (Campaign Logging Agent) process on the OMS Log file for the cmd (Cache Manager) process The process identification number for the cmd (Cache Manager) process Configuration information for the Content Management Server (CMS) and its processes Configuration information used by VCMS APIs for connecting to secure processes Log file containing errors generated while configuring the VCMS software Log file for the LOG template command
cmd.log cmd.pid S OLARIS cms.cfg cmscppapi.cfg config.log ctld-id.#.infolog
Log file Process ID file Configuration file Configuration file Log file Log file
B-2
August 2001
VCMS File Reference
File or directory name ctld-id.#.log ctld-id.pid S OLARIS ctld.tcl delivery.tcl docroot host.cfg insts.cfg
Type Log file Process ID file Configuration file Configuration file Directory Configuration file Internal file
Description One log file for each ctld (Tcl Page Generator) process The process identification number for each ctld (Tcl Page Generator) master process Local initialization information for the ctld (Tcl Page Generator) process Global initialization information for the ctld (Tcl Page Generator) process On-line VCMS information that your web browser can access Contains the configuration information for the local host Contains information about each VCMS component and process installed on the local host For each VCMS component, lists the subcomponents configured on the local host One delivery log for each mcd process One log file for each mcd (Multi-Channel Delivery Agent) process The process identification number for each mcd (Multi-Channel Delivery Agent) master process Configuration information for the Vignette Multi-Channel Communication Server V6 (VMCS) and its processes Log file of errors for the VCMS Binary versions of the browser capabilities of corresponding templates Holds template meta-data A backup copy of the NSAPI configuration file for an iPlanet web server One log file for each omd (Observation Manager) process
manifest mcd-id.deliver.log mcd-id.#.log mcd-id.pid S OLARIS mcs.cfg
Configuration file Log file Log file Process ID file Configuration file
messages S OLARIS metafiles metatemplates-id obj.conf.vgnbak omd-id.log
Log file Directory Directory Configuration file Log file
August 2001
B-3
VCMS File Reference
File or directory name omd-id.pid S OLARIS oms.cfg
Type Process ID file Configuration file
Description The process identification number for each omd (Observation Manager) process Configuration information for the OMS (Observation Management Server) and its processes Log file for the pad (Placement Agent) process The process identification number for the pad (Placement Agent) master process Preferences for the browser to use for previewing templates, and for viewing on-line documentation Security configuration information for the VCMS user tools
pad.#.log pad.pid S OLARIS Preferences
Log file Process ID file Configuration file (Present only if you install the VCMS Tools) Configuration file (Present only if you install theVCMS Tools) Directory Log file Process ID file Directory Directory Log file Process ID file Log file Configuration file (Present only if you install the Vignette Development Center)
security.cfg
staticfiles ted.log ted.pid S OLARIS tedtasksworkingdir templates-id tmd-id.log tmd-id.pid S OLARIS upgrade.log UsrMacroData.xml
Working copies of the static files that the vhs (Request Service) has processed Log file for the ted (Event Service) process The process identification number for the ted (Event Service) process Timed-event process working files Template cache written by tmd and read by ctld One log file for each tmd (Template Manager) process The process identification number for each tmd (Template Manager) process Log file of errors generated while upgrading the VCMS Custom macros created by users of the Macro Editor within the Vignette Development Center
B-4
August 2001
VCMS File Reference
File or directory name vhs.#.log vhs.pid S OLARIS vrd-id.log vrd-id.pid S OLARIS vwd.log vwd.pid ws.cfg
Type Log file Process ID file Log file Process ID file Log file Process ID file Configuration file
Description Log file for the vhs (Request Service) process The process identification number for the vhs (Request Service) master process Log file for the vrd (Router) process The process identification number for each vrd (Router) process Log file for the vwd (Watchdog) process The process identification number for the vwd (Watchdog) process Configuration information for the web server module
August 2001
B-5
VCMS File Reference
adminutil.cfg
The 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.
B-6
August 2001
VCMS File Reference
asp-id.log
Each 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.
August 2001
B-7
VCMS File Reference
bob.log
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. 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.
B-8
August 2001
VCMS File Reference
bob.pid
Solaris 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.
August 2001
B-9
VCMS File Reference
cds.cfg
The configuration file for the CDS and its subcomponents and processes, including:
Docroot Manager (dm)

Cache Manager (cmd) Placement Agent (pad) Template Manager (tmd) Tcl Page Generator (ctld) ASP Page Generator (IIS web server instance)
Application Engine (ape)

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.
B-10
August 2001
VCMS File Reference
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.log
Logs 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.
August 2001
B-11
VCMS File Reference
cld- id.log
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. 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.
B-12
August 2001
VCMS File Reference
cld- id.pid
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. For more information, see log Files and pid Files on page 6-8.
August 2001
B-13
VCMS File Reference
cld- id-timestamp.log
A 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: YYYYMMDDHHMMSS. See the netCustomer appendix in the Business Center Guide for more information.
B-14
August 2001
VCMS File Reference
cmd.log
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. For more information, see log Files and pid Files on page 6-8.
August 2001
B-15
VCMS File Reference
cmd.pid
Solaris 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.cfg
The 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
B-16
August 2001
VCMS File Reference
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. 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 bob on page A-18, ted on page A-39, and vhs on page A-54. For more information, see Overview of Configuration Files on page 6-3.
cmscppapi.cfg
A 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
August 2001
B-17
VCMS File Reference
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. 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.
config.log
Logs 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.
B-18
August 2001
VCMS File Reference
ctld-id.#.infolog
Output 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.
August 2001
B-19
VCMS File Reference
ctld-id.#.log
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. 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.
B-20
August 2001
VCMS File Reference
ctld-id.pid
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. For more information, see log Files and pid Files on page 6-8.
ctld.tcl
A 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
August 2001
B-21
VCMS File Reference
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.tcl
Contains 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.
B-22
August 2001
VCMS File Reference
docroot
Contains 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.cfg
Contains configuration information for the local host.
Location
Windows
install-path\inst-name\conf\host.cfg
Solaris
install-path/vignette/inst-name/conf/host.cfg
August 2001
B-23
VCMS File Reference
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.cfg
An 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.
B-24
August 2001
VCMS File Reference
jsp-id.log
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. 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.
August 2001
B-25
VCMS File Reference
jsp-id.pid
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. For more information, see log Files and pid Files on page 6-8.
B-26
August 2001
VCMS File Reference
manifest
A manifest file exists for the CDS, OMS, and MCS components. It lists the subcomponents that are configured on the local host.
Location
Component CDS Path to manifest file W INDOWS install-path\inst-name\conf\cds-name\manifest S OLARIS install-path/vignette/inst-name/conf/cds-name/manifest OMS W INDOWS install-path\inst-name\conf\oms-name\manifest S OLARIS install-path/vignette/inst-name/conf/oms-name/manifest MCS W INDOWS install-path\inst-name\conf\mcs-name\manifest S OLARIS install-path/vignette/inst-name/conf/mcs-name/manifest
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.
August 2001
B-27
VCMS File Reference
mcd-id.deliver.log
This 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.
B-28
August 2001
VCMS File Reference
mcd-id.#.log
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/ 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.
August 2001
B-29
VCMS File Reference
mcd-id.pid
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. For more information, see log Files and pid Files on page 6-8.
mcs.cfg
The 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
B-30
August 2001
VCMS File Reference
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. 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. For more information, see Overview of Configuration Files on page 6-3. See mcd on page A-34, vrd on page A-54, and vwd on page A-55.
messages
Solaris 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.
August 2001
B-31
VCMS File Reference
metafiles
A 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. For information on file location variables, see Common Path Name Variables on page 1-5.
metatemplates-id
A 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/
B-32
August 2001
VCMS File Reference
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.vgnbak
A 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
August 2001
B-33
VCMS File Reference
Description
The obj.conf.vgnbak file provides a backup copy of obj.conf in order to preserve web server mappings before making VCMS modifications. For information on file location variables, see Common Path Name Variables on page 1-5. The file is a copy of the:
W INDOWS ws-install-path\ws-instance\config\obj.conf S OLARIS 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.log
Location
Windows
install-path\inst-name\logs\oms-name\omd-id.log
Solaris
install-path/vignette/inst-name/logs/oms-name/omd-id.log
B-34
August 2001
VCMS File Reference
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. 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.
omd-id.pid
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. For more information, see log Files and pid Files on page 6-8.
August 2001
B-35
VCMS File Reference
oms.cfg
The 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. 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. For more information, see Overview of Configuration Files on page 6-3. See vrd on page A-54, omd on page A-34, cld on page A-20, and vwd on page A-55.
B-36
August 2001
VCMS File Reference
pad.#.log
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. 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.
August 2001
B-37
VCMS File Reference
pad.pid
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.
Preferences
Contains preferences for the browser to use for previewing templates and viewing on-line documentation, the web server to use for previewing, and the windows that remained open at the last closing of a 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.
B-38
August 2001
VCMS File Reference
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.cfg
The 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.
August 2001
B-39
VCMS File Reference
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.
staticfiles
Contains 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 doesnt reside in the database) via the Submit File option of the Project Manager File command, the VCMS software creates the file in the CMSs 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.
B-40
August 2001
VCMS File Reference
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 CDSs web server to the docroot of another development CDSs web server to avoid exposing files in progress on a live CDS. For information on file location variables, see Common Path Name Variables on page 1-5. See also vhs on page A-54.
ted.log
Location
Windows
install-path\inst-name\logs\cms\ted.log
Solaris
install-path/vignette/inst-name/logs/cms/ted.log
August 2001
B-41
VCMS File Reference
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. The level of logging is set in the LOG_LEVEL configuration variable. See the Configuration Reference for more information about the LOG_LEVEL variable.
ted.pid
Solaris 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.
B-42
August 2001
VCMS File Reference
tedtasksworkingdir
Contains 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. For information on file location variables, see Common Path Name Variables on page 1-5.
templates-id
Template 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/
August 2001
B-43
VCMS File Reference
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. For information on file location variables, see Common Path Name Variables on page 1-5.
tmd-id.log
Location
Windows
install-path\inst-name\logs\cds-name\tmd-id.log
Solaris
install-path/vignette/inst-name/logs/cds-name/tmd-id.log
B-44
August 2001
VCMS File Reference
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. 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.
tmd-id.pid
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. For more information, see log Files and pid Files on page 6-8.
August 2001
B-45
VCMS File Reference
upgrade.log
Logs 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.xml
Contains 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.
B-46
August 2001
VCMS File Reference
vhs.#.log
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. 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.
August 2001
B-47
VCMS File Reference
vhs.pid
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.log
Location
Windows
install-path\inst-name\logs\oms-name\vrd-id.log
Solaris
install-path/vignette/inst-name/logs/oms-name/vrd-id.log
B-48
August 2001
VCMS File Reference
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. 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.
vrd- id.pid
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. For more information, see log Files and pid Files on page 6-8.
August 2001
B-49
VCMS File Reference
vwd.log
Each 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. 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.
B-50
August 2001
VCMS File Reference
vwd.pid
Solaris 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.
August 2001
B-51
VCMS File Reference
ws.cfg
The 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. 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. For more information, see Overview of Configuration Files on page 6-3.
B-52
August 2001
VCMS File Reference
ws.log
The 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. For more information, see log Files and pid Files on page 6-8.
ws.pid
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.
August 2001
B-53
VCMS File Reference
B-54
August 2001
C
Summary: Audience:
System Database Tables
A list of the Vignette Content Management Server V6 (VCMS) system database tables with short descriptions of each. Administrators and DBAs for the VCMS VCMS System Database Tables
Topics include:
August 2001
C-1
VCMS System Database Tables

The 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 next_id Description Tracks next identifier to use in a given VCMS database table when asked for one, for example, by the GET_NEXT_ID command Stores all templates Version information for the templates. This table is created dynamically when the first template version is created. Stores template paths Version information for the template paths. This table is created dynamically when the first template version is created. Stores all content groups for the Vignette Relationship Management Server V6 (VRMS) product. See the Business Center Guide. Associates manual content groups with content items for the Vignette Relationship Management Server. See the Business Center Guide. Specifies dll or shared libraries used by implied content groups. The cgutil program task configures the table. See the Business Center Guide. Stores all available content types for the Vignette Relationship Management Server. The cgutil program task configures the table. See the Business Center Guide. Stores an entry for each Business Center role user. See the Business Center Guide.
template template_v template_path template_path_v vgn_ag
vgn_ag_membership
vgn_asset_group_impl
vgn_asset_type
vgn_bz
C-2
August 2001
Table Name vgn_campaign_metric_map vgn_cc vgn_cf vgn_cfgdef vgn_cfgnode vgn_cfgrel vgn_cfgspc vgn_cfgval vgn_cfgvar vgn_channels
Description Associates Vignette Relationship Management Server campaigns with registered metrics. See the Business Center Guide. Stores personalization content catalog information Contains VCMS configuration information The vgn_cfg* tables manage the configuration path hierarchy.
Contains all available delivery channels for the Vignette Relationship Management Server. See the Business Center Guide. Contains production management information for templates, files, content records 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. 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_ci vgn_cld_files
vgn_context_default
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. Holds internal information about CMS classes and objects
vgn_dbconfig
August 2001
C-3
Table Name vgn_disabled vgn_failed_file_operations vgn_features vgn_feedback
Description A table of disabled users. See the User Security chapter of the Security Guide. Contains a list of any failed file operations attempted by the pad (Placement Agent), with the operation name and a datestamp. Contains the list of browser features Contains metric counts for Vignette Relationship Management Server campaigns. Information includes rule ID, trigger ID, and metric ID. See the Business Center Guide. Stores VCMS groups Associates users with groups Contains history for the content items. See the Production Center Guide. Stores personalization keyword registry information Contains a list of registered metrics for Vignette Relationship Management Server campaigns. Information includes metric ID and a counter. See the Business Center Guide. Stores user password history. Contains persistent lock information for CMS objects Contains project management information Stores VCMS roles Associates users with roles Associates rules with events. See the Business Center Guide. 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. Provides a temporary working area for the CMS Contains a list of available visitor segments. Information includes segment ID, name, description, and visitor count. See the Business Center Guide.
vgn_groups vgn_groupassoc vgn_history vgn_kr vgn_metrics
vgn_password_history vgn_plock vgn_pr vgn_roles vgn_roleassoc vgn_rule_trigger_map vgn_rules
vgn_scratch vgn_sg
C-4
August 2001
Table Name vgn_sg_map_1
Description Associates visitors with visitor segments. See the Business Center Guide. When this table is in use, data is loaded into 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. Location information for visitor segments imported from the netCustomer web server. See the Business Center Guide. 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. Contains a list of all available campaign styles, by ID and name. See the Business Center Guide. Contains a list of all files submitted to the file system through the CMS. Information includes path, live/dev status, and submit date. Associates campaign events with tasks. See the Business Center Guide. Contains task management information 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. Stores personalization profile-marker-by-user information Stores personalization user registry information Stores VCMS users Maps templates to sets of browser features Stores information on versions of templates, files, and records Stores labels associated with versions of templates, files, and records
vgn_sg_map_2
vgn_sg_map_info vgn_style_templates
vgn_styles vgn_submitted_files vgn_task_trigger_map vgn_tk vgn_triggers
vgn_uc vgn_ur vgn_users vgn_variations_map vgn_version vgn_version_tag
August 2001
C-5
Table Name vgn_xmlattrs vgn_xmlbcodes vgn_xmlcolls vgn_xmldocs vgn_xmlids vgn_xmlnames vgn_xmltags vgn_xmltexts
Description The vgn_xml* tables are for XML persistent storage.
See also:
Database Access on page 7-5
C-6
August 2001
D
Summary: Audience:
Configuring the VCMS Software to Use an LDAP User Repository
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. VCMS and LDAP administrators who want to use LDAP to manage VCMS users, roles, and groups For information about VCMS roles, see:
Before you begin:
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
D-1
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
August 2001
Overview
If 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. To find what version of the LDAP server the VCMS software supports, see the Vignette Content Management Server V6 Release Notes.
Supported LDAP server.
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.
August 2001
D-3
Table D-1: Steps
Roadmap for configuration See
Pre-configuration
1 Understand how the VCMS software integrates with
LDAP.
2 Determine whether you want to make a secure or non-
Understanding How the VCMS Software Integrates with LDAP on page D-5
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 Making LDAP Schema and Database Changes on page D-17 Making Configuration Changes on page D-20
4 Make required schema and database changes to
LDAP.
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.
6 Understand LDAP and internationalization. 7 Make sure the LDAP server is running and accessible
LDAP and Internationalization on page D-21
to the VCMS software. Configuration

8 Understand the flow of steps required to configure the
VCMS software to use LDAP.

9 Configure the VCMS software to use LDAP using
Configuring the VCMS Software to Use LDAP on page D-22
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
D-4
August 2001
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 LDAPs 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:
Task Add, modify, and remove users 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. 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 users information (including role and group association) is refreshed. The most idiosyncratic case is when a new LDAP group wont be available until a member of that group logs in (causing the groups cache to update). Tool LDAP clienta
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.
August 2001
D-5
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 its 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)
VCMS Tools
Client certificate Secure pipe
Server certificate CMS
CMS EUR (external user repository)
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)
D-6
August 2001
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:
Connection type Non-secure. This is the default. Secure without client authentication (no client certificate is required on the CMS). Secure with client authentication (a client certificate is required on the CMS). See Making a Non-secure Connection to LDAP on page D-7 Making a Secure Connection to LDAP without Client Authentication on page D-9 Making a Secure Connection to LDAP with Client Authentication on page D-10
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 2
Decrypts the encrypted user-level passwords it receives from the VCMS Tools, transforming them to clear text Sends the clear-text passwords to LDAP This connection is truly not secure!
August 2001
D-7
Figure D-2 shows a non-secure connection:

Figure D-2: Non-secure connection with LDAP
VCMS Tools Client certificate
LDAP User repository
Secure pipe (SSL)
Non-secure pipe
Server certificate
CMS
The VCMS software compares repositories and logs discrepancies
D-8
August 2001
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
VCMS Tools Client certificate Secure pipe (SSL) Server and client certificate CMS
LDAP User repository Server certificate Secure pipe (SSL) The VCMS software compares repositories and logs discrepancies
August 2001
D-9
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
VCMS Tools Client certificate Secure pipe (SSL)
LDAP User repository Server certificate Secure pipe (SSL) Client certificate Server certificate CMS The VCMS software compares repositories and logs discrepancies
D-10
August 2001
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 Non-secure connection
1 Configure the VCMS software with a
See
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
Configuring the VCMS Software to Use LDAP on page D-22
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.

3 Choose a secure connection when prompted
Setting up LDAP SSL Certificates and Keys on page D-12 Configuring the VCMS Software to Use LDAP on page D-22
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.
2 Set up LDAP SSL certificates and keys.
Setting up LDAP SSL Certificates and Keys on page D-12
August 2001
D-11
Steps
3 Choose a secure connection when prompted
See Configuring the VCMS Software to Use LDAP on page D-22

4 Specify SSL certificate information when
prompted through the configuration tool.

5 Choose client authentication when prompted

6 Specify client authentication information.
Setting up LDAP SSL Certificates and Keys

Summary: If you choose to have a secure connection between LDAP and the VCMS software, youll 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
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.
D-12
August 2001
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.
See also: Getting a Certificate on page D-14, for one way to obtain a certificate
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.
Accept and install the certificates through Netscape Communicator 4.x.

See also: Accepting a Certificate on page D-16 and Installing a Certificate on page D-16
You should also be aware of the following security issues:

Issue Anonymous access Description 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. Its 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. Configuring SSL client authentication is difficult. Aside from using Netscape Communicator to load up the cert7.db and key3.db files, you have to:
Client authentication
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 wont 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.
August 2001
D-13
Issue Certificate and key file formats used by Netscape LDAP servers
Description Netscape LDAP servers dont 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.
Getting a Certificate
You dont 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.
s To obtain a server or client certificate: 1 2
Open Netscape Communicator (version 4.x). In the Netscape Navigation Toolbar, click the Security button.
D-14
August 2001
Figure D-5:
Security Info
In the Security Info page, select Certificates -> Yours. The Your Certificates page is displayed. Click Get a Certificate.
Once you have obtained a certificate, you must accept and install it. See the next section, Accepting a Certificate.
August 2001
D-15
Accepting a Certificate
s To accept the certificate and install it in the Netscape database: 1 2
Open Netscape Communicator (version 4.x). 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
s To install a certificate: 1 2
Shut down Netscape Communicator. Copy the cert7.db and key3.db files from the Netscape Communicator directory into a location convenient for LDAP configuration. 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).
D-16
August 2001
Making LDAP Schema and Database Changes

Before 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).
Make this new objectClass (VgnUser) a subclass of your main person objectClass; for example, VgnUser inherits from Person (or organizationalPerson). Export all users who are VCMS users and add them back in to LDAP with the VgnUser objectClass. Configure LDAP to look for users with the VgnUser objectClass.
3 4
August 2001
D-17
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
objectClass = person name = Ella Fitzgerald roles = developer, system ...
See also:
Roles Authorization on page 5-5
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: Managing Users for a New Installation on page 5-4
D-18
August 2001
Figure D-7:
Minimum required user in LDAP
objectClass = person name =admin roles=system ...
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 cant 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 groups name attribute The user s login attribute
August 2001
D-19
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.
See also: Configuration Reference for information about editing configuration variables
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.
CONNECT_RETRIES (entry of EUR_CONFIGURATION).
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.
D-20
August 2001
See also:
Configuration Reference, for more information about these configuration variables.
LDAP and Internationalization

LDAP 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.
August 2001
D-21
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 LDAP

No matter which configuration tool you chooseLDAP 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.
D-22
August 2001
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 connection with LDAP
secure
STEP 3: Specify SSL certificate information
non-secure
no client authentication
STEP 6: Provide LDAP access information 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 configured to use LDAP Differences log file generated
STEP 4: Choose client authentication or not client authentication STEP 5: Supply client authentication information
Success
Fix differences
August 2001
D-23
If you choose not to use a secure connection between the VCMS software and LDAP, youll 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: versa. Also, switch from a secure connection without client authentication to one with client authentication, and vice versa.
Switch from a non-secure connection to a secure connection, and vice
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.
D-24
August 2001
Using LDAP Configuration (for Windows Users)

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: Topics include: See Configuring the VCMS Software to Use LDAP on page D-22, for a flow chart of the configuration steps
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
Overview
Through the LDAP Configuration, you:
Set up the connectionnon-secure or securebetween 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.
August 2001
D-25
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 2
A connection can be established with LDAP (SSL or non-SSL). 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). At least one user matches the specified search criteria. 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 dont have to be any groups.
3 4
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.
s 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)
D-26
August 2001
As shown in Figure D-9, select Configure an existing Content Management Server and click OK.
Configure an existing Content Management Server
Figure D-9:
3 4 5
Log in to the CMS using the admin user s name and password. The VCMS Manager is started. From the Tools menu, choose Configure for LDAP User Repository. 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
August 2001
D-27
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.
s 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.
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.
s To specify SSL certificate information: 1 2
In the SSL Certificate Information window, specify the LDAP certificate file location in the Certificate DB Location field. Click Next to proceed to Step 4: Choosing Client Authentication on page D-29.
D-28
August 2001
Step 4: Choosing Client Authentication

s 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.
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.
s To specify client authentication information: 1
In the window shown in Figure D-10, specify the client authentication information as follows:
a b c
In the Client Key DB Location field: Type the path and file name of the key filein this case: d:\key3.db. In the Client Key DB Password field: Type the password for the database key file. In the Client Certificate Alias/Nickname field: Type the nickname for the client certificate.
Click Next to proceed to Step 7: Setting up the LDAP Server on page D-33.
August 2001
D-29
Figure D-10:
SSL Client Authentication Information
D-30
August 2001
Step 6: Setting up LDAP Access Information

This step prompts you for LDAP access information.
s 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.
August 2001
D-31
Figure D-11:
LDAP Access
D-32
August 2001
Step 7: Setting up the LDAP Server

This step prompts you for LDAP server information.
s 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 infinitethe 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 youll look at when searching for user information.
s 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, its
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
August 2001
D-33
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.
s 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.
D-34
August 2001
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 youll look at when searching for group information.
s 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)
(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 doesnt have to exist.
2
Click Next to proceed to Step 11: Setting up Group Attributes on page D-36.
August 2001
D-35
Step 11: Setting up Group Attributes

This step prompts you for group attribute information.
s 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.
s To perform repository verification: 1 2
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. 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.
D-36
August 2001
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.)
August 2001
D-37
Figure D-12:
Repository Verification
D-38
August 2001
Using the config Command (for Windows and Solaris Users)

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. See Configuring the VCMS Software to Use LDAP on page D-22, for a flow chart of the configuration steps
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
Overview
The config command sets up the following:
The connectionnon-secure or securebetween the VCMS software and
LDAP. If you choose a secure connection, you can choose a clientauthenticated 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.
August 2001
D-39
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 2
A connection can be established with LDAP (SSL or non-SSL). 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). At least one user matches the specified search criteria. 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 dont have to be any groups.
3 4
The following sections step you through setting up the information required for LDAP migration.
D-40
August 2001
Step 1: Starting the LDAP Configuration

NOTE: This example configures a Netscape LDAP server.
s To start config: 1
Run the config command from install-path/adm.

See also: VCMS Installation and Configuration Guide (printed copy shipped with product)
Type 3 to choose to Configure an existing Content Management Server (CMS), as shown in Figure D-13:
Configure an existing Content Management Server (CMS)
Figure D-13:
Type 1 to Select a CMS, as shown in Figure D-14:

Select a CMS
Figure D-14:
4 5
Log in to the CMS using the admin user s name and password. Once logged in, type 9 to Configure for LDAP User Repository.
August 2001
D-41
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.
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 and LDAP

In this step, you choose to have a non-secure or a secure connection between LDAP and the VCMS software.
s 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.
Press Enter.
If you chose to use SSL, proceed to Step 3: Specifying SSL Certificate

If you connect without SSL, proceed to Step 6: Setting up LDAP Access
D-42
August 2001
Figure D-15:
Use of SSL
Step 3: Specifying SSL Certificate Information

This step prompts you for SSL certificate information.
s 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. Press Enter to proceed to Step 4: Choosing Client Authentication on page D-44.
August 2001
D-43
Step 4: Choosing Client Authentication

s 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
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.
s To specify client authentication information: 1
On the screen shown in Figure D-16, specify the client authentication information as follows:
a b c
In the Client Key DB Location field: Type the path and file name of the key filein this case: d:\key3.db. In the Client Key DB Password field: Type the password for the database key file. In the Client Certificate Alias/Nickname field: Type the nickname for the client certificate.
D-44
August 2001
Press Enter to proceed to Step 7: Setting up the LDAP Server on page D-47.
SSL Client Authentication Information
Figure D-16:
August 2001
D-45
Step 6: Setting up LDAP Access Information

This step prompts you for LDAP access information.
s 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.
D-46
August 2001
Step 7: Setting up the LDAP Server

This step prompts you for LDAP server information.
s 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 infinitethe 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 youll look at when searching for user information.
s 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, its
ssuser.
(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
August 2001
D-47
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). 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.
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.
s 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.
D-48
August 2001
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 youll look at when searching for group information.
s 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, its groupofuniquenames.

(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: 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 doesnt have to exist.
2
Press Enter to proceed to Step 11: Setting up Group Attributes on page D-50.
August 2001
D-49
Step 11: Setting up Group Attributes

This step prompts you for group attribute information.
s 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.
s 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, its d:\ldapeur. 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.
D-50
August 2001
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
August 2001
D-51
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: versa. Also, switch from a secure connection without client authentication to one with client authentication, and vice versa.
Switch from a non-secure connection to a secure connection, and vice
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.
D-52
August 2001
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
August 2001
D-53
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:
D-54
August 2001
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
August 2001
D-55
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.
D-56
August 2001
E
Summary: Audience:
Remote Operations
Configuring systems with firewalls or proxy servers. Administrators of the Vignette Content Management Server V6 (VCMS) software Chapter 9, Managing the VCMS Site
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
E-1
Remote Operations
Overview
This 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 CDSs 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
August 2001
Remote Operations
Enabling Communication between VCMS Components

In 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.
August 2001
E-3
Remote Operations
Key 1
Component or subcomponent connection Web Server to CDS
Process connections required
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 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) tmd (Template Manager) to cmd (Cache Manager) 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 ctld (Tcl Page Generator) to Content Database ASP Page Generator to Content Database JSP Page Generator to Content Database ctld (Tcl Page Generator) to Visitor Database
Application Engine to CMS (if using CMS Tcl Commands)
3 4
Application Engine to Docroot Manager Application Engine to System Database
Application Engine to Content Database
Application Engine to Visitor Database
E-4
August 2001
Remote Operations
Key 7 8
Component or subcomponent connection Web Server to OMS Application Engine to MCS (if using MCS commands) Docroot Manager to Web Server (IIS Web Servers only) Application Engine to OMS
Process connections required
Web Server to vrd (Router) via front door host/port ctld (Tcl Page Generator) to mcd (Multi-Channel Delivery Agent) front door host/port cmd (Cache Manager) to Web Server 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 mcd (Multi-Channel Delivery Agent) to ctld (Tcl Page Generator) front door host/port mcd (Multi-Channel Delivery Agent) to vrd (Router) front door host/port omd (Observation Manager) to Visitor Database omd (Observation Manager) to System Database cld (Campaign Logging Agent) to System Database vhs (Request Service) to tmd (Template Manager) vhs (Request Service) to pad (Placement Agent) bob (Dispatch Service) to System Database vhs (Request Service) to System Database
9 10
11
MCS to Application Engine (if association is configured) MCS to OMS
12
13 14
OMS to Visitor Database OMS to System Database
15
CMS to CDS
16
CMS to System Database
August 2001
E-5
Remote Operations
Figure E-1:
Ports required for component connections
CMS
15
16 14 System DB
Content DB
2 Visitor DB 6 1 Application Engine 3 13 10 OMS 8 12 11 MCS 7 CDS Docroot Manager
Web Server
E-6
August 2001
Remote Operations
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 1 Tools to component connection VCMS tools (Production Center, Development Center, Business Center, and Admin Center) to the CMS Admin Center to CDS (for status information) Process connections required
Tools to bob (Dispatch Service) Tools to vhs (Request Service)
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) Admin Center to vrd (Router) Admin Center to omd (Observation Manager) Admin Center to cld (Campaign Logging Agent) Admin Center to vwd (Watchdog) Admin Center to mcd (MultiChannel Delivery Agent) Admin Center to vwd (Watchdog)
Admin Center to OMS (for status information)
Admin Center to MCS (for status information)
August 2001
E-7
Remote Operations
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
VCMS Tools
1 2 CMS CDS Application Engine Docroot Manager
4 MCS
OMS
E-8
August 2001
Remote Operations
CDS File System Access

The CDSs 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
Application Engine /docroot Web Server /metafiles cache Docroot Manager
August 2001
E-9
Remote Operations
Working with IP Aliases

If 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 2
Log in to the host where the Web Server resides. 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
Edit the Web Server s configuration file. To do so, enter:

admin cfgedit ws.cfg
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. 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.
E-10
August 2001
Remote Operations
Outbound Connections through HTTP Proxy

You 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 CMSs vhs process requires two ports to connect to a CDSs 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.
s 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 hosts 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.
Stop and restart the CMS to read the new information.
August 2001
E-11
Remote Operations
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 SOCKS

The 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.
E-12
August 2001
Remote Operations
Specifying the SOCKS Server Using Command-line Options

s To specify the SOCKS proxy server using command-line options: 1 2 3
Open a DOS shell. If necessary, change to the drive on which the VCMS tool software is installed. 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
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
s To specify the SOCKS proxy server by changing the Platform Tools shortcut button: 1 2
On the Windows desktop, right click the Platform Tools shortcut icon and select Properties. The Platform Tools Properties window opens. 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"
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.
August 2001
E-13
Remote Operations
E-14
August 2001
F
Summary: Audience:
Configuring Virtual Hosting
How to set up virtual hosting for the web servers you use with the Vignette Content Management Server V6 (VCMS) Content Delivery Servers (CDSs). Administrators of the VCMS software
Before you begin:
Chapter 9, Managing the VCMS Site Chapter 10, Working with Web Servers Overview Configuring Web Servers Testing the Virtual Servers Virtual Server Front Doors Virtual Hosting and Development
Topics include:
NOTE: Please be aware that your license may not permit you to do virtual hosting for third parties. Please consult your license paperwork.
August 2001
F-1
Overview
When 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 for Domain1
Requests for Domain2
http: / / www.domain1.com IP 207.8.8.22 Web Server
http: / / www.domain 2.com IP 2 207.8.8.23
... /docroot
... /docroot /domain1
... /docroot /domain 2
F-2
August 2001
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.
s 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). 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 4
Configure the web server to map IP addresses or hostnames to individual document directories within a common document root directory. When working with templates, include the unique path that differentiates the virtual server as a prefix on templates and files you want associated with that server. 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.
August 2001
F-3
Configuring Web Servers

Topics include:
iPlanet Web Servers Microsoft IIS Web Servers Apache Web Servers (Solaris Only) and IHS Web Servers (AIX Only)
s 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). 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: W INDOWS 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
S OLARIS /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.
F-4
August 2001
iPlanet Web Servers

s 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.
Make the following changes from within the iPlanet Web Server Administration Server interface, and save and apply your changes:
What Set bind-to address. How Select web server, select Server Preferences then Network Settings, enter your main IP address in the Bind To Address field. Select Content Management for the web server. Ensure the docroot path of the main webserver is entered into the primary directory path. For example: W INDOWS C:\docroot S OLARIS /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 servers document directory associated with the IP address. For example: W INDOWS C:\docroot\domain1 S OLARIS /AIX /docroot/domain1 Repeat this step for each virtual server you wish to set up.
Set the Primary Document Directory.
August 2001
F-5
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 2 3 4
Creating a Web Server Instance for Each Virtual Host Domain Associating the Primary Web Server Instance with the CDS Obtaining the Web Server Instance ID Updating the Registry
F-6
August 2001
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:
What IP address Home directory Value A unique IP address for this virtual domains web server instance. The complete path for the virtual server's document directorythe 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 1s path might be C:\docroot\domain1. Scripting permissions, to handle server-side includes required by the VCMS software.
Permissions
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).
August 2001
F-7
Obtaining the Web Server Instance ID
Youll 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 -------1 2 3 4 5 Name ---Default Web Site Administration Web Site Primary Web Site Domain1 Virtual Web Site 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 sites docroot directory; for example, C:\docroot\domain1 and C:\docroot\domain2.
F-8
August 2001
Updating the Registry

s To complete configuration for IIS web servers 1 2
Edit the system registry using the Registry Editor (enter regedit32 at a command prompt). Open the definition: 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:
HKEY_LOCAL_MACHINE\SOFTWARE\Vignette\6.0\Platform\IIS_Plugin
SS Config File:REG_SZ:C:/Vignette/inst-tripart/ws-hecate/ws.cfg SS 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 b c
Manually create a new web-site ID key registry entry for a virtual web server instance. Copy the primary web-site ID keys strings and their values to the newlycreated keys registry entry. 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.
August 2001
F-9
4 String Vgn_TplPrefix
For each virtual web-site ID key, add the following string-value pair:
Value The subdirectory, in the primary web server instance home directory, dedicated to this virtual web server instance (and IP address)..
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.cfg SS Config ID:REG_SZ:/ws-tripart/ SS Version:REG_SZ:6.0 Vgn_TplPrefix:REG_SZ:/domain1
Looking at key ID 5, you would see:

SS Config File:REG_SZ:C:/Vignette/inst-tripart/ws-hecate/ws.cfg SS Config ID:REG_SZ:/ws-tripart/ SS Version:REG_SZ:6.0 Vgn_TplPrefix:REG_SZ:/domain2 5 6
Stop and start the IIS World Wide Web Publishing Service from the Service Control Panel. Stop and start the CDS.
F-10
August 2001
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 youve defined in your web server configuration file.
s 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.
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>
August 2001
F-11
Argument ip-address
Description IP address for the virtual web server. With virtual hosting, each machine has multiple IP addresses, each representing a different hostname. 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. 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.
ws.cfg-path
ws-name
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. The hostname that corresponds to ip-address, for example ws-fisher. Path to the web server document root directory (which you provided during configuration of the CDS). Subdirectory in the document root that is dedicated to hostname.
hostname docroot-path
domain-path
F-12
August 2001
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 Servers

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

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

Topics include:
Setting up Development CDSs Creating Templates Submitting Static Files
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, youll 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.
F-14
August 2001
Youll need to add to the list of paths for each template a new template path for each virtual server. For example, suppose you have two virtual servers with these unique document directories: W INDOWS C:\docroot\domain1 C:\docRoot\domain2 S OLARIS /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 /domain1You must
specify a template path of /domain1/dataEntry.

A virtual host that has a Vgn_TplPrefix of /domain2You must
specify a template path of /domain2/dataEntry.

The main webserverYou 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).
August 2001
F-15
Submitting Static Files

Because virtual servers each use a unique subdirectory in the web server document root, its 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, youd submit the file once, with a path such as /domain1/images/logo.gif. If you want to use the file in both domains, youd submit the file twice:
For domain1, youd use the path /domain1/images/logo.gif For domain2, youd use the path /domain2/images/logo.gif
F-16
August 2001
Index
Symbols
%2f (in template path) B-32, B-33, B-44
A
accepting a certificate D-16 accessing CDS file system E-9 content database of different type 7-7 adjusting timeouts 11-3 variable settings to tune the VCMS installation 11-2 Admin Center closing tools 3-7 concepts 1-3 enabling self-registration 5-12 expanding displays 3-5 getting help 3-7 interfaces 3-5 Preferences file 6-17 sorting entries 3-5 starting tools 3-2 terms 1-3 tool directories 6-16 using 3-4 using tabs 5-3 viewing processes 3-5 Admin Center tools Configuration View 3-2 User Manager 3-2
admin command cfgedit A-12 changing the log level A-14 chlog A-13 for all VCMS processes A-5 for the CDS A-6 for the CMS A-8 for the MCS A-9 for the OMS A-10 refreshfromdb 8-6, A-16 starting Template Manager 8-5 stopping Template Manager 8-5 using to start processes 8-3 using to stop processes 8-3 admin refreshfromdb command A-16 location for all processes A-16 location for specific components A-16 options A-14, A-18 admin user 3-2, 5-4 administration tasks getting started 2-2 adminutil.cfg file B-6 ALLOWED_IP_ADDRESSES variable 11-10 Apache parsing 10-8 Application Engine configuration information 4-10 write access to docroot E-9 asp (Active Server Pages) 10-8 scripts 10-11 ASP Page Generator configuration information 4-11 asp-id.log file location B-7
August 2001
Index-1
Index
B
-b option for the transferproject command 12-17 Base Project cant delete 12-29 management ID 12-24 owners 5-4, 5-16 basic setup 1-3 bob (Dispatch Service) configuration information 4-4 process description A-18 bob.log file location B-8 bob.pid file location B-9 browser capabilities 10-2 Preferences file 6-17, B-38 Business Center Full role 5-6 Business Center Partial role 5-6 BY_STATUS template command 7-22
C
CA (Certificate Authority) D-13 Cache Manager (cmd) process A-20 campadmin program task location A-19 Campaign Logging Agent (cld) process A-20 CDS adjusting page generation timeouts 11-3 cmd (Cache Manager) process A-20 configuring outside firewall with http proxy E-11 considerations when stopping 8-5 ctld (Tcl Page Generator) process A-21 development mirroring live F-14 files and directories 6-14
flushing cache 10-9 increasing page generation requests 11-2 increasing page generation slave processes 11-2 mapping front door CURL 10-2 obtaining status 8-7 outside firewall E-4 pad (Placement Agent) process A-34 preview preferences file 6-16 process information in Details Window 4-8 in Primary window 4-8 process names 3-6 restricting access 11-10 setting up virtual hosting F-1 starting using Platform Manager 8-9 static files B-40 stopping using Platform Manager 8-9 subcomponents 3-6 tmd (Template Manager) process A-40 tools client security file 6-16 using proxy server for outbound connections to E-11 viewing information about 4-5 viewing process information 4-7 cds.cfg file location B-10 cert7.db security file D-14 Certificate Authority (CA) 6-17, D-13 certificates accepting D-16 and keys for LDAP security D-12 gencert command A-27 installing D-16 cfgedit (with admin command) A-12, A-13 cfgpassword.log file location B-11 cgutil command A-19
Index-2
August 2001
Index
changing default content database 7-26 log level A-13 ci_mgmt_id A-33 cld (Campaign Logging Agent) configuration information 4-16 process description A-20 cld-id.log file location B-12 cld-id.pid file location B-13 cld-id-timestamp.log file location B-14 CLEAR_CACHE template command 10-9, A-25 clearing disk cache for docroot 11-6 pages from root path 10-9 client certificate getting D-14 closing Admin Center tools 3-7 cmd (Cache Manager) behavior when page regeneration fails 11-9 configuration information 4-8 enabling cached page regeneration 11-8 method used to regenerate cached pages 11-8 process description A-20 setting POOL_SIZE variable 11-6 threads to flush cache 11-6 triggering events for flushing cache 11-6 cmd.log file location B-15 cmd.pid file location B-16 CMD_ACTION variable 10-9
CMS (bob) Dispatch Service process A-18 (ted) Event Service process A-39 (vhs) Request Service process A-54 commands 5-2 considerations when stopping 8-5 files and directories 6-13 increasing request handling 11-6 obtaining status 8-7 process information in Details window 4-4 in Primary window 4-3 process names 3-6 restricting access 11-10 starting using Platform Manager 8-9 starting using Start menu 8-8 stopping using Platform Manager 8-9 stopping using Start menu 8-8 viewing information about 4-2 viewing process information 4-3 CMS commands users and groups 5-2 cms.cfg file 6-4, B-16 location B-16 cmscppapi.cfg file location B-17 command cgutil A-19 encrypt A-22 gencert A-27 RESET_TIMEOUT 11-3 transferproject A-40 common variables 1-5 communication between components E-4 between processes E-4 enabling between components E-3 enabling between tools and components E-7 tools to component E-7 tools to process E-7
August 2001
Index-3
Index
COMPONENT command 10-3 components starting and stopping 8-2 config utility A-21 location A-21, A-56 using to configure the VCMS software to use LDAP D-39 config.log file location B-18 configuration file cds.cfg B-10 cms.cfg B-16 cmscppapi.cfg B-17 host.cfg B-23 insts.cfg B-24 manifest B-27 mcs.cfg B-30 obj.conf B-33 oms.cfg B-36 paths 6-5 refreshing variables 8-6 security.cfg B-39 ws.cfg B-52 configuration information ape (Application Engine) 4-10 ASP Page Generator 4-11 bob (Dispatch Service) 4-4 cld (Campaign Logging Agent) 4-16 cmd (Cache Manager) 4-8 ctld (Tcl Page Generator) 4-11 mcd (Multi-Channel Delivery Agent) 4-20 MCS plug-in 4-21 omd (Observation Manager) 4-17 pad (Placement Agent) 4-9 ted (Timed Event Service) 4-4 tmd (Template Manager) 4-10 vhs (Request Service) 4-4 vrd (Router) 4-17
vwd (MCS Watchdog) 4-20 vwd (OMS Watchdog) 4-18 web server 4-13 configuration tool config utility A-21, A-55 configuration variable CONNECT_RETRIES D-20 EUR_ENABLE_AUTO_REGISTRA TION D-20 configuration variables CONTENT_DB_CONNECTION_CL ASS 7-28 CONTENT_DB_CONNECTION_UR L 7-29 Configuration View primary window 3-3 configuring CDS outside firewall with http proxy E-11 CDS to docroot access E-9 CDS to metafiles cache access E-9 considerations for high-demand pages 11-8 development CDS with virtual servers F-14 number of required ports E-3, E-7 one or more content databases separate from the system database 7-13 ports for process communication E-3 ports for tools communication E-7 the VCMS software and LDAP connection roadmap D-11 the VCMS software to use LDAP roadmap D-3 VCMS software to use LDAP D-1 post-requisite steps D-52 VCMS tools outside firewall with SOCKS proxy E-12 virtual hosting F-1
Index-4
August 2001
Index
virtual hosting for Apache or IHS web servers F-11 virtual hosting for IIS web servers F-6 virtual hosting for iPlanet web servers F-5 CONNECT_RETRIES configuration variable D-4, D-20 content database 1-3 file system 1-3 content database and production management 7-17 changing default 7-26 configuring multiple 7-13 different type from system database 7-7 name collisions with multiple 7-18 performance issues for separate 7-15 content types 1-3 CONTENT_DB_* variables 7-3 creating records for legacy data 7-34 ctld (Tcl Page Generator) configuration information 4-11 process description A-21 templates directory B-43 ctld.tcl file 6-5, B-21 location B-21 path 6-6 CTLD_INTERP_INTERVAL variable 6-5 ctld-id.#.infolog file location B-19 ctld-id.#.log B-20 ctld-id.pid file location B-21, B-26 CURL command F-15
D
database authorization 7-5 changing table ownership 7-9 configuration variables 7-6 content tables 7-2 content types 1-3 granting SELECT permissions 7-10 password encryption 7-5 permissions 7-4 second login 7-8 size 7-5 system tables 7-2, C-2 versioned content 7-31 database environment variables for transferproject command 12-17 database password encryption encrypt command 7-11 in templates 7-23 database variables setting in templates 7-19 setting to default values 7-22 deleting database content with transferproject 12-30 project data with transferproject 12-29 delivery.tcl file 6-5, B-22 path 6-6 Developer role 5-5 directory metafiles B-32 metatemplates-id B-32 staticfiles B-40 tedtasksworkingdir B-43 templates-id B-43
August 2001
Index-5
Index
disabling interpretation of COMPONENT results 10-5 parsing on iPlanet 10-4 server-side includes 10-5 Dispatch Service (bob) process A-18 dist directory with transferproject command 12-42 DN (distinguished name) D-11 docroot restoring 9-6 docroot directory B-23 location B-23 read-only access from web servers E-2 setting up for virtual hosting F-4 Docroot Manager write access to docroot E-9 write access to metafiles cache E-9
E
-e option for the transferproject command 12-4 editing iPlanet obj.conf file 10-5 e-mail enabling notifications 5-13 SMTP server 5-13 enabling cmd to regenerate cached pages 11-8 communication between components E-3 communication between tools and components E-7 parsing 10-3 encrypt command 7-11, A-22 location A-22 encryption database password 7-5 in templates 7-13
environment variables setting for transferproject 12-17 error logging 6-10 levels 6-11 error logging levels A-14 error messages syslogd(1M) on Solaris 6-10, B-31 viewing 6-11 EUR_ENABLE_AUTO_REGISTRATIO N configuration variable D-4, D-20 Event Service (ted) process description A-39 tedtasksworkingdir directory B-43 Event Viewer 6-11 EventLog service 6-10 expire program task A-23 location A-23 options A-24 -r option A-23 exporting database content with transferproject command 12-25 project data with transferproject 12-20
F
-f option for transferproject command 12-41 file CDS 6-14 CMS 6-13 for configuration 6-4 for Tcl interpreter 6-5 in transferproject project package 12-13 listing 6-2 logs 6-9 obj.conf 10-4 path for configuration 6-5
Index-6
August 2001
Index
pid 6-9 Preferences 6-16 security.cfg 6-16 firewall configuring CDS outside with http proxy E-11 holes required for remote processes E-3 holes required for remote VCMS tools E-7 VCMS tools outside with SOCKS proxy E-12 flushcache program task location A-25 options A-26 scheduling 10-10 forcing components to reread configuration file 8-2 front door mapping to CURL 10-2 virtual hosting F-14
editing entry 5-15 name guidelines 5-15 reserved ID 5-4 guest user 5-4
H
HOST variable altering value for IP alias E-10 host.cfg file location B-23 HTTP 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-26 IIS parsing 10-7 importing database content with transferproject command 12-25 project data with transferproject command 12-23 importing projects conflicts 12-18 improving performance for high-demand pages 11-8 inboundmail program task A-29 options A-30 INCLUDE LIB command and transferring projects 12-32
G
gencert command A-27 location A-27 options A-28 general concepts 1-3 GET_NEXT_ID command 7-18 getting a server or client certificate D-14 group adding entry 5-15 Admin 5-4 attributes 5-7 cloning entry 5-15 defined 5-2 deleting entry 5-15
August 2001
Index-7
Index
increasing allowed static file submissions 11-6 allowed template operations 11-6 request handling 11-6 increasing performance methods for different configurations 11-2 installing a certificate D-16 install-path variable 1-5 insts.cfg file location B-24 Internal-use-only template launch A-32 internationalization, with LDAP D-21 IP address access to servers 11-10 for virtual hosting F-3 IP aliases configuring VCMS installation for their use E-10 iPlanet disabling server-side includes 10-5 NSAPI configuration file B-33 obj.conf file 10-4 parsing 10-4 IUSR_hostname 10-8
L
launch program task A-32 location A-32 options A-33 LD_LIBRARY_PATH environment variable for transferproject command 12-17 LDAP and internationalization D-21 and localization D-21 and the User Manager 5-1 configuration D-3, D-25 defined D-1 making schema and database changes D-17 non-secure connection to the CMS D-7 password-related user management with D-52 performing user and group administration with D-5 roadmap for configuring connection with the CMS D-11 roadmap for configuring the VCMS software to use D-3 role definitions D-52 secure connection D-9 server-side limit lookthroughlimit D-56 sizelimit D-56 SSL certificates and keys D-12 steps for configuration D-23 using config utility to configure for VCMS software use D-39 legacy data making available to VCMS installation 7-33 templates provided to handle 7-34 lightweight directory access protocol (LDAP) D-1 listiis utility F-8
J
jsp-id.log file location B-25
K
-k option for the transferproject command 12-27 key3.db security file D-14 keys gencert command A-27
Index-8
August 2001
Index
loading project package using config program 9-4 project package using Platform Manager 9-3 localization, with LDAP D-21 log file 6-9 asp-id.log B-7 bob.log B-8 cfgpassword.log B-11 cld-id.log B-12 cld-id-timestamp.log B-14 cmd.log B-15 config.log B-18 ctld-id.#.infolog B-19 ctld-id.#.log B-20 for each process 6-9 for numbered slave processes 6-9 jsp-id.log B-25 level of logging 6-10 maximum size 6-10 mcd-id.#.log B-29 mcd-id.deliver.log B-28 messages file B-31 omd-id.log B-34 pad.#.log B-37 path to 6-9 ted.log B-41 tmd-id.log B-44 upgrade.log B-46 vhs.#.log B-47 vrd-id.log B-48 vwd.log B-50 LOG template command B-19 LOG_LEVEL variable 6-10 login defaults file B-38 lookthroughlimit LDAP server-side limit D-56
M
Macro Editor UsrMacroData.xml file B-46 macros created by user B-46 making a non-secure connection to LDAP D-7 LDAP schema and database changes D-17 management ID of Base Project 12-24 managing groups 5-15 roles 5-18 users 5-4 manifest file location B-27 mapping root path to front door CURL 10-2 MAX_LOG_SIZE variable 6-10 mcd (Multi-Channel Delivery Agent) configuration information 4-20 process description A-34 mcd-id.#.log file location B-29 mcd-id.deliver.log file location B-28 mcd-id.pid file location B-30 MCS mcd (Multi-Channel Delivery Agent) process A-34 obtaining status 8-7 process information in Details window 4-20 in Primary window 4-19 process names 3-6 stopping using Platform Manager 8-9 viewing information about 4-18
August 2001
Index-9
Index
viewing process information 4-19 vwd (Watchdog) process A-55 MCS plug-in configuration information 4-21 mcs.cfg file 6-4 location B-30 messages file 6-10 location B-31 metafiles directory location B-32 metatemplates-id directory location B-32 methods for starting and stopping processes 8-2 moving transferproject project package 12-31
N
-n option for the transferproject command 12-35 next_id table with transferproject command 12-12 NSAPI obj.conf file B-33
process A-20 obtaining status 8-7 omd (Observation Manager) process A-34 process information in Details window 4-16 in Primary window 4-15 process names 3-6 starting using Platform Manager 8-9 stopping using Platform Manager 8-9 viewing information about 4-14 viewing process information 4-15 vrd (Router) process A-54 vwd (Watchdog) process A-55 oms.cfg file 6-4, B-36 location B-36 optimizing parse-html on iPlanet 10-6 ORACLE_HOME environment variable for transferproject command 12-17
P
pad (Placement Agent) configuration information 4-9 process description A-34 pad.#.log file location B-37 pad.pid file location B-38 Page Generator adjusting timeouts 11-3 ctld.tcl file B-22 delivery.tcl file B-22 increasing requests 11-2 increasing slave processes 11-2 setting timeout in templates 11-4 setting timeouts 11-3 templates directory B-43 timeouts 11-3
O
obj.conf file location B-33 Observation Manager (omd) process A-34 omd (Observation Manager) configuration information 4-17 process description A-34 omd-id.log file location B-34 omd-id.pid file location B-35 OMS cld (Campaign Logging Agent)
Index-10
August 2001
Index
pages configuring for high demand 11-8 parse-html function 10-4 parsing control for IIS 10-7 disabling on iPlanet 10-4 enabled by default on iPlanet 10-4 enabling 10-3 on Apache 10-8 password default for admin 5-11 for database 7-5 setting admin 5-11 password-related user management with LDAP D-52 performance concerns request handling 11-6 performing user and group administration using LDAP D-5 permissions CDS to write to docroot E-9 CDS to write to metafiles cache E-9 PG_WRITES_CACHED_PAGES variable E-9 pid file 6-9 bob.pid B-9 cld-id.pid B-13 cmd.pid B-16 ctld-id.pid B-21, B-26 mcd-id.pid B-30 omd-id.pid B-35 pad.pid B-38 path 6-9 ted.pid B-42 tmd-id.pid B-45 vhs.pid B-48 vrd-id.pid B-49 vwd.pid B-51 Placement Agent (pad) process A-34
Platform Manager privileges required to use 9-2 using for configuration tasks 9-2 using to load project 9-3 using 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_EN CRYPTED 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-32 PM_CONTENT_DBn_TEXTSIZE variable 7-32 PM_CONTENT_DBn_USERNAME variable 7-32 PM_CONTENT_DBx_TYPE variable 7-32 POOL_SIZE variable 11-6 ports configuring for process communication E-3 configuring for tools communication E-7 Preferences file 6-16, B-38 private keys gencert command A-27 process bob (Dispatch Service) A-18 changing log level A-13 cld (Campaign Logging Agent) A-20 cmd (Campaign Logging Agent) A-20
August 2001
Index-11
Index
ctld (Tcl Page Generator) process A-21 mcd (Multi-Channel Delivery Agent) A-34 omd (Observation Manager) A-34 pad (Placement Agent) A-34 tmd (Template Manager) A-40 vhs (Request Service) A-54 vrd (Router) A-54 vwd (Watchdog) A-55 processes starting and stopping 8-2 viewing 3-5 viewing using Configuration View 4-2 Production Center flushcache program task 10-9, A-25 inboundmail program task A-29 launch program task A-32 Preferences file 6-17 setting e-mail preferences 5-12 tool directories 6-16 transferproject command A-40 PROFILE_MARK template command 7-22 program task campadmin A-19 expire A-23 flushcache A-25 inboundmail A-29 launch A-32 pzndelete A-35 reseteur A-37, D-5 sgutil A-39 version A-49 project IDs with transferproject command 12-19 project package contents with transferproject command 12-41 description of files with transferproject command 12-13
dist directory with transferproject command 12-42 loading 9-3 loading using config program 9-4 loading using Platform Manager 9-3 moving with transferproject command 12-31 removing 9-3 with transferproject command 12-10 project_mgmt_id A-33 projects Base Project management ID 12-20, A-43 finding IDs 12-19 transferring between CMSs 12-1 VCMS project data and database content 12-11 proxy server HTTP E-11 SOCKS E-12 PROXY_HOST variable E-11 PROXY_PORT variable E-11 pzndelete program task A-35 examples A-36 options A-36 syntax A-35
R
-R option for the transferproject command 12-22 -r option for the transferproject command 12-22 reconfiguring initial VCMS software/LDAP configuration D-24, D-52 record necessary for production management 7-17 special meaning to VCMS software 7-16
Index-12
August 2001
Index
referenced configuration variables 8-6 refreshfromdb (with admin command) A-16 refreshing configuration variables with values from the database 8-6, A-16 REGENERATE_ACCESS_TIME variable 11-8 REGENERATE_CONCURRENCY_LIM IT variable 11-9 REGENERATE_CONCURRENCY_WAI T variable 11-9 REGENERATE_PAGE variable 11-8 removing pages from CDS cache 10-9 project package using config program 9-5 project package using Platform Manager 9-4 Request Service (vhs) process description A-54 staticfiles directory B-40 requirements and restrictions for transferring projects between CMSs 12-3 RESET_TIMEOUT command 11-4 syntax 11-4 reseteur program task A-37, D-5 location A-37 options A-38 restoring corrupted docroot 9-6 roadmap for configuring a connection between the CMS and LDAP D-11 for configuring the VCMS software to use LDAP D-3
role adding entry 5-19 attributes 5-8 authorization 5-5 Business Center Full 5-6 Business Center Partial 5-6 cloning entry 5-19 defined 5-2 definitions when using LDAP D-52 deleting entry 5-19 Developer 5-5 editing entry 5-19 if user has none 5-6 name guidelines 5-19 System 5-5 root mapping front door 10-2 Router (vrd) process A-54 row special meaning to VCMS software 7-16
S
-s option for the transferproject command 12-4 schema restrictions checking when importing with transferproject 12-28 search timeout setting D-20 secure connection between LDAP and the CMS D-9 security.cfg file 6-16 location B-39 self-registration enabling 5-12 server certificate getting D-14
August 2001
Index-13
Index
server components viewing using Configuration View 4-2 service dependencies 2-3 setting database variables in templates 7-19 page generation timeouts 11-3 pages regenerated by cmd 11-8 TEMPLATE_SYSTEM_DB_* variables 7-9 variables for default content database 7-27 sgutil program task A-39 sizelimit LDAP server-side limit D-56 SMTP server 4-3, 5-13 SOCKS proxy server specify by changing VCMS tools shortcut E-13 specify using command line E-13 using for outbound connections to VCMS tools E-12 Solaris pid files 6-9 Solaris configuration tool config program 9-3 SSL certificates and keys D-12 starting processes using admin command 8-3 staticfiles directory location B-40 status of transferred content items 12-39 steps to configure the VCMS software to use LDAP D-23 stopping processes using admin command 8-3 stopping CDS special considerations 8-5
stopping CMS special considerations 8-5 summary of chapters 1-3 SYBASE environment variable for transferproject command 12-17 syntax transferproject command 12-14 syslogd(1M) 6-10, B-31 system database logical parts 7-2 system content 7-2 user content 7-2 visitor information 7-2 system database tables complete list of C-2 description of each C-2 System role 3-2, 5-5 system tables granting SELECT permissions 7-10 SYSTEM_DB_* variables 7-3
T
-t option for the transferproject command 12-24 tables system database C-2 tar format with transferproject command 12-41 tasks ongoing 2-3 post-installation 2-2 Tcl interpreter files 6-5 Tcl Page Generator (ctld) process A-21 ted (Event Service) configuration information 4-4 process description A-39 tedtasksworkingdir B-43 ted.log file location B-41
Index-14
August 2001
Index
ted.pid file location B-42 tedtasksworkingdir directory location B-43 Template Developer Preferences file 6-17 template environment configuring second login 7-8 template location B-32, B-33, B-44 Template Manager (tmd) process description A-40 templates directory B-43 TEMPLATE_SYSTEM_DB_* variables 7-3 TEMPLATE_SYSTEM_DB_USERNAM E variable 7-9 templates and virtual web servers F-15 asp scripts 10-11 database password encryption 7-23 directory B-43 encryption 7-13 legacy 7-34 provided to create records 7-34 using RESET_TIMEOUT command 11-4 templates-id directory location B-43 testing virtual hosting F-13 threads available for clearing cache 11-6 timeouts for the web server 11-4 setting for Page Generator 11-3 tmd (Template Manager) configuration information 4-10 process description A-40 stopping and starting 8-5 templates directory B-43
tmd-id.log file location B-44 tmd-id.pid file location B-45 tool directories 6-16 tools client Certificate Authority 6-17 transferproject command 9-3, A-40 -b option 12-17 Base Project 12-6 Base Project management ID 12-20, A-43 cant delete Base Project 12-29 case sensitivity 12-28 column sizes 12-28 conflicts 12-18 content status 12-40 contents of project package 12-41 datatypes 12-28 DB2_DIR environment variable 12-17 deleting content data 12-30 deleting database content 12-30 deleting project data 12-29 dist directory 12-42 -e option 12-40 environment variables on Solaris 12-17 export 12-5 exporting database content 12-25 exporting project data 12-20 exporting project data and database content together 12-21 -f option 12-41 file properties 12-37 files in project package 12-13 finding project IDs 12-19 -i option 12-26 import 12-5 import conflicts 12-18 importing database content 12-25 importing project data 12-23 INCLUDE LIB command 12-32
August 2001
Index-15
Index
items that must be unique 12-18 -k option 12-27 keywords projects 12-33 records 12-37 templates 12-36 LD_LIBRARY_PATH environment variable 12-17 location 12-14 moving the project package 12-31 -n option 12-38 next_id table 12-26 options A-42 ORACLE_HOME environment variable 12-17 overview 12-5 permissions, user IDs, and authorizations 12-16 project and content item properties transferred 12-33 project data and database content 12-11 project package 12-10 project properties 12-33 properties transferred, inherited, and replaced 12-33 purge file 12-30 -R option 12-22 -r option 12-22 record properties 12-36 requirements and restrictions 12-3 -s option 12-4 schema restrictions 12-28 sequence 12-10 status codes A-41 status of transferred content items 12-39 SYBASE environment variable 12-17 syntax 12-14, A-41 -t option 12-24 tar and zip format 12-41
template IDs 12-26 import conflicts 12-18 things to do after transferring 12-32 transferring one or more content items 12-21 types of transfer 12-10 VCMS project data and database content 12-11 versioned content 12-38 versions of 12-3 workflow 12-37 -z option 12-18 tuning tips for VCMS software 11-2
U
upgrade.log file location B-46 user adding entry 5-9 admin 5-4 attributes 5-7 authorization 5-4 cloning entry 5-9 defined 5-2 deleting entry 5-9 editing entry 5-9 e-mail preferences 5-12 enabling self-registration 5-12 name guidelines 5-9 reserved IDs 5-4 viewing information 5-2 without roles 5-6 user and group administration using LDAP D-1 User Manager 3-2 primary window 3-4
Index-16
August 2001
Index
using an existing LDAP user repository D-3 CURLS 10-2 LDAP to perform user and group administration D-1 legacy templates 7-34 UsrMacroData.xml file B-46 utility config A-21, A-55
V
variable for paths 1-5 refreshing 8-6 settings 11-1 variations 10-2 VCMS software documentation B-23 VCMS tools configuring outside firewall with SOCKS proxy E-12 Help menu 3-7 launch bar 3-2 online help 3-7 outside the firewall E-7 version program task A-49 location A-49 options A-50 project task defaults A-52 workflow task defaults A-52 versioning and databases 7-31 vhs (Request Service) configuration information 4-4 process description A-54 staticfiles directory B-40 vhs.#.log file location B-47
vhs.pid file location B-48 VhsProtoDocRoot directory B-40 viewing log information on Solaris 6-10 log information on Windows 6-11 VCMS processes 3-5 Vignette subdirectory B-39 virtual hosting Apache and IHS web servers F-11 configuring F-1 iPlanet web servers F-5 Microsoft IIS web servers F-6 testing F-13 virtual web server development CDS F-14 front door F-14 static files F-16 visitor database separate 7-10 VISITOR_DB_* variables 7-3 vrd (Router) configuration information 4-17 process description A-54 vrd-id.log file location B-48 vrd-id.pid file location B-49 vwd (MCS Watchdog) configuration information 4-20 vwd (OMS Watchdog) configuration information 4-18 vwd (Watchdog) process A-55 vwd.log file location for MCS B-50 location for OMS B-50 vwd.pid file location for MCS B-51 location for OMS B-51
August 2001
Index-17
Index
W
Watchdog (vwd) process A-55 web server 10-5 adjusting number of processes 11-9 configuration information 4-13 configuring virtual hosting F-2 disabling iPlanet parsing 10-4 disabling server-side includes 10-5 docroot directory B-23 iPlanet obj.conf.vgnbak file B-33 mapping front door 10-2 outside the firewall E-3 parse-html function 10-4 parsing 10-3 parsing on Apache 10-8 parsing with IIS 10-7 preview preferences file 6-17 setting the timeout 11-4 Windows configuration tool Platform Manager 9-2 write access Application Engine to docroot E-9 Docroot Manager to docroot E-9 Docroot Manager to metafiles cache E-9 ws.cfg file 6-4 location B-52
Z
-z option for the transferproject command 12-6 zip format with transferproject command 12-41
Index-18
August 2001

Vignette Content Management Server V6 Administration Guide

Uploaded by

Copyright:

Available Formats

You might also like

Vignette Content Management Server V6 Administration Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vignette Content Management Server V6 Administration Guide

Uploaded by

Copyright:

Available Formats

Vignette Content Management Server V6

Send Us Your Comments

2 Roadmaps for Getting Started

3 Understanding the Admin Center Tools

4 Viewing VCMS Servers and Processes

5 Managing VCMS Users, Groups, and Roles

6 Managing VCMS Files

7 Managing System and Content Databases

8 Managing VCMS Processes

9 Managing the VCMS Site

Working with Web Servers

Tuning Your VCMS Installation

Transferring Projects and Tables between CMSs

A VCMS Process Reference

A-39 A-40 A-40 A-49 A-54 A-54 A-55 A-55

B VCMS File Reference

C System Database Tables

D Configuring the VCMS Software to Use an LDAP User Repository

F Configuring Virtual Hosting

VCMS Software Basic Concepts

Before you begin, make sure that:

VCMS Software Basic Concepts

Using This Book

software Admin Center tools and instructions for using:

VCMS Software Basic Concepts

Concepts and Terms

VCMS Software Basic Concepts

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

Host 3 CMS bob vhs ted

Host 4 Development CDS cds-a Docroot Manager cmd pad

Application Engine ape-1 tmd-1 jsp-1 ctld-1 asp-1

Host 6 OMS vrd-1 cld-1 omd-1 vwdhost6

Host 7 MCS vwdmcd-1 host7 plug-in

VCMS Software Basic Concepts

Common Path Name Variables

W INDOWS C:\Vignette S OLARIS /opt

Chapter 2, Roadmaps for Getting Started

VCMS Software Basic Concepts

Roadmaps for Getting Started

Before you begin: Topics include:

Roadmaps for Getting Started

with the Admin Center Tools.

Chapter 5, Managing VCMS Users, Groups, and Roles

self- registration should be allowed.

Enabling Self-registration on page 5-12 Setting E-mail Preferences on page 5-12

Roadmaps for Getting Started

See Initialization Files for the Tcl Interpreter on page 6-5

variables and procedures.

Roles Authorization on page 5-5

Fine tune your web server.

Roadmaps for Getting Started

What to do Manage VCMS processes.

Understand the VCMS database.

Set up virtual hosting.

Appendix F, Configuring Virtual Hosting

Chapter 3, Understanding the Admin Center Tools

Understanding the Admin Center Tools

Before you begin: